User Entity Normalization and Associations

Abstract

A method, apparatus, and computing program product implements an embodiment of the invention that includes protecting a computer system by identifying multiple user identifiers associated with a single user entity. A first event is detected that is performed using a first one of the user identifiers. Upon detecting a second event that is performed using a second one of the user identifiers that is different from the first one of the user identifiers, an alert can be issued in response to a combination of the first and second events.

Description

[Technical field]

[0001] The present invention relates generally to computer security and networks, and more particularly to associating user identifiers in an event log with user entities and generating user entity profiles based on events in the log. [Background technology]

[0002] Many computer and network systems are deployed with multiple layers of security devices and software to detect and repel an ever-growing range of security threats. At the most basic level, computers use anti-virus software to prevent malicious programs from running on the computer. At the network level, intrusion detection and prevention systems analyze and control network traffic to detect and prevent malware from spreading through the network.

[0003] The above discussion is presented as a general overview of the related art in this field, and should not be construed as an admission that any of the information it contains constitutes prior art to the present patent application. Summary of the Invention

[0004] According to one embodiment of the present invention, there is provided a method for protecting a computer system, the method including the steps of: identifying, by a processor, a plurality of user identifiers associated with a single user entity, detecting a first event performed using a first one of the user identifiers, detecting a second event performed using a second one of the user identifiers that is different from the first user identifier, and issuing an alert in response to a combination of the first event and the second event.

[0005] In some embodiments, the step of identifying multiple user identifiers associated with the single user entity includes collecting a set of events including the first event and the second event, extracting respective user identifiers from events in the set, mapping the extracted user identifiers to respective accounts, and associating the accounts with respective user entities, where the single user entity includes one of a plurality of user entities.

[0006] In a first embodiment, mapping a given extracted user identifier to a given account includes normalizing a given user entity to a particular format, where the given account includes the normalized user entity.

[0007] In a second embodiment, the single user entity is associated with one or more accounts.

[0008] In a third embodiment, multiple user identifiers are mapped to a given account of the single user entity.

[0009] In an additional embodiment, detecting the first event includes detecting the first event on a first networked entity and detecting the second event includes detecting the second event on a second networked entity different from the first networked entity.

[0010] In a further embodiment, the step of detecting a first event includes detecting a plurality of first events during a first time period and generating a profile in response to the plurality of first events, wherein the step of detecting a second event includes detecting one or more second events during a second time period following the first time period, and a combination of the first and second events includes detecting the one or more second events not conforming to the profile.

[0011] In a complementary embodiment, the first event includes a time-based status of the single user entity, and the second event is not subject to the time-based status.

[0012] According to one embodiment of the present invention, there is provided an apparatus for protecting a computer network, the apparatus including a network interface card (NIC) and at least one processor configured to identify a plurality of user identifiers associated with a single user entity, detect a first event performed using a first one of the user identifiers, detect a second event performed using a second one of the user identifiers that is different from the first user identifier, and issue an alert in response to a combination of the first event and the second event.

[0013] According to one embodiment of the invention, there is additionally provided a computer software product for protecting a computer system, the product including a non-transitory computer readable medium having stored thereon program instructions which, when read by a computer, cause the computer to identify a plurality of user identifiers associated with a single user entity, detect a first event performed using a first one of the user identifiers, detect a second event performed using a second one of the user identifiers that is different from the first user identifier, and issue an alert in response to a combination of the first event and the second event. [Brief description of the drawings]

[0014] The present disclosure is herein described, by way of example only, with reference to the accompanying drawings. [Figure 1] FIG. 1 is a block diagram that illustrates generally a computing facility including a security server configured to generate an activity profile for a user entity based on events retrieved from a network event log, in accordance with one embodiment of the present invention. [Diagram 2] FIG. 2 is a block diagram illustrating an example of a given event log, according to one embodiment of the present invention. [Diagram 3] FIG. 3 is a block diagram illustrating an example of an aggregated event log stored on a security server according to one embodiment of the present invention. [Figure 4] FIG. 4 is a block diagram illustrating an example of a database record that may be stored by a domain database server according to one embodiment of the present invention. [Diagram 5] FIG. 5 is a block diagram illustrating an example of user entity information stored on a security server according to one embodiment of the present invention. [Figure 6]FIG. 6 is a flow chart that generally illustrates a method for generating an activity profile, in accordance with one embodiment of the present invention. [Figure 7] FIG. 7 is a flow chart that generally illustrates a method of using a generated activity profile to detect suspicious activity, according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Networked entities that communicate across computer networks typically keep logs that record events at the networked entities. These logs may contain identifiers for the events, but on the other hand, a user entity (e.g., an employee of an organization) may use multiple accounts (e.g., email accounts) when accessing data on the network, and each account may use multiple identifiers when accessing data on the network. Thus, it may be difficult to detect suspicious / malicious activities performed by a given user entity using different accounts and different user identifiers on the network.

[0016] Embodiments of the present invention provide a method and system for protecting a computer system by identifying multiple user identifiers associated with a single user entity. Upon detecting a first event performed using a first one of the user identifiers and detecting a second event performed using a second one of the user identifiers that is different from the first one of the user identifiers, an alert may be issued in response to a combination of the first and second events. In some embodiments, the first event is collected from a first log on a first networked entity and the second event is collected from a second log on a second networked entity that is different from the first networked entity.

