System and method for identity consolidation

Abstract

A method and apparatus for identity consolidation for a plurality of electronic identities is described. In one embodiment, the method includes receiving user identification data extracted from an electronic communication, the user identification data corresponding to an unknown identity of a sender of the electronic communication. The method further includes determining a known identity for the sender using the user identification data extracted from the electronic communication and associating the known identity with the unknown identity of the sender of the electronic communication. In one embodiment, an association between the known identity and the unknown identity is maintained to determine whether parties of subsequent information transfers are authorized to participate in the information transfers.

Description

FIELD OF INVENTION

Embodiments of the invention relate to the field of processing data, and more particularly, to identity consolidation for a plurality of electronic identities.

BACKGROUND OF THE INVENTION

A modern organization typically maintains a data storage system to store and deliver records concerning various significant business aspects of the organization. Stored records may include data on customers (or patients), contracts, deliveries, supplies, employees, manufacturing, or the like. A data storage system of an organization usually utilizes a tabular storage mechanism, such as relational databases, client/server applications built on top of relational databases (e.g., Siebel, SAP, or the like), object-oriented databases, object-relational databases, document stores and file systems that store table formatted data (e.g., CSV files or Excel spreadsheet files), password systems, single-sign-on systems, or the like.

Existing security techniques typically monitor messages sent by employees of an organization to outside recipients to prevent loss of sensitive information. However, users may utilize a wide range of different ways to transfer information with other users, utilize network resources, store data and information, and control information technology assets. Each of these different ways of transferring information is usually accompanied by an address or username. The existing security techniques are unable to monitor each of these with reference to user-specific policies.

SUMMARY OF THE INVENTION

A method and apparatus for identity consolidation for a plurality of electronic identities is described. In one embodiment, the method includes receiving user identification data extracted from an electronic communication, the user identification data corresponding to an unknown identity of a sender of the electronic communication. The method further includes determining a known identity for the sender using the user identification data extracted from the electronic communication and associating the known identity with the unknown identity of the sender of the electronic communication. In one embodiment, an association between the known identity and the unknown identity is maintained to determine whether parties of subsequent information transfers are authorized to participate in the information transfers.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.

FIG. 1 is a block diagram of exemplary system architecture for consolidating identity data for a plurality of electronic identities of a user.

FIG. 2 is a block diagram of one embodiment of an ID agent.

FIG. 3 is a block diagram of one embodiment of an identity management console.

FIG. 4 is a flow diagram of one embodiment of a method for initializing a consolidated user identity record.

FIG. 5A is a flow diagram of one embodiment of a method for extracting and communicating identification data.

FIG. 5B is a flow diagram of one embodiment of a method for extracting and communicating identification data.

FIG. 6 is a flow diagram of one embodiment of a method for correlating identification data with user identities.

FIG. 7 is a flow diagram of one embodiment of a method for correlating identification data with user identities.

FIG. 8 is a flow diagram of one embodiment of a method for utilizing a consolidated identity.

FIG. 9 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

A system and method for identity consolidation for a plurality of electronic identities is described is described. User identification data, such as an email address, instant message handle, etc., may be extracted from electronic communications. Because communications techniques, such as web email, are typically not connected with electronic directory systems, the extracted user identification data corresponds to an unknown identity of a sender of the electronic communication. In one embodiment, a known identity is determined for the sender using the user identification data extracted from the electronic communication. The known identity may then be associated with the unknown identity of the sender of the electronic communication. Furthermore, an association between the known identity and the unknown identity is maintained to determine whether parties of subsequent information transfers are authorized to participate in the information transfers.

In the following description, numerous details are set forth. It will be apparent, however, to one of ordinary skill in the art having the benefit of this disclosure, that the present invention may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.

Some portions of the detailed description that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing”, “computing”, “calculating”, “determining”, “displaying” or the like, refer to the actions and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.

FIG. 1 is a block diagram of exemplary system architecture 100 for consolidating identity data for a plurality of electronic identities of a user.

The system 100 includes an identity management console 108, a consolidated user identities database 110, a data monitoring system (DMS) 104, a policy management system (PMS) 116 and a plurality of user endpoint devices (e.g., user endpoint device 112A, 112B, and 114). They may be coupled to a computer network that communicates any of the standard protocols for the exchange of information. They may run on one Local Area Network (LAN) and may be incorporated into the same physical or logical system, or different physical or logical systems.

