Abstract:
Improved intrusion detection and/or tracking methods and systems are provided for use across various computing devices and networks. Certain methods, for example, form a substantially unique audit identifier during each authentication/logon process. One method includes identifying one or more substantially unique parameters that are associated with the authentication/logon process and encrypting them to form at least one audit identifier that can then be generated and logged by each device involved in the authentication/logon process. The resulting audit log file can then be audited along with similar audit log files from other devices to track a user across multiple platforms.

Description:
RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 10/118,808, filed Apr. 8, 2002, the disclosure of which is incorporated by reference herein in its entirety. Any disclaimer that may have occurred during the prosecution of the above-referenced application is hereby expressly rescinded, and reconsideration of all relevant art is respectfully requested. 
     
    
     TECHNICAL FIELD 
       [0002]    This invention relates generally to computer devices and computer networks, and more particularly to methods and systems that provide enhanced computer device intrusion detection. 
       BACKGROUND 
       [0003]    Computer account identity theft continues to be a problem. In a typical scenario, an unscrupulous user gains unauthorized access (i.e., hacks into) a vulnerable computer system. Once inside the computer system the thief locates and steals one or more user identities (or credentials) that can be used to gain access to other computer systems, resources and/or networks. The thief may then masquerade as the user victim in accessing and hacking into the other computer systems and/or networks. This unfortunate stolen identity process can then be repeated over and over again making it nearly impossible, given today&#39;s average computer system/network, to catch such an impersonator and determine who they really are. 
         [0004]    Consequently, with the continued growth of the Internet and other like intranets, there is a growing need for improved intrusion detection and tracking methods and systems. 
       SUMMARY 
       [0005]    Improved intrusion detection and/or tracking methods and systems are provided. 
         [0006]    The above stated needs and others are satisfied by a method for forming an audit identifier that is substantially unique to an authentication process, in accordance with certain implementations of the present invention. The method includes identifying one or more parameters that are associated with the authentication process and encrypting them to form at least one audit identifier. Preferably, at least one of the parameter(s) identified is substantially unique to the authentication process. The resulting audit identifier can then be logged in an audit file for subsequent audit analysis. Various devices that have access to the same parameters can also generate matching audit identifiers, such that devices/users activities can be tracked across multiple platforms during an auditing process. 
         [0007]    In certain implementations, for example, several unique logon parameters are identified in a Kerberos ticket-granting service (TGS) message that is either sent or received by the logging device. Exemplary parameters include a user identifying parameter, a timestamp identifying parameter, a domain identifying parameter, a realm identifying parameter, an expiration time identifying parameter, a group identifying parameter, a successful logon count identifying parameter, a session key identifying parameter, a device identifier parameter, a device network address parameter, and/or other like types of parameters/data. 
         [0008]    In certain implementations, for example, the parameter(s) are hashed using an MD5 hash algorithm or the like to form the unique audit identifier. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0009]    A more complete understanding of the various methods and systems of the present invention may be had by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein: 
           [0010]      FIG. 1  is a block diagram generally illustrating an exemplary computer system suitable for use with certain implementations of the present invention. 
           [0011]      FIG. 2  is a block diagram depicting several machines, e.g., computer systems as in  FIG. 1 , operatively coupled to a network and configured to perform/support logon globally unique identifier (LGUID) logging and auditing, in accordance with certain exemplary implementations of the present invention. 
           [0012]      FIG. 3  is a block diagram depicting certain features associated with a machine, e.g., as in  FIG. 2 , employed to perform/support logon globally unique identifier (LGUID) logging and auditing, in accordance with certain exemplary implementations of the present invention. 
           [0013]      FIG. 4  is a flow diagram depicting a process with a machine, e.g., as in  FIG. 3 , employed to log logon globally unique identifiers (LGUIDs), in accordance with certain exemplary implementations of the present invention. 
           [0014]      FIG. 5  is a block diagram illustratively depicting an audit event analysis based on information logged by a logon globally unique identifier (LGUID) logging process, e.g., as in  FIG. 4 , in accordance with certain exemplary implementations of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0015]    Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. 
         [0016]      FIG. 1  illustrates an example of a suitable computing environment  120  on which the subsequently described methods and systems may be implemented. Exemplary computing environment  120  is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the improved methods and systems described herein. Neither should computing environment  120  be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in computing environment  120 . 
         [0017]    The improved methods and systems herein are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable include, but are not limited to, personal computers, server computers, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. 
         [0018]    As shown in  FIG. 1 , computing environment  120  includes a general-purpose computing device in the form of a computer  130 . The components of computer  130  may include one or more processors or processing units  132 , a system memory  134 , and a bus  136  that couples various system components including system memory  134  to processor  132 . 
         [0019]    Bus  136  represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus also known as Mezzanine bus. 
         [0020]    Computer  130  typically includes a variety of computer readable media. Such media may be any available media that is accessible by computer  130 , and it includes both volatile and non-volatile media, removable and non-removable media. 
         [0021]    In  FIG. 1 , system memory  134  includes computer readable media in the form of volatile memory, such as random access memory (RAM)  140 , and/or non-volatile memory, such as read only memory (ROM)  138 . A basic input/output system (BIOS)  142 , containing the basic routines that help to transfer information between elements within computer  130 , such as during start-up, is stored in ROM  138 . RAM  140  typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processor  132 . 
         [0022]    Computer  130  may further include other removable/non-removable, volatile/non-volatile computer storage media. For example,  FIG. 1  illustrates a hard disk drive  144  for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a “hard drive”), a magnetic disk drive  146  for reading from and writing to a removable, non-volatile magnetic disk  148  (e.g., a “floppy disk”), and an optical disk drive  150  for reading from or writing to a removable, non-volatile optical disk  152  such as a CD-ROM/R/RW, DVD-ROM/R/RW/+R/RAM or other optical media. Hard disk drive  144 , magnetic disk drive  146  and optical disk drive  150  are each connected to bus  136  by one or more interfaces  154 . 
         [0023]    The drives and associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules, and other data for computer  130 . Although the exemplary environment described herein employs a hard disk, a removable magnetic disk  148  and a removable optical disk  152 , it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and the like, may also be used in the exemplary operating environment. 
         [0024]    A number of program modules may be stored on the hard disk, magnetic disk  148 , optical disk  152 , ROM  138 , or RAM  140 , including, e.g., an operating system  158 , one or more application programs  160 , other program modules  162 , and program data  164 . 
         [0025]    The improved methods and systems described herein may be implemented within operating system  158 , one or more application programs  160 , other program modules  162 , and/or program data  164 . 
         [0026]    A user may provide commands and information into computer  130  through input devices such as keyboard  166  and pointing device  168  (such as a “mouse”). Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, camera, etc. These and other input devices are connected to the processing unit  132  through a user input interface  170  that is coupled to bus  136 , but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB). 
         [0027]    A monitor  172  or other type of display device is also connected to bus  136  via an interface, such as a video adapter  174 . In addition to monitor  172 , personal computers typically include other peripheral output devices (not shown), such as speakers and printers, which may be connected through output peripheral interface  175 . 
         [0028]    Computer  130  may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer  182 . Remote computer  182  may include many or all of the elements and features described herein relative to computer  130 . 
         [0029]    Logical connections shown in  FIG. 1  are a local area network (LAN)  177  and a general wide area network (WAN)  179 . Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. 
         [0030]    When used in a LAN networking environment, computer  130  is connected to LAN  177  via network interface or adapter  186 . When used in a WAN networking environment, the computer typically includes a modem  178  or other means for establishing communications over WAN  179 . Modem  178 , which may be internal or external, may be connected to system bus  136  via the user input interface  170  or other appropriate mechanism. 
         [0031]    Depicted in  FIG. 1 , is a specific implementation of a WAN via the Internet. Here, computer  130  employs modem  178  to establish communications with at least one remote computer  182  via the Internet  180 . 
         [0032]    In a networked environment, program modules depicted relative to computer  130 , or portions thereof, may be stored in a remote memory storage device. Thus, e.g., as depicted in  FIG. 1 , remote application programs  189  may reside on a memory device of remote computer  182 . It will be appreciated that the network connections shown and described are exemplary and other means of establishing a communications link between the computers may be used. 
         [0033]    Network access control, in accordance with certain exemplary implementations of the present invention, is provided by user authentication integrated with and/or otherwise supported by a Kerberos protocol. Under the Kerberos protocol, when a client device or machine wants to establish a session with a service/server device or machine, the client needs to be in possession a session key and a session ticket for the purpose of authenticating the client (e.g., user) with the service. The session key and the session ticket are issued by a Kerberos key distribution center (KDC) upon request of the client. Since the KDC is itself a service, the client must first obtain a session key and a session ticket for the transactions with the KDC before it can request session keys and tickets for other services. This special session ticket for communicating with the KDC is a ticket-granting ticket (TGT), and the associated session key is a logon session key. When the client wants to access a service other than the KDC, it sends a request, including the TGT, to the KDC for a session ticket for that service. The KDC responds to the request by issuing a session ticket for the target service to the client, which then uses the service session ticket to access the target service. 
         [0034]    The Kerberos protocol includes three sub-protocols. The sub-protocol in which KDC  210  gives a client a logon session key and a ticket-granting-ticket (TGT) is known as the authentication service (AS) exchange. The sub-protocol in which KDC  210  distributes a service session key and a session ticket for a requested service to the client is known as the ticket-granting service (TGS) exchange. The sub-protocol in which the client presents the session ticket for admission to a service is known as the application protocol exchange. 
         [0035]    Reference is now to  FIG. 2 , which is a block diagram of a networked environment  200  having a plurality of machines  202 ,  204 ,  206 , and  208  that are operatively coupled to a network  201  and configured to perform/support logon globally unique identifier (LGUID) logging and auditing, in accordance with certain exemplary implementations of the present invention. 
         [0036]    Preferably, environment  200  is configured to provide a high degree of security and hence trustworthiness such that unauthorized identity changes are rare. Unfortunately, there may be times when an unscrupulous user locates and exploits a security weakness that essentially allows for an online identity theft. Until now, it has been difficult if not impossible to determine when a thief begins masquerading as another user. In accordance with certain aspects of the present invention, the LGUID logging/auditing methods and systems presented herein can uncover and expose such illegal activity by causing the thief to unknowingly leave a trail of discoverable breadcrumbs (e.g., logged audit events) that can be followed from machine to machine during an audit to ascertain their true identity. 
         [0037]    Each of the machines  202 ,  204 ,  206 , and  208  is representative of a device, such as, e.g., a computer device as in  FIG. 1 , or other like device. Network  201  is representative of any communication system/link capable of supporting the desired communication between the devices. In certain implementations, for example, network  201  includes the Internet. 
         [0038]    Machine  202  (hereinafter referred to simply as M 1 ) includes a LGUID logger  212   a  that is configured to support the exemplary logging/auditing methods and systems provided herein. In the examples that follow M 1  is assumed to act as a client device. LGUID logger  212   a  is configured to record an audit log  214   a  having at least one audit event entry  222   a  associated with certain audit events that occur during the operation of M 1 . 
         [0039]    Machine  204  (hereinafter referred to simply as M 2 ) includes a LGUID logger  212   b  that is also configured to support the exemplary logging/auditing methods and systems provided herein. In the examples that follow M 2  is assumed to act as a trusted third-party server device that is capable of authenticating specific users/devices. As such, in this example M 2  is shown has having a KDC  210 . LGUID logger  212   b  is configured to record an audit log  214   b  having at least one audit event entry  222   b  associated with certain audit events that occur during the operation of M 2 . 
         [0040]    Machine  206  (hereinafter referred to simply as M 3 ) includes a LGUID logger  212   c  that is also configured to support the exemplary logging/auditing methods and systems provided herein. In the examples that follow M 3  is assumed to act as a server device capable of being accessed by a user of M 1  when M 1  provides the proper authentication information (e.g., a session ticket/message) generated by M 2 . LGUID logger  212   c  is configured to record an audit log  214   c  having at least one audit event entry  222   c  associated with certain audit events that occur during the operation of M 3 . 
         [0041]    Machine  208  (hereinafter referred to simply as M 4 ) includes a LGUID auditor  216  that is configured to support the exemplary logging/auditing methods and systems provided herein. In the examples that follow M 4  is assumed to act as a server device capable of capable of receiving or otherwise accessing all or portions of audit logs  214   a ,  214   b  and  214   c  from M 1 , M 2  and M 3 , respectively. M 4  may store audit data and other like information in a database  218 , for example. 
         [0042]      FIG. 3  is a block diagram depicting certain exemplary features/operations associated with a LGUID logger  212  that is configured to perform/support LGUID logging and auditing, in accordance with certain further implementations of the present invention. 
         [0043]    LGUID logger  212  is configured to extract certain information from one or more authentication messages  300  associated with an authenticating logon process. Preferably, the extracted information includes one or more logon parameters  302  or other data that is unique to the logon process and can thusly be traced back to the user/device that is involved in the authenticating logon process. By way of example, in environment  200  of  FIG. 2 , LGUID loggers  212   a ,  212   b  and  212   c  can be configured to extract information from a TGS ticket. In this example the extracted logon parameters would include one or more TGS ticket/message parameters that uniquely identify the user/device that is involved in the authenticating logon process. Hence, in certain implementations a user identifier and timestamp may be extracted. Other information, such as, e.g., a domain or realm identifier, an expiration time, one or more group identifiers, a session key, or other like information may also/alternatively be extracted by the LGUID logger. As can be seen from this exemplary listing of Kerberos parameters/fields/values (which is not complete), there are a variety of options available and certain logon parameter(s)  302  may prove to be better choices than others depending on the authentication system and/or implementation. 
         [0044]    With this in mind, in accordance with certain implementations of the present invention, it is assumed that LGUID logger  212  in  FIG. 3  is configured to extract three logon parameters from a TGS ticket. The TGS ticket is either being sent as would be the case for LGUID  212   b , or received as would be the case for LGUIDs  212   a  and  212   c  in  FIG. 2 . The first logon parameter is a user identifier, which is a unique name operatively associated with the user account that is authenticated/supported by KDC  210 . Note, that the term “unique” as used in this document is intended to also be understood to mean “substantially globally unique”. The second logon parameter is a realm identifier that is unique to the realm name that is supported by KDC  210 , for example. The third logon parameter is a timestamp that will likely be unique, depending on the resolution of the time measurement. For example, some computer devices have a 64-bit timestamp that is measured in 100 nanosecond increments beginning with some set time in the past. Thus, theoretically, it may be possible for two or more TGS tickets to share the same timestamp. 
         [0045]    Nevertheless, in this example, the desired logon parameters  302  are extracted and grouped together (e.g., concatenated) by a LGUID generator  304 . The resulting combined parameter is then provided to a one-way encryption process, hash function, message digest, etc., such as, e.g., hash function  306 , which produces corresponding data that is called a LGUID. In certain preferred implementations, for example, hash function  306  includes an MD5 hash function. 
         [0046]    The resulting LGUID is then logged in an audit log  214  as part of an audit event  222 . Subsequently (or simultaneously) an audit support function  308  can produce/send an audit report  310  that includes, for example, one or more audit events  222 . With reference to  FIG. 2 , for example, an audit report  310  from M 2  could be sent over network  201  to LGUID auditor  216  of M 4 . LGUID auditor  216  can actively/dynamically and/or passively collect/receive a plurality of audit reports from various machines in this manner. 
         [0047]    Attention is now drawn to  FIG. 4 , which is a flow diagram depicting an exemplary LGUID logging process  400  that corresponds to machines M 1 , M 2  and M 3  as illustrated in environment  200 . In this example, there are two logon activities represented by steps  401  and  402 . In step  401 , a user #1 (U 1 ) logs on as U 1  to M 1  with a ticket from KDC  210  in M 2 . Subsequently, in step  402 , the same U 1  makes an unwise decision to get a logon ticket to M 3  using the stolen logon credentials of user #2 (U 2 ). Note that in  FIG. 4 , whenever U 1  is masquerading as U 2 , the symbol U 2 * is used. 
         [0048]    Within step  401  there are several additional steps that occur. In step  404 , U 1  obtains an AS ticket from M 2  using U 1  credentials (e.g., user name/password combination). In step  406 , U 1  obtains a TGS ticket (TGS 1 ) for M 1  from M 2 . 
         [0049]    At this point, in this exemplary timeline, it is time to log an audit event  222  at both machines, M 1  and M 2 . So, in step  408 , M 2  generates an LGUID (G 1 ) based on logon parameters  302  in TGS 1 . Next, in step  410 , M 2  logs an audit event  222   b   1 . Audit event  222   b   1 , for example, may record that U 1  successfully authenticated and the associated LGUID (G 1 ). In step  412 , M 1  also generates the same LGUID (G 1 ) based on the same logon parameters  302 . Then, in step  414 , M 1  logs an audit event  222   a   1 . Audit event  222   a   1 , for example, may record the U 1  logon and the LGUID (G 1 ). 
         [0050]    Within step  402  there are also several additional steps that occur. In step  416 , U 2 * obtains an AS ticket from M 2  for U 2 . In step  418 , U 2 * obtains a TGS ticket (TGS 2 ) from KDC  210  in M 2 ; TGS 2  is for M 3 . Then U 2 * logs on to M 3 . 
         [0051]    Now once again at this point of this exemplary timeline, it is time to log another audit event  222  at machines M 1 , M 2  and now also the targeted M 3 . Thus, in step  420 , M 2  generates an LGUID (G 2 ) based on logon parameters  302  in TGS 2 . In step  422 , M 2  logs an audit event  222   b   2 . Audit event  222   b   2 , for example, may record that U 2  (actually U 2 *, but M 2  does not know this) successfully authenticated and the associated LGUID (G 2 ). 
         [0052]    With regard to machine M 1 , in step  424 , M 1  also generates the same LGUID (G 2 ) based on the same logon parameters  302  in TGS 2 . Then, in step  426 , M 1  logs an audit event  222   a   2 . Audit event  222   a   2 , for example, preferably records the fact that U 1  changed identity by explicitly supplying the credentials of another user, namely U 2 . This important user “switching” information is recorded along with LGUID (G 2 ). 
         [0053]    Not to be left out, M 3  also in possession of TGS 2 , generates LGUID (G 2 ) based on the same logon parameters  302  in TGS 2 , in step  428 . Then, in step  422 , M 3  logs an audit event  222   c   1 . Audit event  222   c   1 , for example, may record the U 2  (actually U 2 *, but M 3  does not know this) logon and the LGUID (G 2 ). 
         [0054]    Having now recorded the unauthorized activities of U 2 * in the applicable audit logs  214  of machines M 1 , M 2  and M 3 , at some point, LGUID auditor  216  of M 4  can receive the audit information in audit reports  310   a ,  310   b  and  310   c  from each machine, respectively. M 4  will then process the audit information accordingly. 
         [0055]    Thus, for example, attention is drawn to  FIG. 5 , which is a block diagram illustratively depicting an exemplary audit event analysis that may take place within LGUID auditor  216  ( FIG. 2 ). 
         [0056]    Audit data  500 , which may be stored for example in database  218 , includes at least portions of audit reports from one or more reporting/examined machines. Here, for example, audit report  310   a  is from machine M 1  and includes the audit events logged in steps  414  and  426  of  FIG. 4 . Audit report  310   b  is from machine M 2  and includes the audit events logged in steps  410  and  422  of  FIG. 4 . Similarly, audit report  310   c  is from machine M 3  and includes the audit event logged in step  430  of  FIG. 4 . 
         [0057]    Based on the audit data  500 , certain deductions may be made. For example, deduction  502  is that U 1  logged on to M 1 . The curving arrows illustrate the audit event data that supports the logical deduction being made. Thus, for example, deduction  502  is based on audit events  222   a   1  and, if available,  222   b   1 . Audit event  222   b   1  shows that LGUID G 1  is associated with user U 1 , and audit event  222   a   1  establishes that a G 1  logon event occurred at M 1 . Thus, in deduction  502  it is deduced that U 1  logged on to M 1 . 
         [0058]    Deduction  504  is based on the deduction of  502  and the further evidence provided by audit events  222   a   2  and, if available,  222   b   2 . Thus, for example, audit event  222   b   2  shows that LGUID G 2  is associated with user U 2 , and audit event  222   a   2  reveals that a user identity change occurred when LGUID G 2  was recorded. Thus, it is therefore known that U 1  was logged on to M 1  and that the user of M 1  (i.e., U 1 ) changed identity to U 2 . Hence, U 1  is now acting as U 2  (i.e., U 2 *). 
         [0059]    Finally, in this example, deduction  506  is that U 1  acting as U 2  (U 2 *) logged on to M 3 . This is based on the considerable evidence of an identity change provided by deduction  504  and audit event  222   c   1 , which places U 2 * as having logged on to M 3 . 
         [0060]    Consequently, with the above methods and systems an audit trail across multiple machines is created using the LGUID as a common marker within the collected and logged audit data. In addition to logging an LGUID, certain further implementations also log data that in some way further identifies the device/machine involved in the authentication process. This, for example, LGUID logger  212  (in  FIGS. 2 and 3 ) may include an Internet Protocol (IP) address and/or other machine identifying information in an audit event  222 . Note, that an IP address, for example, may be included in the information that is hashed by hash function  306 , and/or included in audit event  222  separately. Such machine identifying information could provide additional evidence about various unauthorized activities. 
         [0061]    While illustrated within a Kerberos environment, those skilled in the art will recognize that these exemplary methods are adaptable to a wide variety of other logon and/or authentication techniques. Additionally, clearly the information that is logged using the above exemplary methods and systems may also be used for other purposes during an audit analysis. 
         [0062]    Thus, although some preferred implementations of the various methods and systems of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the invention is not limited to the exemplary implementations disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.