[0017] In one embodiment, multiple events may be collected from multiple event logs on networked entities coupled to a computer network. Identifiers may be extracted from the events. The identifiers may be normalized to map the events to accounts. A subset of the accounts may then be associated with a single user entity. A user entity profile may then be generated based on the events associated with the single user entity. Using this embodiment, a system implementing an embodiment of the present invention may detect and flag suspicious activity when any subsequent events associated with the single user entity are determined to not conform to the user entity profile.

[0018] System Description Figure 1 is a schematic block diagram of an example computing facility 20 including a security server 22 configured to generate a user entity activity profile 24 based on activity recorded by a plurality of networked entities in their respective event logs 26, in accordance with one embodiment of the present invention. In the configuration shown in Figure 1, the security server 22 is configured to communicate across a data network, such as a local area network (database server) 32, with a plurality of computing devices 28 (also known as hosts or host computers), an account LAN 29, and a human resources (HR) server 30.

[0019] The account database server 29 may include a domain database management system (DBMS) application 31 and a domain database 37. The account database 33 contains a set of account database records 35, which are described in the text below with reference to FIG.

[0020] Computing facility 20 may also include an Internet gateway 34, which couples computing facility 20 to a public network 36, such as the Internet. To protect computing devices 28, computing facility 20 may also include a firewall 38, coupled to LAN 32, that controls data traffic between computing devices 28 and a data cloud 40, which includes one or more cloud servers 42, based on predetermined security rules.

[0021] As mentioned above, the security server 22 may be configured to generate a user entity profile 24 based on activity recorded by a number of networked entities in their respective event logs 26. Although the configuration of Figure 1 shows the networked entities to include a computing device 28, a firewall 38, and a cloud server 42, any other types of networked entities communicating across a network are contemplated as being within the spirit and scope of the present invention.

[0022] In the configuration shown in FIG. 1, the event logs 26 can be differentiated by appending letters to the identification numbers, so that the web pages look like this: ● Operating system (OS) log 26A stores information about events generated by operating systems (such as Windows (registered trademark) manufactured by Microsoft Corporation and Linux (registered trademark)) and applications running on computing device 28. The endpoint detection and response (EDR) log 26B may be generated by an endpoint agent 44 (e.g., XDR, manufactured by Palo Alto Networks, Inc., 3000 Tanner Way, Santa Clara, Calif. 95054, USA) running on the computing device 28. TM ) to store information about events detected by the • Firewall log 26C stores information regarding transmissions between computing facility 20 (e.g., computing device 28) and a server (e.g., cloud server 42) coupled to the Internet 36. One example of a firewall 38 is the PA-3250 Next Generation Firewall manufactured by Palo Alto Networks, Inc. TM It is. ● Cloud event log 26D stores information about events generated by cloud server 42. Examples of logs 26 include, but are not limited to, application logs, resource logs, and service logs for Amazon Web Services (provided by Amazon.com Inc., 410 Terry Avenue, North Seattle, WA 98109, USA).

[0023] In embodiments described herein, security server 22 extracts user identifiers (IDs) from logs 26, normalizes the user IDs, and associates the normalized user IDs with user entities (i.e., individual people such as employees). In some embodiments, HR server 30 stores an HR database 46 that stores information for each user entity. In some embodiments, HR database 46 contains a set of records 47 that have a one-to-one correspondence with the user entities (i.e., employees) of the organization.

[0024] Security server 22 includes a processor 48, memory 50, and a local area network interface card (NIC) 51 that couples the security server to network interface card 32. In some embodiments, processor 48 can combine logs 26 into an aggregated event log 52. Event logs 26 and 52 are described below in the description with reference to Figures 2 and 3, respectively.

[0025] In the embodiment described herein, processor 48 collects events from event logs 24A-24D and stores them in aggregated event log 52, although it is believed to be within the spirit and scope of the present invention to aggregate events from other types of event logs 26 into an aggregated event log. Examples of information that may be stored by one or more additional event logs 26 include, but are not limited to, the following: Input / Output (I / O) events (also known as file events). One example of an I / O event is the domain account "Company\jdoe" writing a file named "local_file\malicious.exe". Domain accounts are discussed below. Registry Events: One example of a registry event is the domain account "Company\jdoe" modifying a registry key related to Autorun with the value "local_file\malicious.exe". ● Process execution events. One example of a process execution event is SYSTEM automatically executing "local_file\malicious.exe" with the permissions of the domain account "company\jdoe." Network events. One example of a network event is the domain account "company\jdoe" making an HTTP request to "www.malware_command_and_control.com" using a process named local_file\malicious.exe. ● Single sign-on (SSO) events. SSO services (e.g. Okta TM , PingOne TM , Azure AD TM ) typically provides an audit log. One example of an event that processor 48 can collect is SSO account "john.doe@company.com" logging in. Email events. The email log that stores email events is TM Local system, ExchangerServer TM Server (i.e., enterprise) systems such as Exchange Online TMAn example of an email event in a local system is an email sent / received by "john.doe@gmail.com". An example of an email event in a server system is an email sent / received by "johndoe@company.com". An example of an email event in a cloud-based system is an email sent / received by "john_doe@cloud_email_provider.com".