Alternatively, the identity management console 108, consolidated user identities database 110, DMS 104, PMS 116 and user endpoint devices (e.g., user endpoint device 112A, 112B, and 114) may reside on different LANs that may be coupled together via the Internet but separated by firewalls, routers, and/or other network devices. In yet another configuration, the identity management console 108 and PMS 104 may reside on a server, or different servers, coupled to other devices via a public network (e.g., the Internet) or a private network (e.g., LAN). It should be noted that various other network configurations can be used including, for example, hosted configurations, distributed configurations, centralized configurations, etc.

The user endpoint devices (e.g., user endpoint device 112A, 112B, and 114) are responsible for sending and receiving messages. Messages may represent a transmitted document (e.g., an email message, a web mail message, an instant message, a short message service (SMS) message, a multimedia message service (MMS) message, etc.) or data stored in databases, caches, etc. In one embodiment, user endpoint devices 112A, 112B, and 114 are client devices, such as, for example, personal computers, laptop computers, cellular telephones, personal digital assistants (PDAs), etc.

In one embodiment, some user endpoint devices, such as user endpoint device 112B are devices known by data monitoring system 104 or identity management console 108. In one embodiment, a device is a “known” device when it is part of an electronic directory system, such as a Microsoft Active Directory system or Lightweight Data Access Protocol (LDAP) system. These directory systems hold corporate email addresses, system login information (e.g., username and password), as well as related information about individuals in the corporation such as a business unit each individual belongs to, employee identification number, etc. Thus, when a user logs into such a machine with an assigned username and password (e.g., an electronic identity), messages sent to and from user endpoint device 112B may be presumed to have been generated by the logged-in user.

In one embodiment, some user endpoint devices, such as user endpoint device 112A are devices that are not “known” by data monitoring system 104 or identity management console 108. Although user endpoint device 112A is connected to a network and is enabled to send and receive messages that can be intercepted by data monitoring system 104, user endpoint device 112A is not a device that is part of an electronic directory system. For example, such a device may be a user's personal laptop that is connected to a network, a PDA connected to the corporate network, etc. Thus, these devices may have access to sensitive information, and be able to send and receive such information, while little is known about these devices.

The PMS 116 is responsible for receiving parameters pertaining to data loss prevention (DLP) policies, such as pre-configured template policies or customized policies, and creating policies based on these parameters. In one embodiment, the PMS 116 receives the policy parameters via a policy definition graphical user interface (not shown). In another embodiment, the PMS 116 receives the policy parameters from an Application Programming Interface (API) or via a configuration file formatted in text or a defined data format (e.g., extensible markup language (XML) or binary format).

The PMS 116 may create policies based on regulations concerning handling of sensitive information maintained by an organization, or based on corporate data governance rules. The regulations may include, for example, the Health Insurance Portability and Accountability Act (HIPAA) ensuring the confidentiality of electronic protected health information, California Senate Bill 1 (SB1) or Senate Bill 1386 (SB1386) controlling customer information leaving the company and affiliates, the Gramm-Leach-Bliley Financial Services Modernization Act controlling customer information leaving a financial institution, the Cardholder Information Security Program (CISP) controlling handling of customer credit card information maintained by an organization, or the like. In one embodiment, the PMS 116 may use policy templates or customized policies pre-configured based on input provided by individuals familiar with the relevant regulations or corporate data governance rules.

A policy may include a set of rules that specify which information should be present in a message to trigger a violation. For example, a message may represent a transmitted document (e.g., an email message, a web mail message, etc.) or data stored in databases, caches, etc. The set of rules may provide specific conditions for triggering a violation (e.g., a sender or recipient of a message, inclusion in a message of a keyword(s) or regular expression pattern, etc.). The rules in the policy may be combined using logical connectives of first-order logic (e.g., AND, OR, NAND, NOR, NOT, equivalent, nonequivalent, or the like).

In one embodiment, a policy specifies source data that should be protected from unauthorized transmission, access or any other use. The source data may be stored in a tabular format (e.g., data in a relational database, data maintained by client/server applications built on top of relational databases, data in document and file systems that store table formatted data (e.g., CSV files or Excel spreadsheet files), etc.) or it may be stored in a non-tabular format but convertible to a tabular format (e.g., data stored as comma separated values in a flat file, a password database or a single-sign-on system, relational data in an object-oriented database, etc.). The policy may also specify which portions of the source data 102 should be included in a message to trigger a policy violation.