[0026] 1, memory 50 also stores a number of user entity records 54 that store profiles 24. In some embodiments, each given user entity record 54 may retrieve information about a given user entity from HR database 46 and store the retrieved information in the given user entity record.

[0027] In some embodiments, the tasks described herein, such as extracting user IDs from event log 26, normalizing user IDs, associating normalized user IDs with user entities, aggregating log 26 into aggregated event log 52, and generating user entity profile 24, may be divided among multiple computer systems 22, 28, and 30 within computing facility 20 or external to the computing facility (e.g., cloud server 42). In additional embodiments, some or all of the functionality of computing device 28, security server 22, account database server 29, and HR server 30 may be deployed within computing facility 20 and / or Internet 36 as physical computing devices, virtual machines, or containers.

[0028] In some embodiments, the client computers 28 have respective hostnames 56 that can be used to identify each of the client computers.

[0029] Processor 48 includes a general-purpose central processing unit (CPU) or a dedicated embedded processor, which is programmed with software or firmware to perform the functions described herein. The software may be downloaded to security server 22 in electronic form, for example, over a network. Additionally or alternatively, the software may be stored on a tangible, non-transitory computer-readable medium, such as an optical, magnetic, or electronic memory medium. Still additionally or alternatively, at least some of the functions of processor 48 may be performed by hardwired or programmable digital logic circuitry.

[0030] Examples of memory 50 include dynamic random access memory, non-volatile random access memory, hard disk drives, and solid state disk drives.

[0031] 2 is a block diagram illustrating one example of data components stored in event log 26, according to one embodiment of the present invention. Event logs 26A-26D can store information in different respective layouts (i.e., formats and schemas), but for simplicity, the event log herein includes a single layout.

[0032] 2, each event log 26 includes a set of event log entries 60, each of which includes a date 62, a time 64, and an event message 66 that stores a description of the event. For a given event in a given event log entry 60, the date 62 includes the date of the given event, the time 64 includes the time of the given event, and the event message 66 describes the event and lists the user identifiers of the participants. User identifiers are explained in the description below with reference to FIG. 3.

[0033] Each event message 66 (i.e., one that references a given event) can have one or more user identifiers 68 (i.e., participants in the corresponding event). In one embodiment, if a given event message corresponds to an event involving a user entity sending an email, then the given event message 66 includes a single identifier (ID) 68. In another embodiment, if a given event message corresponds to an event involving a first account associated with a first user entity granting one or more system permissions to a second account associated with a second user entity, then the given event message can include two identifiers 68.

[0034] In an embodiment of the invention, there are multiple user entities 67 (i.e., individual physical users) that operate a computing device using one or more respective accounts 69. As described below, processor 48 may map each identifier 68 to a respective account 69 and then associate each account 69 with a respective user entity 67. Accounts 69 are described below in the description with reference to FIG.

[0035] In some embodiments, processor 48 may retrieve event log entries 60 from all event logs (e.g., event logs 26A-26D) and store the event information in the retrieved event log entries in aggregated event log 52. As described below, processor 48 may use the information stored in aggregated event log 52 to map events to user entities.

[0036] 3 is a block diagram illustrating an example of data components stored in aggregated event log 52, according to one embodiment of the invention. Aggregated event log 52 includes a set of aggregated log entries 70. In some embodiments, processor 48 may create a new aggregated log entry 70 for each event log entry 60 in each event log 26. In other words, each aggregated log entry 70 has a corresponding event log entry 60.

[0037] Each aggregated event log entry 70 includes an event ID 72, a source 74, a date 76, a time 78, an event message 80, and an identifier information record 82. Upon creating a new aggregated log entry 70 for a corresponding event log entry 60, processor 48 may: ●Create a unique event ID (72). Store, in the source 74, an identifier of the device that generated the event log that stores the corresponding event log entry 60. Examples of the identifier include, but are not limited to, the Internet Protocol (IP) address of a given cloud server 42 or the Media Access Control (MAC) address of a given computing device 28. ● Copy date 62 to date 76 from the corresponding event log entry 60. ● Copy the time 64 in the corresponding event log entry 60 to the time 78. ● Copy the event message 66 in the corresponding event log entry 60 to the event message 80.

[0038] In some embodiments, processor 48 may extract one or more user IDs 69 from the event message 80, normalize the user IDs, and associate the normalized user IDs with user entities. In the configuration shown in Figure 3, each user ID 69 extracted from a given event message 80 has a corresponding identifier record 82 that stores information such as the extracted user identifier 84, the identifier type 86, the mapped account m, and the associated user entity 90.

[0039] When creating a new aggregated log entry (i.e., as described above), processor 48 identifies a number (i.e., one or more) identifiers 68 in the event message 80, adds the identified number of identifier information records 82 to the new aggregated log entry such that each identifier 68 has a corresponding identifier information record 82, and may populate each given identifier information record as follows: ● Store the corresponding identifier 68 in the extracted identifier 84. • Classify the extracted identifiers 84 and store the classification in an identifier type 86. Classification of identifiers is explained below. ● Normalize the corresponding identifier 68 to map the corresponding identifier to a predefined account 69, and store the mapped account in Mapped Account 88. Normalized identifier 68 is described below in the description with reference to FIG. 6. Identifying a given user entity 67 associated with the mapped account 88 and storing the identified user entity in associated user entity 90. Identifying associated user entity 90 is described below in the description with reference to FIG. 6.

[0040] In the example described below, a given user entity 67 named “John Doe” has multiple mapped accounts 88, called “Company,” for which he works, each referenced by one or more identifiers 84.

[0041] Examples of identifier types 86 include, but are not limited to, the following: The domain name is something like "Company / jdoe." The domain name can typically be found in the event message 66 in the event logs 26A, 26B, and 26C. ● The Final Qualified Domain Name (FQDN) is typically something like “Company.com / jdoe.” The FQDN can typically be found in the event message 66 in the event logs 26A, 26B, and 26C. - The username (i.e. without the domain) is something like "jdoe." The username can typically be found in the event message 66 in the event logs 26A, 26B, and 26C. - A security identifier (SID) number, such as "S-1-5-21-1602811402-2595058921-120187713-502." The SID number can typically be found in the event message 66 in the event logs 26A and 26B. - A globally unique identifier (GUID) number, such as "8c6bfd4a-4cb2-11ea-b67e-88e9fe502c1f." The GUID number can typically be found in the event message 66 in the event logs 26B and 26D. - A local username is something like "host123\jdoe", where "host123" includes a given hostname 56. The local username can typically be found in the event message 66 in the event logs 26A, 26B, and 26C. ● Corporate usernames are things like "john.doe@company.com" These usernames can typically be found in event messages 66 in event logs 26, such as the SSO log (not shown), email logs (not shown), and event logs 26C and 26D. ● Personal usernames, such as "john.doe@gmail.com." These usernames can typically be found in event messages 66 in event logs 26, such as the SSO log (not shown), the email log (not shown), and event logs 26C and 26D.

[0042] 4 is a block diagram illustrating one example of the organization of a given database record 35, according to one embodiment of the present invention. Each database record 35 can store information such as an event identifier 92 and a corresponding account identifier 94 that references a given account 69. Using this organization, the account database record 33 can store a known relationship between the identifier 68 and the account 67.

[0043] In some embodiments, the account database 33 is implemented using the Directory Sync Service manufactured by Palo Alto Networks, Inc. TM (DSS TM ) and the endpoint agent 44 includes an XDR TM XDR TM The endpoint agent uses the DSS to retrieve the mapping between the identifier 68 and the account 67. TM You can interact with.

[0044] For example, the relationship between identifier 68 and account 67 may be used to configure an Active Directory domain that performs operations such as authenticating and authorizing all users and computers in a Windows domain type network, assigning and enforcing security policies for all computers, and installing and updating software. TM The account DBMS 31 may be maintained by a directory service application (not shown), such as the Active Directory (ADO) DBMS (manufactured by Microsoft Corporation of Redmond, Wash., USA). In this embodiment, the account DBMS 31 uses Active Directory to retrieve mappings between identifiers 68 and accounts 67, including domain accounts. TM can be queried.

[0045] Figure 5 is a block diagram illustrating an example of information stored in a user entity record 54 according to one embodiment of the present invention. In the configuration shown in Figure 5, each user 072 record 54 stores the following information: a user entity ID 100, a user entity profile 24, a set of status information records 104, a set of account information records 106, and a set of identifier-to-account mapping records 108.

[0046] The user entity ID 100 includes a unique identifier for a given user entity 67. In some embodiments, the processor may create a set of user entity records 54 that have a one-to-one correspondence with the account database records 47, and store a unique identifier for each user entity ID 100 in the set. Thus, each given user entity (i.e., employee) 67 has a corresponding user entity record 54. The user entity ID 100 may also be referred to herein as a user entity 100.

[0047] User entity profile 24 includes a user profile indicating the expected activity of the corresponding user entity. As described herein below in the description with reference to FIG. 7, processor 48 can use user profile 24 to detect any anomalies in the actions performed by the corresponding user entity within computing facility 20.

[0048] Each status information record includes a start date 110, an end date 112, and a status 114. Each given status 114 spans a period of time beginning with the start date 110 and ending with the end date 112. In some embodiments, the start date 110 and end date 112 may also include a time (e.g., 13:30 on Dec. 11, 2022).

[0049] Examples of status 114 include, but are not limited to, the following: ● Period of employment. Processor 48 may flag activity (eg, email, file access) by a corresponding user entity as suspicious if the user entity is no longer employed by the organization. Vacation Periods. Processor 48 may flag activity (eg, email, file access) by a corresponding user entity as suspicious if the user entity is on vacation. Location. An organization may have multiple locations, and the HR database may track the location from which each user entity works at a given time. In some embodiments, processor 48 may use this information to detect activity by a given user entity working from an anomalous location. ● Devices. User entities 100 may use different computing devices 28 (e.g., desktop / laptop computers and mobile devices). Processor 48 can use this information to track which user entity is using which computing device 28 at any given time (i.e., past or present). ● Department. At any given time, each user entity 100 can be assigned to a particular department (e.g., finance, marketing), thereby representing the systems (e.g., payroll, ad tracking) typically accessed by employees in each department. ● Title. The organizational title of a given user entity 100 (eg, manager, supervisor) can indicate privileges and typical system behavior for the given user entity.

[0050] Each user entity ID 100 typically uses one or more email accounts. In the configuration shown in Figure 5, each given user entity 100 includes a corresponding user entity record 54 that stores a corresponding account information record 106 for each of the email accounts used by the given user entity.