In one embodiment, the PMS 116 creates an index of the source data. In one embodiment, the index is in the form of an abstract data structure that includes signatures of data elements of the source data and placement information of each data element within the source data. The signature may be an encrypted or hashed copy of the data element or some other representation of the data element that would not allow a malicious user to recover the actual content of the data element. The placement information may include the number of a row storing the data element in the source data and/or the number of a column storing the data element in the source data. Optionally, the placement information may also include the data type of the column. The signatures and placement information may be stored in a tuple-storage structure derived from the source data. A tuple-storage structure provides a mechanism for storing multiple tuples associated with the elements of the source data. Examples of tuple-storage structures include a hash table, a vector, an array, a tree or a list. Each type of the tuple-storage structure is associated with a method for retrieving a set of tuples for any given content element (the set of tuples may be empty if no match is found in the tuple-storage structure). The abstract data structure may be created periodically and sent to the DMS 104, along with the policy that is to be implemented.

The DMS 104 is responsible for monitoring information content (e.g., sent email messages, instant messages, text messages, and/or other documents according to a configuration of the DMS 104) to detect policy violation incidents. In one embodiment, the DMS detects policy violation incidents using the policies supplied by the PMS 116 and the source data index created by the PMS 116. Once the DMS 104 has detected a policy violation, the DMS 108 reports the policy violation to an appropriate entity (e.g., a manager, database administrator, a reporting system, etc.) or performs some other action.

In one embodiment, user endpoint device 112B hosts identification (ID) agent 106A that is responsible for monitoring messages and extracting user identification data from the messages. For example, when user endpoint device 112B sends an email message from a corporate email address, ID agent 106A extracts a username, email address, etc. associated with the message. Furthermore, when non-corporate forms of communication are used (such as instant messaging, a web email, etc.), ID agent is responsible for extracting identification information, such as an IM handle, web email address, etc. associated with the message. In one embodiment, the extracted information is associated with an individual responsible for sending the message. Furthermore, because user endpoint device 112B is a “known” device (e.g., a device that is logged into an electronic directory system), both public identification information (e.g., information that is part of the electronic directory system) and private identification information (e.g., an IM handle, web email address, etc.) can be extracted from messages sent to and from user endpoint device 112B. The extracted identification information is then transmitted to Identity Management Console 108 to consolidate user identity data, as discussed in greater detail below.

In one embodiment, the DMS 104 hosts ID agent 106B that is also responsible for monitoring messages and extracting user identification data from the messages sent by any of user endpoint device 112A, 112B, or 114. However, unlike ID agent 106A, ID agent 106B cannot associate private identification information (e.g., an IM handle, web email address, etc.) extracted from the messages with public identification information (e.g., information that is part of the electronic directory system) of the same users. For example, ID agent 106B may extract identification information from electronic messages sent by user endpoint device 112A which may be a user's private laptop computer, not logged into an electronic directory system with a corporate assigned username and password. Rather user endpoint device 112A may have network access from which it sends and receives messages. ID agent 106B extracts identification information from messages transmitted by user endpoint device 112A and sends the extracted identification information to Identity Management Console 108 to consolidate user identity data, as discussed in greater detail below.

Identity management console 108 is responsible for consolidating user identification data in order to create a global identity for users of an electronic directory system. The consolidated user identity data is stored in consolidated user identities database (DB) 110. A consolidated, or global, user identity may be considered as composed of two types of user identity data: known user identity data and correlated identity data. For example, when a user logs into an electronic directory system with a given name and password, an identity known to the electronic directory system is used. However, when a user then sends email messages from his or her private email account (e.g., a YAHOO™, GOOGLE™, etc. email account), which is not affiliated with the electronic directory system, the sender's identity is unknown for policy enforcement purposes, data loss prevention, tracking, etc.

In one embodiment, identity management console 108 correlates a user's known identity (e.g., an assigned login and password, user endpoint device identification, etc.) with identification data extracted from various types of electronic communications. Once a known identity and unknown identification data are correlated, both identities can be consolidated into a data record representing a user's global identity. For example, when John Doe logs into his work computer, sends an instant message with the IM handle JD, and sends an email from JD@YAHOO, the IM handle and private email address are correlated with John Doe's known identity. Thus, DMS 104 and PMS 116 may enforce policies, with respect to messages transmitted via John Doe's personal accounts (e.g., JD@YAHOO and the IM handle). The identification data, and messaging types discussed above are merely exemplary, as any type of messaging system that uses a user's identity may be correlated with a user.