[0051] Each account information record 106 may store information such as a unique account ID 116, an account name 118 (i.e., an email address such as "john.doe@company.com" and john.doe@gmail.com), and an account type 120. In embodiments herein, the account ID 116 may also be referred to as an account 116.

[0052] Examples of account types 120 include, but are not limited to, the following: A domain account, such as "Company / jdoe." A domain account is a user account that is managed by an Active Directory within the organization. TM(Manufactured by Microsoft Corporation) Contains accounts that can be used across domains. Domain accounts are typically associated with the following identifier types 86: domain name, FQDN, user name, SID number, GUID number, and enterprise identifier. ● Local accounts include accounts such as "host123 / jdoe" (i.e., "host123" contains a given hostname 56) that are tied to each particular networked entity. Local accounts are typically associated with the following identifier types 86: username, SID number, GUID number, and local user. ● A cloud account, such as "john.doe@company.com." A cloud account is a user account that is managed by Google Cloud Platform. TM (provided by Alphabet, Inc., Mountain View, California) or Azure TM (such as that offered by Microsoft). Cloud accounts are typically associated with the following identifier types 86: GUID number, corporate identifier, and personal identifier. - Personal accounts, including accounts such as "john.doe@gmail.com" that can be used both inside and outside an organization. Personal accounts are typically associated with a personal identifier.

[0053] In an embodiment of the invention, processor 48 extracts identifiers 84 from event log entry 0 and normalizes the extracted identifiers to identify respective mapped accounts 88. For a given user entity 100 in the corresponding user entity record 54, processor 48 may store the current mapping between the extracted identifiers and the associated accounts (i.e., both for the given user entity) in an identifier-to-account mapping record 108. Each identifier-to-account mapping record 108 in a given user entity record 54 (i.e., for the corresponding user entity 100) may store information such as: • A user identifier 122, which includes the given identifier 84 used by the corresponding user entity. - Identifier types 124. As mentioned above, the identifier types 124 include domain name, FQDN, username, SID number, GUID number, local username, enterprise identifier, and personal identifier. • Associated account ID 126 stores the given account ID 116 that the processor 48 associates with the identifier 122 .

[0054] User Entity Identification FIG. 6 is a flow chart that illustrates generally a method of associating activity in the event log 26 with a user entity 100 and generating a profile 24 based on the user entity's activity within the computing facility 20 according to one embodiment of the present invention.

[0055] At step 130, processor 48 initializes user entity records 54. In some embodiments as described above, each user entity record 54 corresponds to a given HR database record 47a for a corresponding user entity 100. When initializing user entity records 54, and additionally, when initializing user entity records 54, processor 48 may initialize user entity profile 24 as well.

[0056] In step 132 , processor 48 identifies event log 26 .

[0057] In step 134, the processor selects an unmapped event log entry 60 within a given event log 26. In embodiments herein, an unmapped event log entry 60 includes any event log entry that is not processed by steps 134-136, as described below.

[0058] In step 136, processor 48 retrieves the selected event log entry. Upon retrieving the selected log entry, processor 48 may add a new aggregated log entry 70 to aggregated event log 52 and populate the event ID 72, source 74, date 76, time 78, and event message 80 in the new aggregated log entry using the embodiments described herein above.

[0059] In step 138, the processor 48 identifies one or more identifiers 68 in the event message 80 and stores the identified identifiers 68 in one or more extracted identifiers 84 (i.e., in one or more respective identifier information records 82).

[0060] In step 140, processor 48 normalizes one or more extracted identifiers 84 into one or more specified formats to map each of the extracted identifiers to a respective account 116. In some embodiments, each account type 120 may have a corresponding specified format. Using the example account types described above, they are as follows: ● The format specified for the account type "domain account" can be "CompanyName[ / ]UserName", where "CompanyName" and "UserName" are self-descriptive. As mentioned above, one example of a domain account is "Company / jdoe". - The format specified for the account type "local account" may be "ComputerID / UserName", where "ComputerID" includes an identifier for a given computing device 28 on the network 32, and "UserName" is self-describing. As mentioned above, one example of a local account is "host123 / jdoe". ● The format specified for the account type "cloud account" may be "UserName[@]CompanyDomain", where "UserName" is self-describing and includes an identifier for a given computing device 28 on the network 32, and "UserName" is self-describing and "CompanyDomain" includes the company domain name. As mentioned above, one example of a cloud account is "john.doe@company.com". The format specified for the account type "personal account" can be "UserName[@]ProviderDomain", where "UserName" is self-describing and "ProviderDomain" contains the email service provider domain name (e.g., Gmail, provided by Alphabet, Inc.). TM ). As mentioned above, one example of a personal account is "john.doe@gmail.com".

[0061] In some embodiments, the format for a given event is based on the source (e.g., the event log from which processor 48 retrieved the event log entry corresponding to the given event, the event type, or the fields in the log entry corresponding to the given event) or the contents of the log entry corresponding to the given event. ●If a given extracted identifier 84 has an email identifier format (i.e., "local-part[@]domain", where "local-part" includes the username and "domain"), the processor 48 may normalize the given identifier to a cloud account (e.g., "john.doe@company.com") or a personal account (e.g., "john.doe@gmail.com"). ● The processor 48 extracts a given identifier 84 from a given log entry 60 from the email server log and knows that if the domain is some public service, it most likely refers to a private email account (e.g., the context is that the given log entry came from a given log 26 of the email server, and the content of the given log entry included a public email domain such as "@gmail"). SID formats can refer to local or domain accounts and are often differentiated by content: in some embodiments, the prefix of a SID uniquely identifies a domain, or a local machine (e.g., a given computing device 28). The GUID can refer to different account types and can be determined by the context (e.g., the respective type of log 26 from which the processor 48 extracted the GUID) or by the processor 48 checking the account database 33 (e.g., the DSS TM ) to identify the GUID.

[0062] In some embodiments, there may be a mapping from one or more extracted identifiers 84 (corresponding to respective identifiers 68) to a single account 116 (corresponding to a given account 69), for example: ● The processor 48 may map the following identifier 84 to a given account 116 "Company / jdoe" whose account type 120 includes a domain account: "Company / jdoe", identifier type 86 containing a domain name - "Company.com / jdoe", identifier type 86 contains FQDN "jdoe", identifier type 86 containing a username without a domain "S-1-5-21-1602811402-2595058921-120187713-502", identifier type 86 contains a SID "8c6bfd4a-4cb2-11ea-b67e-88e9fe502c1f", where identifier type 86 contains a GUID "host123\jdoe", identifier type 86 contains a local username ○ "john.doe@company.com", where identifier type 86 contains a corporate username. ● The processor 48 may map the following identifier 84 to a given account 116 "host123 / jdoe" whose account type 120 includes a local account: "jdoe", identifier type 86 containing a username without a domain "S-1-5-21-1602811402-2595058921-120187713-502", identifier type 86 contains a SID "8c6bfd4a-4cb2-11ea-b67e-88e9fe502c1f", where identifier type 86 contains a GUID "host123\jdoe", identifier type 86 contains a local username ● The processor 48 may map the following identifier 84 to a given account 116 "john.doe@company.com" whose account type 120 includes a cloud account: "8c6bfd4a-4cb2-11ea-b67e-88e9fe502c1f", where identifier type 86 contains a GUID "john.doe@company.com", where identifier type 86 contains a corporate username "john.doe@gmail.com", where identifier type 86 contains a personal username ● The processor 48 may map the following identifier 84 to a given account 116 "john.doe@gmail.com" whose account type 120 includes a personal account: "john.doe@gmail.com", where identifier type 86 contains a personal username

[0063] In some embodiments, the processor 46 may query the database records 35 for the extracted identifiers for each account 116 .

[0064] Upon performing each mapping for a given extracted identifier 84, processor 48 may store the mapped account (ID) 116 in a mapped account 88 in the identifier information record 82 storing the given extracted identifier. If any given mapping detected in step 140 is not already stored in the user entity record 54, processor 48 may add a new identifier-account mapping record in the user entity record storing the mapped account and populate the identifier 122, identifier type 124, and associated account ID 126 accordingly.

[0065] In a first normalization embodiment, string manipulation may normalize a given extracted identifier 84 (i.e., processor 48 stores the extracted identifier as a text string). In this embodiment, processor 48 may normalize the extracted identifier 84 to enable correlation and querying. For example, processor 48 may use string manipulation to normalize both of the following to "company\jdoe": ● “jdoe@company[.]onmicrosoft[.] ●“domain=company.local, username=jdoe”

[0066] In a second normalization embodiment, processor 48 may normalize a given extracted identifier 84 by using domain knowledge. In this embodiment, a special identifier may indicate the type and scope of the account (e.g., host or main level) that is mapped to the given identifier. In the following example, processor 48 may use domain knowledge to: ●Map "AzureAD\jdoe" to a cloud account. ● "MicrosoftAccount\jdoe" domain to personal Microsoft TM Map to an account. ● Map "company\jdoe$" to the machine account for the given hostname 56 "jdoe" In this example, the "$" in the identifier indicates the machine account (i.e., "$" + username).

[0067] Domain knowledge is the processor 48's Active Domain TM and Kerberos realms, as well as allowing for differentiation between accounts that are typically managed differently in various data cloud environments.