Therefore, identity information about multiple personal user communications accounts, such as webmail addresses (e.g., YAHOO! MAIL™, GMAIL™, HOTMAIL™, etc.), instant messaging address user names (e.g., YAHOO INSTANT MESSANGER™, AOL INSTANT MESSANGER™, MSN MESSENGER™, etc.), etc. may be linked to known identities, such as a corporate identity. Because a large portion of inadvertent and malicious data loss events often involve sending information to and from personal communications accounts, collecting and correlating different types and parameters for user's personal identities is highly beneficial. For example, personal communications accounts could be blocked altogether, but many organizations are not willing to take this step because of potential negative reactions from employees. By using correlated identities, as described herein, organizations are able to enforce security, data loss, and usage policies, with minimal impact to employees.

FIG. 2 is a block diagram of one embodiment of an ID agent 200. The ID agent 200 may include a communications monitoring engine 202, identification extraction engine 204, and an ID reporting engine 206. In one embodiment, ID agent 200 may be deployed on both DMS 104 and user endpoint device 112B, discussed above in FIG. 1. However, in an alternate embodiment, an ID agent 200 may be configured specifically for deployment on one of DMS 104 or user endpoint device 112B.

The communications monitoring engine 202 monitors the transmission of electronic communications (e.g., email messages, web email messages, instant messages, text messages, etc.). In one embodiment, communications monitoring engine 202 monitors outgoing messages. In another embodiment, communications monitoring engine 202 monitors incoming messages or both outgoing and incoming messages. Communications monitoring engine 202 notifies identification data extraction engine 204 when communications monitoring engine 202 detects an electronic communication. In one embodiment, the electronic communication may be any of a corporate email, web email, instant message, social networking message, SMS message, MMS message, etc.