[0068] In a third normalization embodiment, processor 48 may normalize a given extracted identifier 84 by using previously learned knowledge. In this embodiment, processor 48 may normalize a given extracted identifier 84 by using previously learned roles and directory synchronization services (DSSs) to determine the account for the given extracted identifier 84. TM In the following example, processor 48 may use domain knowledge as follows. If ad_domain_role contains "company", then the account type 120 is a domain account. If internal_hostname_role contains "company", then the account type 120 is a local account. If the event message only has a SID number, the processor 48 maps the given extracted identifier to "company\jdoe" via the DSS.sid field ("sid" is the Active Directory TM The RFC 24212 protocol allows a user to pivot between a public and private network (the protocol is an abbreviation for "security identifier" in the RFC 24212 protocol). If the extracted given identifier contains "john.doe@gmail[.]com", then the extracted given identifier is recognized as a domain account via the DSS.upn field ("upn" is an Active Directory TM , which is an abbreviation for "user principal name" in DSS.upn, and then maps the extracted identifier to the normalized identifier "company\jdoe". In this example, processor 48 compares the string "john.doe@gmail[.]com" to the DSS.upn field, and if a record with that value is found, it is considered to be a domain account, and the processor returns the normalized identifier "company\jdoe". In some embodiments, the value in the corresponding DSS record "DSS.netbios_domain\DSS.sam_account_name" may include "company\jdoe".

[0069] Returning to the flowchart, at step 142, for each given mapped account 88, processor 48 associates a given user entity 100 with the given mapped account 88. In some embodiments, each user entity 100 may be associated with one or more accounts 116. For example, as discussed above, mapped accounts may include "Company / jdoe," "host123 / jdoe," "john.doe@company.com," and "john.doe@gmail.com." All of these mapped accounts 88 may be associated with a given user entity named "John Doe."

[0070] In a first association embodiment, the processor 46 can use information stored in the HR database 46 and / or the account database 33 to associate a given account 69 with a given user entity 67. For example, if the processor 46 uses the account database 33 to map a given identifier 68 to a given account 69 “john.doe@gmail.com” and identifies a given user entity 67 named “John Doe” in the HR database 46, the processor can associate the given account with the given user entity since they have the same name.

[0071] In a second association embodiment, processor 48 may use heuristics to associate a given user entity with a given mapped account. For example, if "john.doe@gmail[.]com" matches the DSS display name "John Doe", then they are likely to refer to the same user entity 100.

[0072] In a third association embodiment, processor 48 may use profiling and attributes to associate a given user entity with a given mapped account. In one profiling example, processor 48 may determine that computing devices having hostname "host_123" are mostly used by a single user entity 100, "company\jdoe." In a second profiling example, processor 48 may determine that account "john.doe@gmail[.]com" always originates log entries 60 from a computing device having hostname "host_123."

[0073] In an example of a first attribute, processor 48 may determine that a computing device having hostname "host_123" is a personal endpoint used by user entity "jdoe." In an example of a second attribute, processor 48 may determine that "john.doe@gmail[.]com" is a personal email for user entity "jdoe." In an example of a third attribute, processor 48 may determine that user entity "jdoe" likely has access to account "host_123\Administrator."

[0074] Returning to the flowchart, at step 144 processor 48 identifies one or more of the user entities that participated in the event corresponding to the selected log entry.

[0075] At step 146, processor 48 updates the user entity profile for each of the user entities identified at step 144 with the event indicated by the event message in the selected log entry. In some embodiments, processor 48 may update user entity profile 24 with the event indicated in the selected log entry only if the event occurred within a specified period (e.g., the last 30 days).

[0076] In step 148, if there are unmapped log entries 60, the method proceeds to step 132. The method ends when there are no unmapped log entries 60.

[0077] Once the processor 48 creates a profile 24, the processor can use the profile to detect a single user entity 100 using multiple identifiers 122 to perform malicious activity within the computing facility 20. For example, the processor 48 can: 1. Google Drive TM Detects the cloud account “jdoe@company[.]com” which downloaded the file “confidential.pdf” from (provided by Alphabet, Mountain View, California). 2. Detects that the domain account "Company\jdoe" renamed the file "confidential.pdf" to "obscured.zip". 3. Detects an email sent to a personal email "john.doe@gmail[.]com" with an attachment named obscured.zip.

[0078] Although each of these individual events appears to be legitimate, embodiments of the present invention allow for correlating these three events to a single user entity 100, "John Doe." Correlating multiple events having multiple identifiers 122 allows processor 48 to detect suspicious event sequences tied to a single user entity 100.

[0079] FIG. 7 is a flow chart that generally illustrates a method of using a user entity activity profile 24 to detect suspicious activity, according to one embodiment of the present invention.

[0080] At step 150, at a point after generating profile 24 as described above in the description with reference to Figure 6, processor 48 collects an additional set of event log entries 60 from log 26. In some embodiments, processor 48 may collect the additional event log entries during a particular period of time (e.g., 10 minutes or a full day).

[0081] In step 152, processor 48 associates each of the events in the event message in the additional event log entry with a respective user entity 100, using the embodiment described in the description above with reference to steps 140-142 of FIG.

[0082] In step 154, processor 48 updates status information record 104 with any updates to HR database 46 and accordingly updates user entity profile 24. For example, user entity "John Doe" may be on vacation.

[0083] During step 156 , processor 48 selects an unselected user entity 100 .

[0084] At step 158, processor 48 compares the additional events of the selected user entity with user entity profile 24 of the selected user entity.

[0085] At step 158, processor 48 determines whether the additional events include suspicious activity based on the user entity profile. In some embodiments, each user profile 24 may include information from the status record 104 of the corresponding user entity 100. For example, if a given status 114 for a given user entity 100 indicates that the given user entity has left the company, and processor 48 detects events associated with the user entity after the departure, the processor may classify the events as suspicious because they do not conform to the departure status in the user entity profile.

[0086] If the additional events include suspicious activity, processor 48 issues an alert to the selected user entity at step 160. In one embodiment, the suspicious activity may be combined with a first event in a first given event log entry 60 used by processor 48 to generate the user entity profile and a second event in a second given event log entry 60 collected by processor 48 at step 150. In this embodiment, the first and second given event log entries were mapped to different identifiers 122 associated with the same user entity 100.

[0087] To issue an alert, processor 48 may perform actions such as sending a message to a system administrator (not shown) or restricting access to any of the accounts associated with the selected user entity.

[0088] At step 162, processor 48 updates the user entity profile of the selected user entity with additional events associated with the selected user entity.

[0089] In step 164, if there are unselected user entities 100 (ie, step 156), the method proceeds to step 156. If there are no unselected user entities 100, the method ends.

[0090] Returning to step 158 , if processor 48 does not detect suspicious activity in the additional events based on the user entity profile, the method proceeds to step 162 .

[0091] It will be understood that the above-described embodiments are cited by way of example, and that the invention is not limited to what has been particularly shown and described above, but rather, the scope of the present invention includes both combinations and subcombinations of the various features described above, as well as variations and modifications thereof not disclosed in the prior art that will occur to those skilled in the art upon reading the above description.

Claims

1. 1. A method for securing a computer system, comprising: identifying, by a processor, a plurality of user identifiers associated with a single user entity; detecting a status of the user entity based on an information record of a first user identifier among the user identifiers, the status including a time period; detecting a second event performed during the time period using a second one of the user identifiers that does not comply with the status of the user entity based on the information record of the first user identifier; issuing an alert in response to detecting an event occurring during said time period; A method comprising:

2. The step of identifying multiple user identifiers associated with the single user entity comprises: collecting a set of events; extracting respective user identifiers from the events in the set; mapping the extracted user identifiers to respective accounts; and associating said accounts with respective user entities; Including, the single user entity comprises one of a plurality of user entities; The method of claim 1.

3. Mapping a given extracted user identifier to a given account may include: normalizing a given user entity to a particular format; the given account includes the normalized user entity; The method of claim 2.

4. The single user entity is associated with one or more accounts; The method of claim 2.

5. Multiple user identifiers are mapped to a given account of the single user entity; The method of claim 2.

6. The step of detecting a status comprises: detecting a first event on a first networked entity indicative of said status; Detecting an event comprises: detecting a second event on a second networked entity different from the first networked entity; The method of claim 1.

7. The step of detecting a status comprises: detecting a plurality of first events during a first time period; and generating a profile in response to the plurality of first events; Detecting an event comprises: detecting one or more second events during a second time period subsequent to the first time period; The method of claim 1.

8. The step of detecting a status comprises: detecting, based on the first user identifier, that during the time period the user entity was no longer used by an organization issuing the first user identifier; The method of claim 1.

9. The step of detecting a status comprises: detecting, based on the first user identifier, that the user entity has left the organization issuing the first user identifier during the time period; The method of claim 1.

10. The step of detecting a status, detecting a first location of the user entity during the time period based on the first user identifier; and the step of detecting an event includes detecting an action performed during the time period at a second location, different from the first location, using the second user identifier. The method of claim 1.

11. The step of detecting a status, detecting a first device used by the user entity during the time period based on the first user identifier; and the step of detecting an event includes detecting an action performed on a second device, different from the first device, during the time period using the second user identifier. The method of claim 1.

12. The step of detecting a status, detecting a department within an organization to which the user entity belongs during the time period based on the first user identifier; and the step of detecting an event includes detecting a system accessed during the time period using the second user identifier; the system is not typically accessed by members of the department to which the user entity belongs; The method of claim 1.

13. The step of detecting a status, detecting a level of privilege of the user entity during the time period based on the first user identifier; and the step of detecting an event includes detecting an action performed using the second user identifier during the time period that is incompatible with the level of privilege. The method of claim 1.

14. 1. An apparatus for securing a computer network, comprising: Network Interface Card (NIC) and at least one processor; The processor: Identifying multiple user identifiers associated with a single user entity; Detecting a status of the user entity based on an information record of a first user identifier among the user identifiers, the status including a time period; Detecting a second event performed during the time period using a second one of the user identifiers that does not comply with the status of the user entity based on the information record of the first user identifier; and issuing an alert in response to detecting an event occurring during said time period; The apparatus is configured to:

15. A given processor may: Collecting sets, extracting respective user identifiers from the events in the set; mapping the extracted user identifiers to respective accounts; and associating said accounts with respective user entities; configured to identify multiple user identifiers associated with the single user entity by the single user entity comprises one of a plurality of user entities; 15. The apparatus of claim 14.

16. The given processor is configured to map the given extracted user identifier to the given account by normalizing the given user entity to a particular format; the given account includes the normalized user entity; 16. The apparatus of claim 15.

17. The single user entity is associated with one or more accounts; 16. The apparatus of claim 15.

18. Multiple user identifiers are mapped to a given account of the single user entity; 18. The apparatus of claim 17.

19. A given processor may: Detecting the status by detecting a first event indicative of the status on a first networked entity of the network; and detecting the event by detecting a second event on a second networked entity different from the first networked entity; It is configured as follows:

15. The apparatus of claim 14.

20. a given processor is configured to detect the status by detecting a plurality of first events during a first time period; The given processor is further configured to generate a profile in response to the plurality of first events; the given processor is configured to detect the event by detecting one or more second events during a second time period subsequent to the first time period; 15. The apparatus of claim 14.

21. A computer program comprising computer instructions and stored on a non-transitory computer-readable medium; The computer instructions, when executed by a processor, cause the computer to: Identifying multiple user identifiers associated with a single user entity; Detecting a status of the user entity based on an information record of a first user identifier among the user identifiers, the status including a time period; Detecting a second event performed during the time period using a second one of the user identifiers that does not comply with the status of the user entity based on the information record of the first user identifier; and issuing an alert in response to detecting an event occurring during said time period; A computer program that makes

Images