The identification data extraction engine 204 is responsible for extracting identification data from an electronic communication in response to notification from communications monitoring engine 202. In one embodiment, identification data extraction engine 204 parses the electronic communication to locate and extract the identification data. For example, identification data extraction engine 204 may parse an instant message to determine an IM handle responsible for sending a message. In one embodiment, the identification data extraction engine 204 also extracts additional identity data corresponding to an electronic communication. For example, when user endpoint device 112B sends a web email message, identification data extraction engine 204 extracts information relating to the user endpoint device 112B (e.g., a user's login, password, internet protocol address, machine name, etc.) from which the message was sent.

Identification data extraction engine 204 forwards the extracted identification information to ID reporting engine 206.

ID reporting engine 206 is responsible for sending reports, containing the extracted identification data, to the identity management console. In one embodiment, the ID reporting engine 206 transmits reports each time ID information is extracted from an electronic communication. In another embodiment, ID reporting engine 206 stores ID data and periodically transmits batches of extracted identification information.

FIG. 3 is a block diagram of one embodiment of an identity management console 300. The identity management console 300 may include an identification data receipt engine 302, an identification correlation engine 304, and a reporting engine 306. In one embodiment, identity management console 300 also includes a consolidated user identities database (DB) 308. In another embodiment, identity management module 300 communicates with consolidated user identities DB 308 (e.g., via a network).

Identification data receipt engine 302 is responsible for receiving reports of identification data from ID agents, such as ID agents 106A, 106B, and 200. Identification data receipt engine 302 forwards received reports to identification correlation engine 304.

Identification correlation engine 304 is responsible for correlating known identities with unknown identities and consolidating the results in consolidated user identities DB 308. In one embodiment, where an ID report consists of both known identification data (e.g., an electronic directory system assigned user ID, IP address, machine name, etc.) and unknown identification data (e.g., an IM handle, web email address, social/professional networking user name, etc.), identification correlation engine 304 associates known identification data with the unknown identification data. For example, if an ID report specifies that an electronic communication in the form of a web email sent by ANONYMOUS@YAHOO was submitted from a machine j_doe (e.g., a username known to, and assigned by, a corporate directory system) is currently logged into, j_doe can thereafter be associated with the personal email address ANONYMOUS@YAHOO. Thus, applications such as policy enforcement systems, data loss prevention systems, network resource tracking, etc. may monitor and/or handle electronic communication sent by ANONYMOUS@YAHOO as having been sent by j_doe. Identification correlation engine 304 stores the correlation in consolidated user identities DB 308 thereby creating a consolidated identity for the user j_doe.

In one embodiment, where an ID report consists of unknown identification data (e.g., an IM handle, web email address, social/professional networking user name, etc.), identification correlation engine 304 queries consolidated user identities DB 308. When a record exists with the unknown identification data identification, correlation engine 304 updates the database with the new occurrence. In one embodiment, when there is no record with the unknown identification data in the database 308, correlation engine 304 stores a record with unknown identification data separately (e.g., in a separate “suspension” table). Subsequently, when correlation engine 304 adds new identification data to the consolidation user identities DB 308, correlation engine 304 checks the suspension table for a record with matching identification data. If such a record is found, correlation engine 304 adds any other identifiers from the same record in the suspension table to the consolidation user identities DB 308, and removes this record from the suspension table.

In one embodiment, an identity will not be available in consolidated user identities DB 308 for identification correlation engine 304 to correlate with known identification data. For example, a data thief could log onto a shared system that makes use of generic names/passwords (e.g., a shared research laboratory network, computer commons, unsecured Wi-Fi access point, etc.). Furthermore, a confidence level for a consolidated user identity may be relatively low. In these situations, a consolidated user identity may be established via physical and/or forensic evidence. For instance, if correlated internet identities cluster around list of known systems at known times, examining access logs from other systems or interviewing individuals may lead to establishment of a corporate identity. In one embodiment, identity management console 300 receives (e.g., via identity management console 108 of FIG. 1) known user identification data that has been obtained from physical and/or forensic investigation. Thus, identification correlation engine 304 may thereafter utilize the known identification data to correlate previously unknown or anonymous identities.

In one embodiment, identification correlation engine 304 further correlates groupings of unknown user identities, which either cannot or have not yet been correlated with a known corporate identity. For example, identification correlation engine 304 may correlate three recurring unknown identities in consolidated user identities DB 308 that are responsible for data leakage. By correlating unknown identities, identification correlation engine 304 responses to reporting engine 306 may be generated without (yet) having a known corporate identity associated with the consolidated unknown identities. In one embodiment, unknown identities are correlated by identification correlation engine 304 to enable policy enforcement against the unknown identity(s).

Reporting engine 306 is responsible for responding to and sending reports concerning user identities. In one embodiment, when an ID agent (e.g., ID agent 106B of FIG. 1) detects an electronic communication, a corresponding system (e.g., DMS 104 of FIG. 1, a DLP system configured with an ID agent, a resources tracking system or application configured with an ID agent, etc.) may issue a request to know the true identity associated with the electronic communication from an unknown identity. Reporting engine 306 receives such requests, and queries identification correlation engine whether the unknown identity exists in any consolidated identity records. When the unknown identity exists, reporting engine 306 responds with the true/known identity. Otherwise reporting engine 306 responds that the identity is unknown. In one embodiment, reporting engine 306 further responds with a correlated grouping of unknown identities. In one embodiment, by responding that identities are unknown and/or belong to a grouping of recurring unknown identities, reporting engine 306 enables policy enforcement directed at unknown identity(s), such as more stringent policies for unknown identities or complete blocking of internet access for recurring and correlated unknown identities. Continuing the example above, reporting engine 306 may receive a request concerning an instant message sent by the IM handle ANON_JD. Based on consolidated identity data stored in consolidated user identities DB 308, reporting engine 306 may respond that ANON_JD is associated with the identity for j_doe to reveal the identity of the sender.

FIG. 4 is a flow diagram of one embodiment of a method 400 for initializing a consolidated user identity record. The method 400 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the method 400 is performed by an identity management console (e.g., identity management console 108).

Referring to FIG. 4, processing logic begins with obtaining identity seed data for a user (processing block 402). Seed data is identification data known about a user prior to the sending or receiving of an electronic communications. In one embodiment, the seed data is data stored in an electronic directory system (e.g., an Active Directory or LDAP directory), such as the user's assigned login name, password, employee number, assigned IP address, etc. Processing logic then creates a database record for the user (processing block 404). In one embodiment, the database record is an entry in a database table for multiple users. Furthermore, each record may be dynamically sized to permit the storage of a plurality of correlated IDs. In one embodiment, as discussed above and as will be discussed in greater detail below, the seed/known data and database record forms the basis of a consolidated user identity.

FIG. 5A is a flow diagram of one embodiment of a method 500 for extracting and communicating identification data. The method 500 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the method 500 is performed by an ID agent (e.g., ID agent 106A).

Referring to FIG. 5A, processing logic begins with detecting an electronic communications transmission at a user endpoint device (block 502). In one embodiment, the user endpoint device may be any of a personal computer, laptop computer, personal digital assistant, cellular telephone, etc. Because the user endpoint device may be any of the devices noted above, the electronic communications transmission may be an email message, web email message, instant message, SMS message, MMS message, etc.

Processing logic extracts identification (ID) data from the user endpoint device (processing block 504). In one embodiment, processing logic extracts the user name associated with a user currently logged into the endpoint device, the endpoint device's IP address (or other networking address), telephone number, etc. Processing logic also extracts ID data from the communications transmission (processing block 506). As discussed above, processing logic parses the electronic communication to determine identification data (e.g., an email address, IM handle, etc.) associated with the electronic communication.

Processing logic reports the ID data extracted from the electronic communication and the user endpoint device (processing block 508). In one embodiment, the report is directed to an identity management console, such as identity management console 108.

FIG. 5B is a flow diagram of one embodiment of a method 550 for extracting and communicating identification data. The method 550 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the method 550 is performed by an ID agent (e.g., ID agent 106B).

Referring to FIG. 5B, processing logic receives an electronic communications transmission from a user endpoint device (block 552). The electronic communication may be an email message, web email message, instant message, social/professional networking message, etc. In one embodiment, the message is received at a DMS 104 which is monitoring electronic communications sent from a plurality of user endpoint devices. However, other systems, such as data loss prevention systems, usage tracking systems, etc. configured with an ID agent 106B may also receive and handle messages, as discussed herein.

Processing logic extracts identification data from the electronic communications transmission (processing block 554). In one embodiment, the electronic communication is parsed to determine identification data, such as the sender's name of an email, IM handle of an instant message, login name for a social/professional networking message, etc.

Processing logic reports the identification data extracted from the electronic communications transmission (processing block 556). In one embodiment, the report is directed to an identity management console, such as identity management console 108.

FIG. 6 is a flow diagram of one embodiment of a method 600 for correlating identification data with user identities. The method 600 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the method 600 is performed by an identity management console (e.g., identity management console 108).

Referring to FIG. 6, processing logic receives identification (ID) data extracted from a communications transmission and an ID extracted from a user endpoint device (block 602). In one embodiment, the data is received from a user endpoint device configured with an ID agent, such as user endpoint device 112B.

Processing logic determines a user identity associated with the ID extracted from the user endpoint device (processing block 604), and determines whether a correlation exists between the user identity and the ID extracted from the electronic communication (processing block 606). If a correlation does exist, processing logic updates the correlation in an identity database with the new occurrence. If no correlation exists, processing logic creates a correlation between the user identity and the extracted identification data (processing block 608). In one embodiment, processing logic updates records in a consolidated user identities database, such as consolidated user identities database 110. For example, processing logic may receive a user's assigned login and an IM handle extracted from an instant message. Processing logic then either creates a correlation between the user's consolidated identity and the IM handle, or updates an existing correlation.

In one embodiment, processing logic updates a strength of the correlation in the identity database (processing logic 612). The strength may indicate such factors as how often a correlation between a user identity and the extracted identification data occurs, how many times the correlation has been detected, whether the correlation conditions are similar to other occurrences (e.g., a user name correlation is detected but from different IP addresses), etc. By updating a measure of strength, additional guarantees of trustworthiness are provided by the consolidated user identity. That is, a correlation that has been detected 100 times may be trusted more readily than a correlation that has only been detected twice. Thus, systems, such as policy enforcement systems, data loss prevention system, usage tracking systems, etc. may factor the strength of the correlation into their own actions.

Processing logic classifies the electronic communication ID as known (e.g., a correlation between a known identity and the communication's ID exists) (processing block 614), and reports the determined user identity, classification, and strength of correlation (processing block 616). In one embodiment, the report is transmitted to DMS responsible for monitoring electronic messages, a data loss prevention system responsible for preventing inadvertent loss of sensitive information, a risk management system, an IT usage tracking system, etc.

FIG. 7 is a flow diagram of one embodiment of a method 700 for correlating identification data with user identities. The method 700 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the method 700 is performed by an identity management console (e.g., identity management console 108).

Referring to FIG. 7, processing logic receives identification (ID) data extracted from a communications transmission (block 702). In contrast to FIG. 6, discussed above, an ID extracted from a user endpoint device is not received along with the extracted ID data.

Processing logic determines whether a correlation exists for the ID extracted from the electronic communication (processing block 704). If a correlation does exist (e.g., the extracted ID is associated with an existing user identity), processing logic updates the correlation and strength in an identity database with the new occurrence (processing blocks 708 and 710). Processing logic further classifies the identity for the electronic communication as known (processing block 712).

If no correlation exists, processing logic classifies the identity associated with the electronic communication as unknown (processing block 706). That is, since processing logic did not receive known identification data, and no correlations currently exist for the extracted ID, the extracted ID remains unknown. In one embodiment, as discussed above, unknown identities, as well as grouping of unknown identities and/or recurring unknown identities, are also correlated in identity database with the new occurrence and a strength of the correlation updated (processing blocks 716 and 718).

Processing logic reports the determined identity (if known), classification, and strength of correlation (processing block 714). In one embodiment, the report is transmitted to a DMS responsible for monitoring electronic messages, a data loss prevention system responsible for preventing inadvertent loss of sensitive information, a risk management system, an IT usage tracking system, etc.

FIG. 8 is a flow diagram of one embodiment of a method 800 for utilizing a consolidated identity. The method 800 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the method 800 is performed by the system of FIG. 1.

Referring to FIG. 8, processing logic receives information content from an electronic communication (processing block 802). In one embodiment, the received information may include free-form text and may be a file (e.g., an archived email message stored on a hard drive of a computer) or a block of data transmitted over a network (e.g., an email message, instant message, social/professional networking message, etc. transmitted over a network using any type of a network protocol). In one embodiment, the electronic communication is from a personal communications channel, such as a web email account (e.g., YAHOO! MAIL™), an instant message (e.g., AOL INSTANT MESSANGER™), text message, etc.

Processing logic determines whether the information content violates a policy (processing block 804). In one embodiment, the policy also specifies one or more rules regarding the identity of a party associated with the information content (e.g., whether a particular sender is allowed to send, or a particular recipient is allowed to receive, information content that includes sensitive data protected by the policy).

Processing logic requests an identity report for the electronic communication from an identity management console (processing block 806) and receives the identity report (processing block 808). In one embodiment, the report includes a user identity corresponding to the identification data extracted from the electronic communication and correlated with the user identity. In one embodiment, the identity report further includes a classification (e.g., whether the identity is known or unknown) and strength of the identity correlation.

Processing logic determines whether the parties associated with the information content from the electronic communication are authorized to handle (e.g., send, receive, copy, etc.) this information content in accordance with the relevant policy (processing block 810). Processing logic notifies a user, or other appropriate entity, when there is a policy violation (processing block 812).

Processing logic further captures data surrounding the policy violation (processing block 814). In one embodiment, processing logic captures a time when the policy violation occurred, the correlated identity for a user responsible for the policy violation, etc.

Accordingly, method 800 allows sensitive information to be protected from unauthorized use (e.g., transmission, access, etc.). Furthermore, because unknown identification data for electronic communications is extracted and correlated with a known identity, the policy may be enforced irrespective of how the electronic communication is transmitted, or from which computer an electronic communication was sent.

FIG. 9 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system 900 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The exemplary computer system 900 includes a processing device (processor) 902, a main memory 904 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 906 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 918, which communicate with each other via a bus 930.

Processor 902 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processor 902 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processor 902 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processor 902 is configured to execute the processing logic 926 for performing the operations and steps discussed herein.

The computer system 900 may further include a network interface device 908. The computer system 900 also may include a video display unit 910 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 912 (e.g., a keyboard), a cursor control device 914 (e.g., a mouse), and a signal generation device 916 (e.g., a speaker).

The data storage device 918 may include a machine-accessible storage medium 930 on which is stored one or more sets of instructions (e.g., software 922) embodying any one or more of the methodologies or functions described herein. The software 922 may also reside, completely or at least partially, within the main memory 904 and/or within the processor 902 during execution thereof by the computer system 900, the main memory 904 and the processor 902 also constituting machine-accessible storage media. The software 922 may further be transmitted or received over a network 920 via the network interface device 908.

While the machine-accessible storage medium 930 is shown in an exemplary embodiment to be a single medium, the term “machine-accessible storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-accessible storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-accessible storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. A computer-implemented method, comprising: receiving, by a processing device executing an identification engine, user identification data extracted from an electronic communication, the user identification data corresponding to an unknown identity of a sender of the electronic communication;determining, by the processing device, a known identity for the sender using the user identification data extracted from the electronic communication;associating, by the processing device, the known identity with the unknown identity of the sender of the electronic communication, an association between the known identity and the unknown identity being maintained to determine whether parties of subsequent information transfers are authorized to participate in the information transfers;determining a measure of correlation strength for the association between the known identity and the unknown identity based on at least one of how often the association is detected and how many times the association has been detected, wherein the correlation strength is maintained with the association; andtransmitting the known identity as the sender of the electronic communication and the measure of correlation strength to a communications data monitoring system to monitor information content to detect policy violation incidents.

2. The method of claim 1, further comprising: receiving identification data extracted from a user endpoint device that is transmitting the electronic communication;determining the known identity from the identification data extracted from the user endpoint device;creating a correlation between the known identity and the user identification data extracted from the electronic communication; andstoring the correlation in a database.

3. The method of claim 1, further comprising: updating the correlation strength based on at least one of how often the association is detected or how many times the association has been detected.

4. The method of claim 2, wherein the user endpoint device is selected from a group consisting of a personal digital assistant, cellular telephone, laptop computer, or personal computer.

5. The method of claim 1, wherein: the electronic communication is in a format type selected from a group consisting of an electronic mail message, an instant message, or a text message; andthe user identification information extracted from the electronic communication is selected from a group consisting of an electronic mail address, an instant message handle, an internet protocol (IP) address from which the electronic communication was sent, or an online social network identification.

6. The method of claim 1, wherein the known identity is derived from a corporate directory system.

7. The method of claim 1, further comprising: responding to a request for an identity report with the known identity, the identity report for determining whether an information transfer associated with the known identity is authorized in accordance with a data loss prevention policy.

8. A system comprising: a memory and a processing device coupled to the memory, wherein the processing device is configured to execute an identification data receipt engine and an identification correlation engine;the identification data receipt engine, configured to receive user identification data extracted from an electronic communication, the user identification data corresponding to an unknown identity of a sender of the electronic communication; andthe identification correlation engine, configured to: determine a known identity for the sender using the user identification data extracted from the electronic communication;associate the known identity with the unknown identity of the sender of the electronic communication, an association between the known identity and the unknown identity being maintained to determine whether parties of subsequent information transfers are authorized to participate in the information transfers;determine a measure of correlation strength for the association between the known identity and the unknown identity based on at least one of how often the association is detected and how many times the association has been detected, wherein the correlation strength is maintained with the association; andtransmit the known identity as the sender of the electronic communication and the measure of correlation strength to a communications data monitoring system to monitor information content to detect policy violation incidents.

9. The system of claim 8, further comprising: the identification data receipt engine to receive identification data extracted from a user endpoint device that is transmitting the electronic communication;the identification correlation engine to determine the known identity from the identification data extracted from the user endpoint device and create a correlation between the known identity and the user identification data extracted from the electronic communication; anda database to store the correlation.

10. The system of claim 8, further comprising: the identification correlation engine to update the correlation strength based on at least one of how often the association is detected or how many times the association has been detected.

11. The system of claim 9, wherein the user endpoint device is selected from a group consisting of a personal digital assistant, cellular telephone, laptop computer, or personal computer.

12. The system of claim 8, wherein: the electronic communication is in a format type selected from a group consisting of an electronic mail message, an instant message, or a text message; andthe user identification information extracted from the electronic communication is selected form a group consisting of an electronic mail address, an instant message handle, an internet protocol (IP) address from which the electronic communication was sent, or an online social network identification.

13. The system of claim 8, wherein the known identity is derived from a corporate directory system.

14. The system of claim 8, further comprising: a reporting engine, to be executed by the processing device, to respond to a request for an identity report with the known identity, the identity report for determining whether an information transfer associated with the known identity is authorized in accordance with a data loss prevention policy.

15. A non-transitory computer readable storage medium that provides instructions, which when executed on a processing device, cause the processing device to perform a method comprising: receiving, by the processing device, user identification data extracted from an electronic communication, the user identification data corresponding to an unknown identity of a sender of the electronic communication;determining, by the processing device, a known identity for the sender using the user identification data extracted from the electronic communication;associating, by the processing device, the known identity with the unknown identity of the sender of the electronic communication, an association between the known identity and the unknown identity being maintained to determine whether parties of subsequent information transfers are authorized to participate in the information transfers;determining a measure of correlation strength for the association between the known identity and the unknown identity based on at least one of how often the association is detected and how many times the association has been detected, wherein the correlation strength is maintained with the association; andtransmitting the known identity as the sender of the electronic communication and the measure of correlation strength to a communications data monitoring system to monitor information content to detect policy violation incidents.

16. The non-transitory computer readable storage medium of claim 15, further comprising: receiving identification data extracted from a user endpoint device that is transmitting the electronic communication;determining the known identity from the identification data extracted from the user endpoint device;creating a correlation between the known identity and the user identification data extracted from the electronic communication; andstoring the correlation in a database.

17. The non-transitory computer readable storage medium of claim 15, further comprising: updating the correlation strength based on at least one of how often the association is detected or how many times the association has been detected.