Patent Description:
Conventional security models protect data and electronic assets by providing a secure perimeter around an organization. The secure perimeter includes not only the data sources, servers, and other analogous assets, but also clients employed by users of the assets. However, applications remain vulnerable, unscrupulous individuals may still obtain copies of sensitive data and administration of the secure perimeter may be complex and expensive. In addition, data sources, such as conventional databases and modem data repositories including distributed message queues, may not be configured for other types of security, such as tokenization of data and federated identity management. Accordingly, an improved mechanism for providing security for data sources is desired.

<CIT> describes techniques for multifactor authentication as a network service. A system, process, and/or computer program product for multifactor authentication as a network service includes monitoring a session at a firewall, applying an authentication profile based on the new session, and performing an action based on the authentication profile.

<CIT> describes analysing a data stream, in a method of determining whether a data stream includes unauthorized data, using a hardware filter to detect a presence of one or more of a first set of patterns in the data stream. It is determined whether a packet in the data stream belongs to one of a plurality of data flows to be further inspected based on the analysis of the data stream by the hardware filter. A set of rules is applied to the packet to produce rule match status data if it is determined that the packet belongs to one of the plurality of data flows to be further inspected. The packet is analyzed to determine if the packet includes unauthorized data using software stored on a computer-readable medium and implemented on a processor if the rule match status data indicates that the packet potentially includes unauthorized data.

<CIT> describes a flow processing facility, which uses a set of artificial neurons for pattern recognition, such as a self-organizing map, in order to provide security and protection to a computer or computer system supports unified threat management based at least in part on patterns relevant to a variety of types of threats that relate to computer systems, including computer networks. Flow processing for switching, security, and other network applications, including a facility that processes a data flow to address patterns relevant to a variety of conditions are directed at internal network security, virtualization, and web connection security. A flow processing facility for inspecting payloads of network traffic packets detects security threats and intrusions across accessible layers of the IP-stack by applying content matching and behavioral anomaly detection techniques based on regular expression matching and self-organizing maps. Exposing threats and intrusions within packet payload at or near real-time rates enhances network security from both external and internal sources while ensuring security policy is rigorously applied to data and system resources. Intrusion Detection and Protection (IDP) is provided by a flow processing facility that processes a data flow to address patterns relevant to a variety of types of network and data integrity threats that relate to computer systems, including computer networks.

"<NPL>, describes application switching and traffic management features and app flow of an application switch that performs application-specific traffic analysis to distribute, optimize and secure Layer <NUM>-Layer <NUM> (L4-L7) network traffic for web applications.

According to an aspect of the present invention, there is provided a method according to claims <NUM> to <NUM>.

According to another aspect of the present invention, there is provided a system according to claims <NUM> to <NUM>.

According to a further aspect of the present invention, there is provided a computer program product according to claims <NUM> and <NUM>.

Any examples and embodiments of the description not falling within the scope of the claims do not form part of the invention as defined by the independent claims.

The systems and methods described herein provide a protection layer, or wrapper, that resides at and functions as a secure perimeter around a data source. Clients (e.g. applications and/or end users) communicate with and are validated by the wrapper to access the data source. Compromised applications (including previously validated applications) may be denied access to the data source. This approach is in contrast to security measures that place a perimeter around the entire organization including the data source and applications. The methods and systems may also track an application's accesses of the data source to determine a context/behavioral baseline for the application. For example, the type of session, browser, APIs, IP address, query attributes etc. may be used to determine a behavioral baseline for accesses of the data source. Subsequent accesses are compared to the baseline to determine whether a current query matches the baseline. If not, additional validation/defense mechanisms may be employed. Application identity, or application fingerprinting, may be incorporated into this behavioral baselining. In some aspects, data masking may also be employed. In data masking, sensitive data are replaced by tokens or format preserving encryption having a similar form but without intrinsic meaning. For example, credit card or social security numbers may be replaced by a different number having the same number of digits. Tokens may also have an expiration time, requestor identification and other data used to track tokens' use. Tokens are used unless/until the sensitive data are needed (e.g. credit card number needed to process a transaction). If the sensitive data are needed, tokens are presented to the data vault and validated to obtain the sensitive data.

In some embodiments, a wrapper functions as a secure perimeter around a data source. The wrapper includes a dispatcher and a number of services that communicate with the dispatcher. The dispatcher may be a Layer <NUM> component that intercepts accesses of the data source. Both incoming accesses and outgoing data may be intercepted by the dispatcher. The dispatcher is data agnostic so can be deployed across a variety of data sources. The dispatcher may hold packets (step mode) or immediately forward packets to/from the data source (stream mode) but does not inspect the packets. The dispatcher also provides packets to the services. The services perform deeper inspection of the packets intercepted by the dispatcher. Services may provide one or more functions including but not limited to: authentication of the user/requester of the data source, query analysis, multifactor authentication, tokenization of data, rewriting, caching and behavioral baselining (using collectors), federated identity management and other functionality. In some embodiments, services may include Layer <NUM> (application layer) components. For example, for authentication, the service may inspect the user's credentials (e.g. user id and password and/or certificate) for that data source and only allow access to the data source if the user's credentials are validated. One or more of these services can be used together. This approach is in contrast to security measures that place a perimeter around the entire organization including the data source and applications or which attempt to manage the data source/organization using Layer <NUM> components.

In addition to the wrapper at the data source, collectors may be used at some/all of the clients using the data repository/data source. Collectors can be present for some or all clients having applications issuing queries to the data source. For example, collectors can be attached to applications for end users as well as in microservices utilized by end users. A collector intercepts a communication (e.g. a query or method call) from the application and examines the state of the application. For example, the type of session, get/put/post/delete commands, APIs, IP address, query attributes, method calls, order of queries and/or other information may be detected by the collector. These represent the context of the query, or state of the application/client issuing the query. The collectors attach this context to the query. In the case of microservices/multiple applications pass a query before the query is sent to a database. For example, one microservice may issue a query and pass the query to a second microservice. The second microservice may add to the query or issue an additional query. The collector for each microservice/application can obtain the context from that microservice/application. The collector also attaches the context from that microservice/application to the query/queries. Thus, multiple contexts may be obtained from multiple microservices/applications for a single access of a data source. The query and context are passed to the wrapper when the data source is accessed. Over multiple accesses, the context can be used by the wrapper (e.g. a service) to determine the behavior (sequence of states/contexts) for each application's accesses of the data source. A model of the behavior (e.g. a Hidden Markov Model) can provide a behavioral baseline. Subsequent accesses are compared to the behavioral baseline to determine whether a current query matches the behavioral baseline. If not, additional validation/defense mechanisms may be employed. For example, access to the data source can be refused and/or multifactor authentication invoked. Collectors and/or behavioral baselining may be used in conjunction with other services.

Requests regarding sensitive data can be sent to a tokenization/encryption service by the dispatcher. The service replaces sensitive data with tokens/format preserving encryption (FPE), or analogous data that is without intrinsic meaning. What is used (tokens or FPE) is configurable on the attribute level. For example, for credit card numbers of a user, FPE can be used. For the social security number of the same user, a token can be used. In some embodiments, the request to store sensitive information can be provided to the service and the value encrypted before storage in the data store. A request to obtain the number can be provided to the service which can decrypt/detokenize if the requester is authorized. Alternatively, the token/FPE can be provided in response to the request. Tokens/FPE can have an expiration time, requestor identification or other information. Tokens are used unless/until the sensitive data are needed (such as a credit card number needed to process a transaction). If the sensitive data are needed, tokens are presented to the data vault and validated to obtain the sensitive data. This validation may require additional, more trusted mechanisms for ensuring the security of the sensitive data. Tokenization can be used in conjunction with behavioral baseline/collectors, multifactor authentication and/or other services.

Multifactor authentication may also be performed using a service. In some embodiments, the dispatcher is placed in step mode, to hold packets instead of directly forwarding to a data source. The dispatcher also provides packets to the service, which controls multi-factor authentication. The service performs multifactor authentication (e.g. requiring a code to be sent to a separate device and input) or accesses a third party multifactor authentication service. Once multifactor authentication is completed, the dispatcher is placed in stream mode, allowing the user to communicate with the data source. Thus, the data agnostic dispatcher can provide multifactor authentication across a number of different data sources, such as databases that do not traditionally support multifactor authentication.

The dispatcher can forward requests/queries to an analyzer service that performs query analysis. The analyzer service examines/parses the queries and emits a structure that describes the query. In some embodiments, the structure is an abstract syntax tree. However, other structures may be used. The structure can be used to determine whether the query represents an attack, (e.g. to obtain unauthorized information) to determine whether the query will adversely affect performance. For example, queries which include wildcards or tautologies in users' names can result in exfiltration of sensitive information. Queries that are missing a where clause can adversely affects database performance. Such queries may be identified. The packet including the query can then be stopped or the query can be canceled. Further, the structure emitted by the query analyzer may be used to log or otherwise store information about the queries. For example, the structure may be used to identify and log features of the query that may be of interest. Such information may be used in conjunction with analytics to examine use of the data source. In some embodiments, the information regarding queries that is logged can be indexed and may include only information previously identified as sensitive. For example, the tables, columns in tables, and data entries corresponding to the identified sensitive information may be logged. Further, such information redacted so that certain information, such as names and/or social security numbers, are not included in the log.

Another service provided may include query rewriting, which may be used with query analysis. Queries that may adversely affect performance can be rewritten. For example, a limit may be added so that too many results are not returned, a tautology removed, and/or other portions of the query rewritten to improve performance.

A service can be used for federated identity management (for example via lightweight directory access protocol (LDAP)). An end user requests access to the data repository/database and provides the directory access credentials via the wrapper. The dispatcher provides the request to a service controlling federated identity management. The wrapper/service determines whether the end user exists on a directory access server (e.g. an LDAP server), authenticates the end user's credentials on the directory access server and determines the groups to which the end user belongs. The service uses the group information to access the data repository as a proxy for the end user.

A method and system for performing at least one service are disclosed. The method and system include receiving a communication for a data source at a wrapper. The wrapper includes a dispatcher and at least one service. The dispatcher receives the communication and is data agnostic. The method and system also include providing the communication from the dispatcher to the data source and to the at least one service. The at least one service inspects the communication and may perform additional functions. In some embodiments, the dispatcher is an open systems interconnection (OSI) Layer <NUM> dispatcher and the service(s) include OSI Layer <NUM> service(s). In some embodiments, the method and system also include performing at least one function by the at least one service based on the communication. The at least one function may include one or more of authentication services, multifactor authentication, tokenization of data, encryption of data, query analysis, behavioral baselining, and federated identity management. For example, the communication may be generated at a client and service(s) may include an authentication service. In such embodiments, the method and system further include determining whether the client is authorized to access the data source using the authentication service and preventing access to the data source if the client is not authorized to access the data source. For example, the communication may be provided to the data source only if the authentication service determines the client is authorized to access the data source. In some embodiments, the communication to the data source from the dispatcher and recalled before processing by the data source if the authentication service determines the client is not authorized to access the data source. In some embodiments, the communication is generated at a client and includes a first communication. The service(s) include an authentication service the dispatcher is in a step mode for the first communication from the client. In such embodiments the first communication may be provided to the authentication service without forwarding the first communication to the data source (step mode). The authentication service may use the first communication to determine whether the client is authorized to access the data source. If it is determined that the client is not authorized to access the data source, access to the data source by the client may be prevented by terminating a connection to the client. If it is determined that the client is authorized, then the first communication is provided from the dispatcher to the data source. The dispatcher is also placed in a stream mode. Upon receiving additional communication(s) from the client, the dispatcher, automatically forwards the at least one additional communication from the dispatcher to the data source.

A method and system that may utilize behavioral baselining are disclosed. The method and system include receiving, at the wrapper, a communication and a context associated with the communication from a client. The communication is for a data source. The wrapper includes the dispatcher and the service. The method and system also include providing the context from the dispatcher to the service. In some embodiments, the method and system use the service to compare the context to a behavioral baseline for the client. The behavioral baseline incorporates a plurality of contexts previously received from the client. The method and system also permit the client access the data source only if the context is consistent with the behavioral baseline. The behavioral baseline may also be updated based on the context. In some embodiments, the communication is intercepted at the client using a collector. The collector determines the context of the client and attaches the context to the communication. In some embodiments, the method and system include receiving, at the dispatcher and from the client, additional communication(s) and additional context(s) associated with the additional communication(s). The additional communication(s) are for the data source. The additional context(s) are provided from the dispatcher to the service. The service compares the context and additional context(s) to the behavioral baseline for the client. In some embodiments, the client is allowed to access the data source only if the context and the additional context(s) are consistent with the behavioral baseline. In some embodiments, the method and system also include receiving additional context(s) associated with the communication from additional client(s). The additional context(s) are also provided from the dispatcher to the service. In such embodiments, the service compares the context and the additional context(s) to the behavioral baseline for the client.

A method and system for anonymizing data are disclosed. The method and system include receiving, at the wrapper, a request to store data in a data source. The method and system also include providing the request from the dispatcher to the at least one service and anonymizing, at the service(s), the data to provide anonymized data. The anonymized data may be provided to the data source. In some embodiments, the request includes the data and additional data. In such embodiments, the anonymizing further includes identifying the data to be anonymized. The anonymizing may include tokenizing and/or encrypting the data. The tokenizing and/or encrypting may be selected based upon a policy for the data. In some embodiments, the encryption uses format preserving encryption. In some embodiments, the method and system further include receiving, from a requester, an access request for the data. The requester is authenticated. If the requester is authorized to receive the data, the method and system include de-anonymizing the anonymized data and providing de-anonymized data to the requester. If the requester is authorized to receive the anonymized data, the method and system include providing the anonymized data.

A method and system for performing authentication are described. The method and system include receiving, from a client, a communication for a data source at the wrapper. The communication is provided from the dispatcher to the service. The service determines whether the client is authorized to access the data source. In some embodiments, the service determines whether the client is authorized by calling a multi-factor authentication (MFA) utility. The method and system also include receiving, from the MFA utility, a success indication. The success indication indicates whether authentication by the MFA utility is successful. In some embodiments, the MFA utility is a third-party MFA utility. The method and system may also include preventing access to the data source if the success indication indicates that the authentication is unsuccessful. Preventing access may include providing the communication to the data source from the dispatcher and recalling the communication before processing by the data source if the authentication indication indicates the authentication is unsuccessful. In some embodiments, the communication includes a first communication and the dispatcher is in a step mode for the first communication. In such embodiment, the preventing access may include providing the first communication to the service without forwarding the first communication to the data source. Preventing access to the data source may include terminating a connection to the client if the success indication indicates that the authentication is unsuccessful. In addition, the first communication may be forwarded from the dispatcher to the data source if the success indication indicates that the authentication is successful. The dispatcher may be placed in a stream mode if the success indication indicates that the authentication is successful. At least one additional communication from the client may be received at the dispatcher. Such additional communications are automatically forwarded from the dispatcher to the data source if the success indication indicates that the authentication is successful. In some embodiments, the dispatcher is an open systems interconnection (OSI) Layer <NUM> dispatcher and wherein the at least one service includes at least one OSI Layer <NUM> service.

A method and system for performing query analysis are described. The method and system include receiving a query for a data source at the wrapper. The method and system also include providing the query from the dispatcher to the data source and to the service. The query is analyzed using the service. In some embodiments, analyzing the query further includes parsing the query, providing a logical structure based on the query and analyzing the logical structure. In some embodiments, a log is provided based on the logical structure. The log may also be analyzed. The method and system may include receiving at least one of an identification of sensitive data and sensitive data policies. In some such embodiments, providing the log further includes redacting a portion of the log based on the sensitive data policies and the identification of the sensitive data. The method and system may prevent access to the data source if the analysis of the query indicates the query is an attack. In some embodiments, the method and system rewrite the query if the analysis of the query indicates the query adversely affects performance. In some embodiments, the analysis of the query indicates that data for a response to the query is in a cache. In such embodiments, the method and system may provide the data from the cache.

A method and system for performing federated identity management are described. The method and system include receiving a communication for a data source at a wrapper. The wrapper includes a dispatcher and a service. The dispatcher receives the communication and is data agnostic. The communication corresponds to end user credentials for an end user. The method and system include providing the communication from the dispatcher to the data source and to the service. The method and system also use the service to authenticate the end user based on the end user credentials and utilizing federated identity management. In some embodiments, the method and system also include accessing the data source by the wrapper as a proxy for the end user if the end user is authenticated using the federated identity management. The end user activities for the data source may also be logged. In some embodiments, authenticating the end user includes providing the end user credentials to a federated identity management data source. The federated identity management data source may be searched for group(s) to which the end user belongs. In some embodiments, a read only binding of the service to the federated identity management data source is performed. In such embodiments, the federated identity management data source may be searched for the end user using the read only binding. If the end user is authenticated, the method and system may include binding the service to the federated identity management data source as a proxy for the end user. Access to the data source may be prevented if the end user is not authenticated utilizing the federated identity management.

<FIG> is a diagram depicting an exemplary embodiment of a system <NUM> utilizing a protective layer between clients and data sources. System <NUM> includes data sources <NUM> and <NUM>, clients <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> (collectively clients <NUM>) and wrapper <NUM>. Although two data sources <NUM> and <NUM>, three clients <NUM> and one wrapper <NUM> are shown, in another embodiment, different numbers of data sources, clients, and/or wrappers may be used. Data sources <NUM> and <NUM> may be databases, data stores, data vaults or other data repositories. Clients <NUM> may be computer systems for end users and/or include applications which provide requests, or queries, to data sources <NUM> and <NUM>. Clients <NUM> may be part of the same organization as the data sources <NUM> and <NUM> or may be outside users of data sources <NUM> and <NUM>. For example, clients <NUM> and data sources <NUM> and <NUM> may be part of the same business organization coupled by an internal network. In other embodiments, clients <NUM> may be outside users of data sources <NUM> and <NUM> connected to wrapper <NUM> and/or data sources <NUM> and/or <NUM> via the Internet or other external network. In some embodiments, some clients <NUM> may be external users of data sources <NUM> and <NUM> while other clients <NUM> are part of the same organization as data sources <NUM> and <NUM>.

Wrapper <NUM> provides a protective layer between clients <NUM> and data sources <NUM> and <NUM>. Wrapper <NUM> is configured such that its operation is data agnostic. Thus, wrapper <NUM> may be used with data sources <NUM> and <NUM> that have different platforms, are different databases, or are otherwise incompatible. Wrapper <NUM> is so termed because although depicted as residing between clients <NUM> and data sources <NUM> and <NUM>, wrapper <NUM> may be viewed as enclosing, or forming a secure perimeter around data sources <NUM> and <NUM>. Stated differently, clients <NUM> cannot bypass wrapper <NUM> in order to access data sources <NUM> and <NUM> in at least some embodiments. For example, a security group may be created for data sources <NUM> and <NUM>. Dispatcher <NUM>/wrapper <NUM> may be the only member of the security group. Thus, clients <NUM> may access data sources <NUM> and <NUM> only through wrapper <NUM>. Clients <NUM> connecting to wrapper <NUM> may be internal or external to an organization. Therefore, wrapper <NUM> need not reside at the perimeter of an organization or network. Instead, wrapper <NUM> may reside at data sources <NUM> and <NUM>. Stated differently, wrapper <NUM> may provide the final or only security for requests for data source <NUM> and <NUM> and need not provide security for other components of the organization. Thus, requests made by clients <NUM> may be passed directly from wrapper <NUM> to data sources <NUM> and <NUM> via a network.

Wrapper <NUM> provides security and other services for data sources <NUM> and <NUM> and clients <NUM>. To do so, wrapper <NUM> includes dispatcher <NUM> and services <NUM>-<NUM> and <NUM>-<NUM> (collectively services <NUM>). Dispatcher <NUM> is data agnostic and in some embodiments is a transport layer component (e.g. a component in Layer <NUM> of the Open Systems Interconnection (OSI) model). Dispatcher <NUM> thus performs limited functions and is not a Layer <NUM> (application layer) component. In particular, dispatcher <NUM> receives incoming communications from clients <NUM>. As used herein, a communication includes a request, a query such as a SQL query, or other transmission from clients <NUM> to access data source <NUM> or <NUM>.

Dispatcher <NUM> also provides the requests to the appropriate data source(s) <NUM> and/or <NUM> and the appropriate service(s) <NUM>-<NUM> and/or <NUM>-<NUM>. However, dispatcher <NUM> does not inspect incoming communications from clients <NUM> other than to identify the appropriate data source(s) <NUM> and/or <NUM> and corresponding service(s) <NUM> for the communication. Dispatcher <NUM> does not make decisions as to whether communications are forwarded to a data source or service. For example, a communication from a client <NUM> may include a header indicating the data source <NUM> desired to be accessed and a packet including a query. In such a case, dispatcher <NUM> may inspect the header to identify the data source <NUM> desired to be accessed and forwards the packet to the appropriate data source <NUM>. Dispatcher <NUM> also provides the packet to the appropriate service(s) <NUM>. However, dispatcher <NUM> does not perform deep inspection of the packet. Instead, the appropriate service(s) inspect the packet. In some embodiments, dispatcher <NUM> provides the communication to the appropriate service(s) <NUM> by storing the packet and providing to service(s) <NUM> a pointer to the storage location.

In some embodiments, dispatcher <NUM> holds communications (e.g. packets) while service(s) <NUM> perform their functions. In other embodiments, dispatcher <NUM> directly forwards the communications to data source(s) <NUM> and/or <NUM> and services <NUM> separately perform their functions. In some embodiments, whether dispatcher <NUM> holds or forwards communications depends upon the mode in which dispatcher <NUM> operates. For example, in a step mode, dispatcher <NUM> may store some or all of the communication from client <NUM>-<NUM> without forwarding the communication to data sources <NUM> and <NUM>. In such a mode, dispatcher <NUM> only forwards the communication to a data source if instructed to do so by the appropriate service <NUM> or if placed into stream mode by the appropriate service <NUM>. Although not forwarding the communication to a data source, dispatcher <NUM> does provide the communication to service <NUM>-<NUM>, for example for client <NUM>-<NUM> to be authenticated and/or for other functions. If client <NUM>-<NUM> is authenticated, dispatcher <NUM> may be placed in stream mode by service <NUM>-<NUM>. Consequently, dispatcher <NUM> forwards the communication to the appropriate data source(s) <NUM>. Because dispatcher <NUM> is now in stream mode, subsequent communications from client <NUM>-<NUM> may then be forwarded by dispatcher <NUM> directly to the appropriate data source(s) <NUM> and/or <NUM>, even if the subsequent communications are also provided to a service <NUM> for other and/or additional functions. Thus, dispatcher <NUM> may provide the communication to the data source(s) as received/without waiting for a response from a service <NUM>.

In some embodiments, responses from data source(s) <NUM> and/or <NUM> are also inspected by wrapper <NUM> and provided to clients <NUM> only if the responses are authorized. As used herein, a response from a data source may include data or other transmission from the data source to the client requesting access. In other embodiments, responses from data source(s) <NUM> and/or <NUM> may bypass wrapper <NUM> and be provided directly to clients <NUM>. This is indicated by the dashed line from data source <NUM> to client <NUM>-<NUM>. In the embodiment shown, therefore, data source <NUM> may bypass wrapper <NUM> and provide responses directly to client <NUM>-<NUM>.

Services <NUM> provide security and other functions for data sources <NUM> and <NUM> and clients <NUM>. For example, services <NUM> may include one or more of authentication, query analysis, query rewriting, caching, tokenization and/or encryption of data, caching, advanced or multifactor authentication, federated identity management, and/or other services. Further, one or more of the services described herein may be used together. Services <NUM> perform more functions than dispatcher <NUM> and may be application layer (Layer <NUM>) components. In contrast to dispatcher <NUM>, services <NUM> may perform a deeper inspection of communications from clients <NUM> in order to provide various functions. The services <NUM> performing their functions may thus be decoupled from forwarding of communications to data source(s) <NUM> and/or <NUM> by dispatcher <NUM>. If a client or communication is determined by a service <NUM> to be unauthorized or otherwise invalid, the communication may be recalled, or canceled, from data source(s) <NUM> and/or <NUM> and connection to the client terminated. The communication may be recalled despite the decoupling of tasks performed by services <NUM> with forwarding of communications by dispatcher <NUM> because data sources <NUM> and <NUM> typically take significantly more time to perform tasks than services <NUM>. The time taken by data source <NUM> and <NUM> may be due to issues such as transmission over a network from wrapper <NUM> to data sources <NUM> and <NUM>, queues at data sources <NUM> and <NUM>, and/or other delays.

In some embodiments, services <NUM> may perform authentication. For example, suppose service <NUM>-<NUM> validates credentials of clients <NUM> for data sources <NUM> and <NUM>. In some such embodiments, service <NUM>-<NUM> may simply employ a username and password combination. In other embodiments, multifactor authentication (MFA), certificates and/or other higher level authorization is provided by one or more services <NUM>. Such authentication is described herein. However, dispatcher <NUM> may still be a data agnostic component, such as a Layer <NUM> component.

In some embodiments, this separation of functions performed by dispatcher <NUM> and services <NUM> may be facilitated by routines or other lightweight process(s). For example, a client such as client <NUM>-<NUM> may request access to data source <NUM> via a particular port. Wrapper <NUM> may utilize listener(s) (not shown in <FIG>) on the ports to identify requests for data sources <NUM> and <NUM>. In response to the request for access, a connection to the client <NUM>-<NUM> is established for the wrapper <NUM> on that port and a routine corresponding to the connection generated. In some embodiments, the routine is responsible for that connection only. The communication from client <NUM>-<NUM> is also provided to dispatcher <NUM>. Dispatcher <NUM> provides the communication to the appropriate service(s) <NUM> for authentication, for example via a message bus (not shown in <FIG>). Dispatcher <NUM> may hold (in step mode) or forward (in stream mode) the communication to the data source(s) <NUM> and/or <NUM>. If client <NUM>-<NUM> is not authenticated or is later determined by service(s) <NUM> to be unauthorized, then the service(s) <NUM> indicates this to dispatcher <NUM>. For example, service(s) <NUM> may provide a message to dispatcher <NUM> via the message bus that client <NUM>-<NUM> is not authorized/that the corresponding routine has an unauthorized connection. Dispatcher <NUM> communicates with the corresponding routine, which terminates the connection to client <NUM>-<NUM>. Thus, connections to clients <NUM> may be securely managed using data agnostic, Layer <NUM> dispatcher <NUM>.

Using system <NUM> and wrapper <NUM>, data sources <NUM> and <NUM> may be secured and other features may be provided via service(s) <NUM>. Because of the use of data agnostic dispatcher <NUM>, wrapper <NUM> may function with a variety of data sources <NUM> and <NUM> that do not share a platform or are otherwise incompatible. Deployment of wrapper <NUM>, for example either in the cloud or on premises, does not require changes in existing code. Consequently, implementation of wrapper <NUM> may be seamless and relatively easy for developers. Further, wrapper <NUM> need not protect every component within a particular organization. Instead, only selected data sources may be protected. Use of services <NUM> for security as described herein may be both more effective at securing sensitive data and less expensive because data sources may not significantly increase in number even when the number of applications that access the data sources grows significantly. Further, utilizing services <NUM>, the level of security and/or functions provided by wrapper <NUM> may differ for different data sources. Additional functionality may also be provided by services <NUM>.

<FIG> is a diagram depicting another exemplary embodiment of a system <NUM> utilizing a protective layer between clients and data sources. System <NUM> is analogous to system <NUM> and includes components that are labeled similarly. System <NUM> indicates that multiple wrappers having different services may be used. Thus, system <NUM> includes data sources <NUM>-<NUM>, <NUM>-<NUM> (collectively <NUM>) and <NUM>, clients <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> (collectively clients <NUM>) and wrappers 210A and 210B (collectively wrappers <NUM>). Although three data sources <NUM>-<NUM>, <NUM>-<NUM> and <NUM>, three clients <NUM> and two wrappers <NUM> are shown, in another embodiment, different numbers of data sources, clients, and/or wrappers may be used. Data sources <NUM>-<NUM>, <NUM>-<NUM> and <NUM> and clients <NUM> are analogous to data sources <NUM> and <NUM> and clients <NUM>, respectively. Wrappers 210A and 210B are analogous to wrapper <NUM>. Thus, wrapper 210A includes dispatcher 212A and services <NUM>-1A and <NUM>-2A (collectively services 214A). Similarly, wrapper 210B includes dispatcher 212B and services <NUM>-1B, <NUM>-2B and <NUM>-3B (collectively services <NUM>). Services 214A may differ from or be included in services 214B. Wrapper 210A controls accesses to data sources <NUM>, while wrapper 210B controls accesses to data source <NUM> in a manner analogous to described elsewhere herein. In general, one wrapper having multiple services may function for all the data sources in an organization. However, as depicted in <FIG>, nothing prevents the use of multiple wrappers. Further, although wrappers 210A and 210B are shown as controlling access to different data sources <NUM> and <NUM>, in other embodiments, wrappers may control the same data source. For example, in another embodiment, wrapper 210B might serve both data source <NUM>-<NUM> and data source <NUM>.

<FIG> is a diagram depicting another exemplary embodiment of a system <NUM> utilizing a protective layer between clients and data sources. System <NUM> is analogous to systems <NUM> and <NUM> and includes components that are labeled similarly. System <NUM> also includes collector <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> (collectively collectors <NUM>). Thus, system <NUM> includes data sources <NUM> and <NUM>, clients <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> (collectively clients <NUM>) as well as client <NUM>-<NUM> and wrapper <NUM>. Although two data sources <NUM> and <NUM>, four clients <NUM> and one wrapper <NUM> are shown, in another embodiment, different numbers of data sources, clients, and/or wrappers may be used. Data sources <NUM> and <NUM> and clients <NUM> are analogous to data sources <NUM> and <NUM> and clients <NUM>, respectively. Wrapper <NUM> is analogous to wrapper <NUM>. Thus, wrapper <NUM> includes dispatcher <NUM> and services <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> (collectively services <NUM>). Wrapper <NUM> controls accesses to data sources <NUM> and <NUM>. Also shown are utilities <NUM>-<NUM> and <NUM>-<NUM> that might be used by services <NUM>. For example, service <NUM>-<NUM> might perform authentication and multifactor authentication using utility <NUM>-<NUM>. Service <NUM>-<NUM> may perform federated identity management using utility <NUM>-<NUM>. Other and/or additional utilities may be used in connection with system <NUM>, as well as with system(s) <NUM> and/or <NUM>. Service <NUM>-<NUM> might perform query analysis as described herein. Service <NUM>-<NUM> might perform behavior modeling based on inputs from collectors <NUM>. Service <NUM>-<NUM> may perform tokenization and/or encryption of sensitive data. Service <NUM>-<NUM> may rewrite queries based on the analysis performed by service <NUM>-<NUM>. Alternatively, service <NUM>-<NUM> might also rewrite queries. Thus, service <NUM>-<NUM> might perform another function such as caching. Other services not described herein may also be provided. Two or more services may be used together in some embodiments.

Collectors <NUM> reside on some clients <NUM>. In some embodiments, each of the clients <NUM> includes a collector. In other embodiments, as shown in <FIG>, not all clients <NUM> include a collector. In some embodiments, none of clients <NUM> includes a collector. For example, clients <NUM> may include end users, applications, and/or microservices utilized by end users. Thus, clients <NUM> may pass communications to each other prior to the communication being provided to wrapper <NUM>. This is indicated by dotted line between client <NUM>-<NUM> and client <NUM>-<NUM>. Collectors <NUM> intercept communications from clients <NUM> and append onto the communication a state of the client/application issuing the communication. For example, collector <NUM>-<NUM> may intercept a query or method call from the application on client <NUM>-1and examine the state of the application. The type of session, get/put/post/delete commands, APIs, IP address, query attributes, method calls, order of queries etc. may be detected by collector <NUM>-<NUM>. These represent the context of the query/communication. Collectors <NUM> attach this context to the query/communication from the corresponding clients <NUM>. In the case of microservices/multiple applications passing a query before the query is sent to a data source, the collectors <NUM> for each of the microservice/applications <NUM> may apply the context from that microservice/application. For example, a query passed from client <NUM>-<NUM> to client <NUM>-<NUM> and then to wrapper can include a first context provided by collector <NUM>-<NUM> and a second context provided by collector <NUM>-<NUM>. If one or more of clients <NUM> being passed a query does not include a collector, then that client simply does not attach the context from the client. For example, if a query is passed from client <NUM>-<NUM> to client <NUM>-<NUM>, then to client <NUM>-<NUM>, a first context from collector <NUM>-<NUM> and a second context from collector <NUM>-<NUM> are attached to the query. In such embodiments, no context is attached by client <NUM>-<NUM> because no collector is present for client <NUM>-<NUM>. The query and context(s) are passed to wrapper <NUM> when data source <NUM> or <NUM> is accessed. Over multiple accesses, the contexts can be used by wrapper <NUM> (e.g. a service such as service <NUM>-<NUM>) to determine the behavior (sequence of states/contexts) for each application's accesses of data source(s) <NUM> and/or <NUM>. A model of the behavior (e.g. using a Hidden Markov Model) can provide a behavioral baseline. Subsequent accesses are compared to the baseline by service <NUM>-<NUM> to determine whether a current query/communication matches the baseline. If not, additional validation/defense mechanisms may be employed. For example, the connection may be terminated as described herein, access to data source <NUM> and/or <NUM> may be otherwise denied and/or additional forms of validation such as MFA may be utilized via services <NUM>.

System <NUM> may provide the benefits of systems <NUM> and/or <NUM>. In addition, system <NUM> may improve security via collectors <NUM>. Further, end-to-end visibility, from clients <NUM> to data sources <NUM> and <NUM>, may be provided via wrapper <NUM>. Thus, performance of system <NUM> may be improved.

<FIG> is a flow chart depicting an exemplary embodiment of method <NUM> for authenticating a client for a data source. Method <NUM> is described in the context of system <NUM>. However, method <NUM> may be used in connection with other systems including but not limited to systems <NUM> and <NUM>. For simplicity, certain steps of method <NUM> are depicted. Method <NUM> may include other and/or additional steps and substeps. Further, the steps of method <NUM> may be performed in another order including performing portions or all of some steps in parallel. Method <NUM> may be carried out each time a client commences a session for communication with a data source.

Dispatcher <NUM> of wrapper <NUM> receives a communication requesting access to one or more data sources from a client, at <NUM>. For example, dispatcher <NUM> may receive a communication requesting access to data source <NUM> from client <NUM>-<NUM>. The communication may be received at dispatcher <NUM> after a connection between wrapper <NUM> and client <NUM>-<NUM> is established and a corresponding routine or other corresponding lightweight process generated. In addition to identifying data source <NUM> and client <NUM>-<NUM>, the request may also include credentials for client <NUM>-<NUM>. In some embodiments, at the start of method <NUM>, dispatcher <NUM> is in step mode. At <NUM>, therefore, dispatcher <NUM> provides the communication from client <NUM>-<NUM> to service <NUM>-<NUM>, which performs authentication. For example, dispatcher <NUM> may send the payload of the communication to service <NUM>-<NUM> via a message bus (not separately labeled in <FIG>). However, because dispatcher <NUM> is in step mode, dispatcher <NUM> does not also forward the communication to the requested data source <NUM>. Further, because dispatcher <NUM> is a data agnostic component such as a Layer <NUM> component, dispatcher <NUM> does not perform a deeper inspection of the communication. Instead, dispatcher <NUM> simply holds (e.g. stores) the communication because dispatcher <NUM> is in step mode. If dispatcher <NUM> were in stream mode, dispatcher <NUM> would also forward the packet to the appropriate data source <NUM>.

Service <NUM>-<NUM> performs authentication of client <NUM>-<NUM>, at <NUM>. In some embodiments, a certificate and/or other credentials such as a username and password may be used to perform authentication. In some embodiments, MFA (described in further detail below) may be used. In addition, if collectors such as collectors <NUM> are present in the system, the context of the communication provided by client <NUM>-<NUM> may be used in authentication at <NUM>. For example, the context appended to the communication by a collector <NUM> may be compared to a behavior baseline modeled by system <NUM> from previous communications by client <NUM>-<NUM> to determine whether the context sufficiently matches previous behavior. Other and/or additional authentication mechanisms may be used in some embodiments.

If the client requesting access is not authenticated, then access to the data source is prevented, at <NUM>. For example, the routine corresponding to the connection with client <NUM>-<NUM> may be notified and the connection terminated. Other mechanisms for preventing access may also be used. The communication held by dispatcher <NUM> is also discarded. In other embodiments, if dispatcher <NUM> had forwarded the communication to data source <NUM>, then the communication is recalled at <NUM>.

If the client is authenticated, then at <NUM>, dispatcher <NUM> is placed in stream mode at <NUM>. As a result, the communication being held is forwarded to the selected data source <NUM> at <NUM>. In addition, future communications corresponding to the authenticated connection with client <NUM>-<NUM> are forwarded to the selected data source <NUM> and appropriate service(s) <NUM>, at <NUM>. For example, service <NUM>-<NUM> may provide a message to dispatcher <NUM> changing dispatcher <NUM> from step mode to stream mode at <NUM>. Consequently, dispatcher <NUM> also forwards the communication to corresponding data source <NUM>. Future communications received at dispatcher <NUM> from client <NUM>-<NUM> via the same connection may be both provided to one of the services <NUM> and to the selected data source <NUM>. Thus, clients <NUM> are allowed to request and receive data from data source <NUM>. However, authentication may still continue. For example, behavioral baselining described herein, periodic requests to revalidate credentials or other mechanisms may be used, at <NUM>. If client <NUM>-<NUM> loses its authentication, then communications from the client to the selected data source may be recalled and further access to the data source blocked, at <NUM>. For example, the routine responsible for the connection to client <NUM>-<NUM> may be notified and the connection terminated. Thus, connection to clients <NUM> may be securely managed using dispatcher <NUM> that is a data agnostic component, such as a Layer <NUM> component.

Using method <NUM>, data sources <NUM> and <NUM> may be secured. Because of the use of data agnostic dispatcher <NUM>, wrapper <NUM> may function with a variety of data sources <NUM> and <NUM> that do not share a platform or are otherwise incompatible. Deployment of wrapper <NUM>, for example either in the cloud or on premises, may require no change in existing code. Consequently, implementation of wrapper <NUM> may be seamless and relatively easy for developers. Further, wrapper <NUM> need not protect every component within a particular organization. Instead, only selected data sources may be protected. Use of services <NUM> for security as described herein may be both more effective at securing sensitive data and less expensive because data sources may not significantly increase in number even when the number of applications that access the data sources grows significantly. Further, utilizing services <NUM>, the level of security and/or functions provided by wrapper <NUM> may differ for different data sources.

<FIG> is a flow chart depicting an exemplary embodiment of method <NUM> for performing one or more services for a client and a data source. Method <NUM> is described in the context of system <NUM>. However, method <NUM> may be used in connection with other systems including but not limited to systems <NUM> and <NUM>. For simplicity, certain steps of method <NUM> are depicted. Method <NUM> may include other and/or additional steps and substeps. Further, the steps of method <NUM> may be performed in another order including performing portions or all of some steps in parallel. In some embodiments, method <NUM> may be considered to be operable once authentication of the client is completed and dispatcher <NUM> is in stream mode.

Dispatcher <NUM> of wrapper <NUM> receives a communication from a client, at <NUM>. For example, dispatcher <NUM> may receive a communication from client <NUM>-<NUM> with a query for data source <NUM>. One or more services <NUM> are desired to be used with the communication. Therefore, dispatcher <NUM> provides the communication from client <NUM>-<NUM> to service(s) <NUM>, at <NUM>. In addition, dispatcher <NUM> forwards the communication to the requested data source <NUM> at <NUM>. Stated differently, dispatcher <NUM> provides the relevant portions of the communication to both the desired data source(s) and service(s). Because dispatcher <NUM> is a data agnostic component such as a Layer <NUM> component, dispatcher <NUM> does not perform a deeper inspection of the communication. Instead, dispatcher <NUM> simply forwards the communication both to the desired data source(s) <NUM> and/or <NUM> and to service(s) <NUM> for further processing.

The desired functions are provided using one or more of the services <NUM>, at <NUM>. This may include inspecting the communication as well as completing other tasks. For example, at <NUM>, services <NUM> may be used for authentication of various types, query analysis, federated identity management, behavioral modeling, query rewriting, caching, tokenization or encryption of sensitive data and/or other processes. Services <NUM> may thus be Layer <NUM> components. However, tasks performed by services <NUM> are decoupled from forwarding of the communication to data sources by dispatcher <NUM>.

Using system method <NUM> and wrapper <NUM>, data sources <NUM> and <NUM> may be secured and other features may be provided via service(s) <NUM>. Because of the use of data agnostic dispatcher <NUM>, wrapper <NUM> may function with a variety of data sources <NUM> and <NUM> that do not share a platform or are otherwise incompatible. Functions performed by services <NUM> are decoupled from forwarding of communications to the data sources by dispatcher <NUM>. Thus, a variety of features may be provided for data sources <NUM> and <NUM> without adversely affecting performance of data sources <NUM> and <NUM>. Consequently, performance of system <NUM> may be improved.

<FIG> is a flow chart depicting an exemplary embodiment of method <NUM> for performing multifactor authentication (MFA) for a client and a data source. Method <NUM> is described in the context of system <NUM>. However, method <NUM> may be used in connection with other systems including but not limited to systems <NUM> and <NUM>. For simplicity, certain steps of method <NUM> are depicted. Method <NUM> may include other and/or additional steps and substeps. Further, the steps of method <NUM> may be performed in another order including performing portions or all of some steps in parallel. In some embodiments, method <NUM> may be considered to be used in implementing <NUM> and/or <NUM> of method <NUM> and/or <NUM>. For the purposes of explanation, suppose service <NUM>-<NUM> provides multi-factor authentication. Method <NUM> may be considered to start after the MFA service <NUM>-<NUM> receives the communication from dispatcher <NUM>. Further, dispatcher <NUM> may be in step mode at the start of method <NUM>. Thus, dispatcher <NUM> may hold the communication instead of forwarding the communication to data source(s). In other embodiments, dispatcher <NUM> may be in stream mode. Dispatcher <NUM> may, therefore, may also provide the communication to the appropriate data sources. MFA may be performed in addition to other authentication, such as certificate or user identification/password based authentication, performed by service <NUM>-<NUM> or another service. Although described in the context of authentication for access to a single data source, in some embodiments, method <NUM> may be used to authenticate client(s) for multiple data sources.

Service <NUM>-<NUM> calls a MFA utility <NUM>-<NUM>, at <NUM>. The MFA utility <NUM>-<NUM> contacted at <NUM> may be a third party MFA such as DUO. Alternatively, the MFA utility <NUM>-<NUM> may be part of the organization to which data source(s) <NUM> and/or <NUM> belong. MFA utility <NUM>-<NUM> performs multi-factor authentication for the requesting client, at <NUM>. For example, suppose end user of client <NUM>-<NUM> has requested access to data source <NUM>. The user identification and password may have been validated by service <NUM>-<NUM>. At <NUM>, the MFA utility <NUM>-<NUM> is called. Thus, the end user is separately contacted by MFA utility <NUM>-<NUM> at <NUM> and requested to confirm the user's by the MFA facility. For example, the end user may be required to enter a code or respond to a prompt on a separate device. As part of <NUM>, service <NUM>-<NUM> is informed of whether the multi-factor authentication by MFA utility <NUM>-<NUM> is successful. Stated differently, as part of <NUM>, service <NUM>-<NUM> receives from MFA utility <NUM>-<NUM> a success indication. The success indication informs MFA utility <NUM>-<NUM> of whether or not MFA authentication was successful.

If the multi-factor authentication by MFA utility <NUM>-<NUM> is successful, then service <NUM>-<NUM> instructs dispatcher <NUM> to forward communications to the requested data source <NUM>, at <NUM>. In some embodiments, in response to receiving a positive success indication (i.e. that MFA authentication is successful), service <NUM>-<NUM> directs dispatcher <NUM> to forward communications to the requested data source <NUM>. In some embodiments, dispatcher <NUM> is instructed to change from step mode to stream mode at <NUM>. Thus, subsequent communications may be provided both to the data source <NUM> and one or more service(s) <NUM>. In other embodiments, dispatcher <NUM> is simply allowed to continue forwarding communications to data source <NUM> at <NUM>. If, however, multifactor authentication was unsuccessful, service <NUM>-<NUM> instructs dispatcher <NUM> to prevent access to the requested data source <NUM>, at <NUM>. For example, in response to receiving a negative success indication (i.e. that MFA authentication is unsuccessful), service <NUM>-<NUM> directs dispatcher <NUM> to prevent access to the requested data source <NUM>. In response, dispatcher <NUM> may instruct the corresponding routine to terminate the connection with the requesting client <NUM>. If the communication has already been forwarded to data source <NUM>, then dispatcher <NUM> also recalls the communication. In some embodiments, dispatcher <NUM> may be instructed to remain in step mode and the client requested to resubmit the credentials and/or another mechanism for authentication used. In some embodiments, other action(s) may be taken in response to MA being unsuccessful.

Using method <NUM> MFA may be provided for data source(s) <NUM> and/or <NUM> in a data agnostic manner. Certain data sources, such as databases typically do not support MFA. Thus, method <NUM> may provide additional security to such data sources without requiring changes to the code of data sources <NUM> and <NUM>. Security of system <NUM> may thus be improved in a simple, cost effective manner.

<FIG> is a flow chart depicting an exemplary embodiment of method <NUM> for performing federated identity management for a client for a data source. Federated identity management allows end users to access various facilities in an organization, such as multiple databases, email, analytics or other applications, based on a group identity and using a single set of credentials. For example, an end user may be a data analyst in a finance department. The end user may thus be considered a member of three groups: employees, data analysts and the finance department. A user identification and password for the end user may allow the end user to access their company/employee email, applications for the finance department, databases including information used by the finance department such as financial projections for the organization, analytics applications accessible by data analysts and other data based on the end user's membership in various groups within the organization. Federated identity management may use protocols such as lightweight directory access protocols (LDAP) and directories defining the groups to which each end user belongs.

Method <NUM> is described in the context of system <NUM>. However, method <NUM> may be used in connection with other systems including but not limited to systems <NUM> and <NUM>. For simplicity, certain steps of method <NUM> are depicted. Method <NUM> may include other and/or additional steps and substeps. Further, the steps of method <NUM> may be performed in another order including performing portions or all of some steps in parallel. In some embodiments, method <NUM> may be considered to be used in implementing <NUM> of method <NUM>. For the purposes of explanation, service <NUM>-<NUM> is considered to provide federated identity management. Method <NUM> may be considered to start after service <NUM>-<NUM> receives the communication from dispatcher <NUM>.

Service <NUM>-<NUM> receives the end user's credentials, at <NUM>. For example, dispatcher <NUM> forwards to service <NUM>-<NUM> a communication requesting access to data source <NUM>. The communication may include the end user's user identification and password for federated identity management. In other embodiments, the end user credentials are otherwise associated with the communication but are provided to service <NUM>-<NUM>. Service <NUM>-<NUM> authenticates the end user with a federated identity management utility or database <NUM>-<NUM>, such as an LDAP directory, at <NUM>. To authenticate the end user the user identification and password are utilized. Service <NUM>-<NUM> searches the federated identity management database <NUM>-<NUM> for the group(s) to which the end user belongs, at <NUM>. Using one or more of the group(s) of which the user is a member, wrapper <NUM> logs onto the data source <NUM> as a proxy for the end user, at <NUM>. The end user may then access data source <NUM> in accordance with the privilege and limitations of the group(s) to which the end user belongs.

Using method <NUM>, federated identity management can be achieved for data source(s) <NUM> and/or <NUM>. Some databases do not support federated identity management. Method <NUM> and wrapper <NUM> having data agnostic dispatcher <NUM> may allow for federated identity management for such databases without changes to the databases. Thus, an end user may be able to access the desired data sources. Further, the organization can manage access to the data sources using groups in the federated identity management database. This may be achieved without requiring changes to data sources <NUM> and <NUM>. Because wrapper <NUM> accesses data sources <NUM> and/or <NUM> as a proxy for the end user, wrapper <NUM> may log activities of the end user. For example federated identity management service <NUM>-<NUM> may store information related to queries performed by the end user as well as the identity of the end user. Thus, despite using federated identity management to allow access to applications and data sources based on groups, the organization may obtain visibility into the activities of individual end users. In addition to improving ease of administration via federated identity management, improved information and control over individuals' use of data sources <NUM> and <NUM> may be achieved.

<FIG> is a flow chart depicting an exemplary embodiment of method <NUM> for performing federated identity management for a client for a data source using an LDAP directory. Method <NUM> is described in the context of system <NUM>. However, method <NUM> may be used in connection with other systems including but not limited to systems <NUM> and <NUM>. For simplicity, certain steps of method <NUM> are depicted. Method <NUM> may include other and/or additional steps and substeps. Further, the steps of method <NUM> may be performed in another order including performing portions or all of some steps in parallel. In some embodiments, method <NUM> may be considered to be used in implementing <NUM> of method <NUM> and/or <NUM>, <NUM> and/or <NUM> of method <NUM>. For the purposes of explanation of method <NUM>, service <NUM>-<NUM> is considered to provide federated identity management via LDAP. Method <NUM> is considered to commence after wrapper <NUM> is provided with a specialized account for LDAP directory <NUM>-<NUM>. The specialized account allows wrapper <NUM> to obtain information from LDAP directory <NUM>-<NUM> that is not available to a typical end user, such as the identification of end users and the groups to which end users belong. In some embodiments, the account is a read only account for wrapper <NUM>.

Service <NUM>-<NUM> binds to the LDAP directory using the read only account at <NUM>. This may occur at some time before receipt of the end user's credentials and the request to access a data source using federated identity management. The binding of service <NUM>-<NUM> with the LDAP directory allows service <NUM>-<NUM> to provide federated identity management services in some embodiments.

A communication requesting access to data source(s) <NUM> and/or <NUM> is received at dispatcher <NUM> and provided to service <NUM>-<NUM> in a manner analogous to <NUM> and <NUM> of method <NUM>. The communication includes the end user's LDAP credentials. Thus, the end user's LDAP credentials are received at service <NUM>-<NUM>. After receiving the end user's LDAP credentials, service <NUM>-<NUM> may search for the end user in the LDAP directory using the read only account, at <NUM>. Searching LDAP directory <NUM>-<NUM> allows service <NUM>-<NUM> to determine whether the user exists in LDAP directory <NUM>-<NUM>. If not, wrapper <NUM> may prevent access to the desired data source(s). If, however, the end user is found at <NUM>, then service <NUM>-<NUM> binds to the LDAP directory as a proxy for the end user, at <NUM>.

Service <NUM>-<NUM> may then request a search for the groups to which the end user belongs, at <NUM>. This is facilitated by the read only account for wrapper <NUM>. Thus, service <NUM>-<NUM> may determine the groups to which the end user belongs as well as the privileges and limitations on each group. A group to be used for accessing the data source(s) <NUM> and/or <NUM> is selected at <NUM>. In some embodiments, service <NUM>-<NUM> ranks groups based upon their privileges. A group having more privileges (e.g. able to access more data sources or more information on a particular data source) is ranked higher. In some embodiments, service <NUM>-<NUM> selects the highest ranked group for the end user. In some embodiments, service <NUM>-<NUM> selects the lowest ranked group. In some embodiments, the user is allowed to select the group. In other embodiments, another selection mechanism may be used.

The desired data source(s) are accessed using the selected group, at <NUM>. Thus, the end user may access data and/or applications based upon their membership in the selected group. Information related to the end user's activities is logged by wrapper <NUM>, at <NUM>. For example, services <NUM>-<NUM> may directly log the end user activities or may utilize another service, such as query analysis, to do so.

Using method <NUM>, an end user may be able to access the desired data sources via federated identity management performed through an LDAP directory. The benefits of federated identity management may thus be achieved. In addition, the end user's actions may be logged. Thus, visibility into the activities of individual end users may be obtained.

<FIG> is a flow chart depicting an exemplary embodiment of method <NUM> for analyzing and logging information related to queries of a data source. Method <NUM> is described in the context of system <NUM>. However, method <NUM> may be used in connection with other systems including but not limited to systems <NUM> and <NUM>. For simplicity, certain steps of method <NUM> are depicted. Method <NUM> may include other and/or additional steps and substeps. Further, the steps of method <NUM> may be performed in another order including performing portions or all of some steps in parallel. In some embodiments, method <NUM> may be considered to be used in implementing <NUM> of method <NUM>. For the purposes of explanation of method <NUM>, service <NUM>-<NUM> is considered to provide query analysis and logging. Thus, a client, such as client <NUM>-<NUM> may be considered to be authenticated for data source(s) <NUM> and/or <NUM> and to perform a query for data on one or both of data sources <NUM> and <NUM>. In some embodiments, the query may be an SQL query.

Wrapper <NUM> receives an identification of information of interest in the data source(s) <NUM> and/or <NUM>, at <NUM>. Also at <NUM>, policies related to the sensitive information are also received. Reception of this information at <NUM> may be decoupled from receiving queries and analyzing queries for the remainder of method <NUM>. For example, owner(s) of data source(s) <NUM> and/or <NUM> may indicated to wrapper <NUM> which tables, columns/rows in the tables, and/or entries in the tables include information that is of interest or sensitive. For example, tables including customer names, social security numbers (SSNs) and/or credit card numbers (CCNs) may be identified at <NUM>. Columns within the tables indicating the SSN, CCN and customer name, and/or individual entries such as a particular customer's name, may also be identified at <NUM>. This identification provides to wrapper <NUM> information which is desired to be logged and/or otherwise managed. Further, policies related to this information are provided at <NUM>. Whether any logging is to be performed or limited is provided to wrapper at <NUM>. For example, any user access of customer tables may be desired to be logged. The policies indicate that queries including such accesses are to be logged. Whether data such as SSNs generated by a query of the customer table should be redacted for the log may also be indicated in the policies.

Wrapper <NUM> receives a query from a client at dispatcher <NUM> and provides the query to service <NUM>-<NUM>, at <NUM>. The query may also be sent from dispatcher <NUM> to the appropriate data source(s) as part of <NUM>. Process <NUM> is analogous to <NUM> and <NUM> of method <NUM>. Thus, the query is received at service <NUM>-<NUM>. Service <NUM>-<NUM> parses a query provided by a client <NUM>, at <NUM>. For example, a client <NUM>-<NUM> may provide a query for data source <NUM> to wrapper <NUM>. Dispatcher <NUM> receives the query and provides the query both to data source <NUM> and to service <NUM>-<NUM>. Service <NUM>-<NUM> parses the query to determine which operations are requested and on what portions of data source <NUM>. Service <NUM>-<NUM> thus emits a logical structure describing the query and based on the parsing, at <NUM>. In some embodiments, the logical structure is an abstract syntax tree corresponding to the query. Each node in the tree may represent a table being searched, operation in the query, as well as information about the operation. For example, a node may indicate a join operation or a search operation and be annotated with limitations on the operation.

The query is logged, at <NUM>. The log may include the end user/client <NUM>-<NUM> that provided the query as well as the query string. In addition, the features extracted from the abstract syntax tree may be logged in a manner that is indexable or otherwise more accessible to analytics. Further, the log may be configured to be human readable. In some embodiments, a JSON log may be used. For example, a list of the operations and tables accessed in the query may be included in the log. Sensitive information such as SSN may be redacted from the log in accordance with the identification of sensitive information and policies relating to sensitive information received at <NUM>. Thus, a placeholder may be provided in the log in lieu of the actual sensitive information accessed by the query. In some embodiments, the logical structure and/or log are analyzed at <NUM>. This process may include analyzing the abstract syntax tree and/or information in the log.

Based on the query analysis and/or log, additional action may be taken by wrapper <NUM>, at <NUM>. For example, a query rewriting service that is part of service <NUM>-<NUM> or a separate service may be employed if it is determined in <NUM> that the log generated in <NUM> indicates that the query may adversely affect performance. For example, limits may be placed on a query, clauses such as an "OR" clause and/or a tautology identified and/or removed. As a result, queries that result in too many rows being returned may be rewritten to reduce the number of rows. If the log or other portion of the query analysis indicates that the query may represent an attack, then access to the data source may be denied at <NUM>. For example, the analysis at <NUM> of the logical structure and log may indicate that the query includes wildcards or tautologies in users' names. The corresponding routine may terminate the connection to the client from which the query originated. If the query has been passed on to data source <NUM>, then the query may be canceled at <NUM>. Unwanted exfiltration of sensitive information may thus be prevented. If the query analysis indicates that a similar query was recently serviced, then some or all of the information for the similar query that already exists in a cache may be used to service the query. If the query can be completely serviced by information in the cache, then the query may be recalled from/canceled before or during servicing by data source <NUM>. Thus, various actions may be taken based upon the analysis of the query by service <NUM>-<NUM>.

For example, suppose as mentioned above that data source <NUM> includes a customer table of customer information having columns of customer names, customer SSNs, customer CCNs, tokenized CCNs (e.g. CCN encrypted with FPE or represented by a token), and customer identifiers (CIDs). Suppose data source <NUM> also includes an order table including a table of customer orders. The table includes a column of order customer identifiers (OCIDs) and multiple columns of orders for each customer identifier. In each order column, the item prices for the order are indicated. The order customer identifier for the order table is the same as the customer identifier in the customer table for data source <NUM>. Query analysis and logging may be performed by service <NUM>-<NUM>.

At <NUM>, service <NUM>-<NUM> is informed that the customer table and the columns of customer names, customer SSNs and (tokenized) customer CCNs are sensitive information for which activity is desired to be logged. Also at <NUM>, service <NUM>-<NUM> is informed that customer names and SSNs are to be redacted from the log. A query of data source <NUM> may be provided to dispatcher <NUM> by end user of client <NUM>-<NUM>. Dispatcher <NUM> forwards the query to data source <NUM> and to service <NUM>-<NUM>. The query is: select object price from customer table join order table on customer identifier = order customer identifier and where name = John Smith (where John is a name of a particular customer). Thus, the query determines the price of objects ordered by John Smith. <FIG> depicts the corresponding abstract syntax tree <NUM> generated from the query at <NUM>. The abstract syntax tree has been annotated for clarity. Nodes <NUM>, <NUM>, <NUM>, <NUM> and <NUM> and lines connecting nodes <NUM>, <NUM>, <NUM>, <NUM> and <NUM> represent the query. From abstract syntax tree <NUM>, a log is generated by service <NUM>-<NUM> at <NUM>. The log indicates that the customer table has been accessed by end user of client <NUM>-<NUM>, that column customer name was read, and the where name = [redacted] was accessed. This information may be provided in a format that is readily usable by analytics, indexable and/or searchable. In some embodiments, the string forming the query may also be provided in the log. However, because they were not identified as being of interest, the order table, CID, OCID and object price are not included in the indexable portion of the log.

Thus, using method <NUM>, performance of system <NUM> may be improved. Method <NUM> may facilitate analysis of queries performed, aid in response to attacks, and/or improve performance of the data source. Because dispatcher <NUM> is data agnostic and may be a transport layer component, this may be achieved without requiring changes to data sources <NUM> and <NUM> while maintaining stability of the data sources <NUM> and <NUM>. Thus, performance and security for system <NUM> may be enhanced.

<FIG> are flow charts depicting exemplary embodiments of methods for utilizing tokenization and/or encryption of sensitive data. <FIG> is a flow chart depicting an exemplary embodiment of method <NUM> for using tokenization and/or encryption for storing data at a data source. Method <NUM> is described in the context of system <NUM>. However, method <NUM> may be used in connection with other systems including but not limited to systems <NUM> and <NUM>. For simplicity, certain steps of method <NUM> are depicted. Method <NUM> may include other and/or additional steps and substeps. Further, the steps of method <NUM> may be performed in another order including performing portions or all of some steps in parallel. In some embodiments, method <NUM> may be considered to be used in implementing <NUM> of method <NUM>.

Method <NUM> may be considered to start after system <NUM> receives policies indicating how sensitive data are to be treated. For example, policies indicating what data are sensitive (e.g. which tables/entries include sensitive data), what clients are allowed to have access to the sensitive data, for what purposes client(s) are allowed to have access to the sensitive data, how the sensitive data are to be anonymized (e.g. tokenized and/or encrypted), and/or other information desired by controller of data sources <NUM> and/or <NUM> have already been received by wrapper <NUM> and provided to the appropriate service(s). Although described in the context of access to a single data source, in some embodiments, method <NUM> may be used for multiple data sources. In some embodiments, the same service fulfills request to store sensitive data and requests to obtain sensitive data. In some embodiments, some service(s) may service requests to store data/tokenize data while other service(s) are used obtain the tokenized data. However, such services communicate in order to service at least some of the requests. In some embodiments, the same service may utilize different types of anonymization (e.g. tokenization and encryption). In other embodiments, different services may be used for different types of anonymization. For example, one service may tokenize data while another service encrypts data. Method <NUM> is described as being used in connection with method <NUM>. In other embodiments, method <NUM> may be used with a different method for accessing encrypted/tokenized data.

A request from a client to store sensitive data at a data source is received by a wrapper, at <NUM>. The dispatcher, which is data agnostic, forwards the request to an encryption/tokenization service for anonymization of the sensitive data desired to be stored, at <NUM>. Based on the policies provided and/or capabilities of the services, the sensitive data is and anonymized, at <NUM>. In some embodiments, the data desired to be stored includes sensitive data desired to be anonymized as well as data that need not by anonymized. In such embodiments, <NUM> also includes identifying the sensitive data to be anonymized. In some embodiments, anonymizing data includes encrypting and/or tokenizing the data. For some sensitive data, encryption such as format preserving encryption (FPE) may be used. For example, CCNs and SSNs may be encrypted using FPE such that the encrypted data has the same number of digits as the CCN and SSN (i.e. such that the format is preserved) but does not have intrinsic meaning. The alphanumeric string having nine members may replace an SSN. Other types of encryption, tokenization, and/or data masking may also be used at <NUM>. Thus, at <NUM> the sensitive data is anonymized. Because policies may be used to determine how and what data are encrypted/tokenized, <NUM> is performed on an attribute level. For example, the CCN of a user may be encrypted by FPE, but the SSN of the same user may be replaced by a token based on the policies used by the encryption/tokenization service. The anonymized data is stored in the data source, at <NUM>. Thus, the anonymized data may be retained in place of the actual sensitive data. In some embodiments, the sensitive data may also be stored, for example in a secure data vault, which may require enhanced authentication to access. Thus, using method <NUM>, sensitive data may be tokenized and/or encrypted and stored using a data agnostic dispatcher.

<FIG> is a flow chart depicting an exemplary embodiment of method <NUM> for accessing tokenized and/or encrypted data from a data source. Method <NUM> is described in the context of system <NUM>. However, method <NUM> may be used in connection with other systems including but not limited to systems <NUM> and <NUM>. For simplicity, certain steps of method <NUM> are depicted. Method <NUM> may include other and/or additional steps and substeps. Further, the steps of method <NUM> may be performed in another order including performing portions or all of some steps in parallel. In some embodiments, method <NUM> may be considered to be used in implementing <NUM> of method <NUM>. Method <NUM> may be considered to start after system <NUM> receives policies indicating how sensitive data are to be treated. For example, policies indicating what data are sensitive (e.g. which tables/entries include sensitive data), what clients are allowed to have access to the sensitive data, for what purposes client(s) are allowed to have access to the sensitive data, how the sensitive data are to be anonymized (e.g. tokenized and/or encrypted), and/or other information desired by controller of data sources <NUM> and/or <NUM> have already been received by wrapper <NUM> and provided to the appropriate service(s). Although described in the context of access to a single data source, in some embodiments, method <NUM> may be used for multiple data sources. In some embodiments, the same service fulfills request to store sensitive data and requests to obtain sensitive data. In some embodiments, some service(s) may service requests to store data/tokenize data while other service(s) are used obtain the tokenized data. However, such services communicate in order to service at least some of the requests. In some embodiments, the same service may utilize different types of anonymization (e.g. tokenization and encryption). In other embodiments, different services may be used for different types of anonymization. For example, one service may tokenize data while another service encrypts data. Method <NUM> is described as being used in connection with method <NUM>. In other embodiments, method <NUM> may be used with a different method for anonymizing data.

A request for the sensitive data stored at data source is received by the wrapper, at <NUM>. The request may come from the same client that stored the data or a different client. Because request(s) for data may be independent of storage, <NUM> through <NUM> may be decoupled from <NUM> through <NUM>. For example, the request may be received at <NUM> at a different time, or may not be received. Thus, methods <NUM> and <NUM> are separately described. The dispatcher provides the request to access sensitive data to encryption/tokenization service, at <NUM>. The request may also be forwarded to the data source storing the anonymized data.

The encryption/tokenization service determines what type of authorization the requestor possesses, at <NUM>. The requester may only be authorized to receive the anonymized (e.g. tokenized/encrypted) data. For example, the requesting client might be a computer system of data scientist associated with system <NUM>. The data scientist/client may be allowed to track use of a credit card number, but not be authorized to know the actual credit card number. The requester may be authorized to receive the original, sensitive data. For example, the requesting client might be a merchant's payment system or the original user's computer systems, both of which may be authorized to receive the de-anonymized (e.g. unencrypted/de-tokenized) sensitive data. However, the requester may be unauthorized to receive either data. For example, the requesting client might be a malicious individual attempting to steal the sensitive data. At <NUM>, therefore, the encryption/tokenization service validates credentials for the requesting client. The encryption/tokenization service may use passwords, certificates, multifactor authentication, behavioral baselining through collector(s) and/or other mechanism(s). Thus, encryption/tokenization service may call another service to perform authentication at <NUM>.

If the requesting client is determined to be authorized to receive the sensitive data, then the anonymized data stored at the data source is retrieved, de-anonymized and provided to client, at <NUM>. For example, encryption/tokenization service may decrypt and/or detokenize the data that was stored in the data source. In another embodiment, instead of or in addition to decrypting/detokenizing the data, encryption/tokenization service may retrieve the original, sensitive data from a secure data vault (not shown in <FIG> and <FIG>). The sensitive data is then sent to the authorized requester at <NUM>.

If the requesting client is determined to be authorized to receive only the anonymized data, then this anonymized data are retrieved and sent to the requester, at <NUM>. For example, encryption/tokenization service may simply retrieve the anonymized data from the data source and forward this data to the requesting client. In some embodiments, a requester may be authorized to receive either or both of the sensitive data and the anonymized data. In such embodiments, <NUM> and/or <NUM> may include determining whether the requester has selected the anonymized/de-anonymized data and providing the anonymized/de-anonymized data. In some embodiments, both the anonymized and the de-anonymized data might be provided.

If, however, it is determined that the requester was not authorized, then other action is taken at <NUM>. For example, the routine may terminate the connection to client as described above, the communication may be recalled from the data source, the client may be blacklisted, managers of system <NUM> and/or owner of the sensitive data may be notified of the attempted breach and/or other action taken. For example, as discussed above, the corresponding routine may terminate the connection to the client from which the query originated. If the query has been passed on to the data source, then the query may be canceled at <NUM>. Unwanted exfiltration of sensitive information may thus be prevented.

Although described in the context of anonymized data at <NUM> and storing the anonymized data at <NUM>, in another embodiment, step <NUM> might be skipped and the sensitive data stored at <NUM>. However, in such embodiments, at <NUM> no decryption is performed for the requester determined to be authorized to receive the sensitive data. Further, for requesters determined to be authorized to receive only encrypted/tokenized data, the data are encrypted/tokenized and then provided at <NUM>. Thus, methods <NUM> and <NUM> may be adapted to the case where sensitive data are stored.

For example, a request from client <NUM>-<NUM> to store sensitive data at data source <NUM> may be received by wrapper <NUM>, at <NUM>. Dispatcher <NUM> forwards the request to encryption/tokenization service <NUM>-<NUM> for anonymization, at <NUM>. Based on the policies provided and/or capabilities of encryption/tokenization service <NUM>-<NUM>, the sensitive data is identified and anonymized, at <NUM>. For example, encryption/tokenization service <NUM>-<NUM> may encrypt some sensitive data and tokenize other sensitive data. The anonymized data is stored in data source <NUM>, at <NUM>.

A request from client <NUM>-<NUM> for the sensitive data stored at the data source is received by the wrapper <NUM>, at <NUM>. Dispatcher <NUM> provides the request to access sensitive data to encryption/tokenization service <NUM>-<NUM>, at <NUM>. The request may also be forwarded by dispatcher <NUM> to data source <NUM>.

Encryption/tokenization service <NUM>-<NUM> determines what type of authorization the requestor possesses, at <NUM>. Thus, encryption/tokenization service <NUM>-<NUM> validates credentials for the requesting client <NUM>-<NUM>.

If the requesting client <NUM>-<NUM> is determined to be authorized to receive the sensitive data, then the anonymized data stored at data source <NUM> is retrieved, decrypted/detokenized and provided to client <NUM>-<NUM>, at <NUM>. In another embodiment, instead of or in addition to decrypting/detokenizing the data, encryption/tokenization service <NUM>-<NUM> may retrieve the original, sensitive data from a secure data vault. The sensitive data is then sent to the authorized requester. If the requesting client <NUM>-<NUM> is determined to be authorized to receive only the anonymized data, then encryption/tokenization service <NUM>-<NUM> retrieves the anonymized data from data source <NUM> and forwards this data to the requesting client <NUM>-<NUM>. If, however, it is determined that the requester was not authorized, then the routine may terminate the connection to client <NUM>-<NUM>, the communication may be canceled or recalled from data source <NUM>, client <NUM>-<NUM> may be blacklisted, managers of system <NUM> and/or owner of the sensitive data (e.g. user of client <NUM>-<NUM>) may be notified of the attempted breach and/or other action taken.

Using methods <NUM> and <NUM> sensitive data may be more securely stored and retrieved. Instead of storing sensitive data, anonymized data may be stored at <NUM>. How and what data are anonymized may be determined on an attribute level, which improves flexibility of methods <NUM> and <NUM>. This improves the ability of system <NUM> and methods <NUM> and <NUM> to protect sensitive data from being inappropriately accessed. Because these functions are provided via service(s) <NUM>, the enhanced security may be provided for data source(s) <NUM> and/or <NUM> that do not otherwise support encrypted data. Stated differently, secure storage and encryption/tokenization of data may be performed in a data agnostic manner. Thus, methods <NUM> and <NUM> may provide additional security to such data sources without requiring changes to the code of data sources <NUM> and <NUM>. Security may thus be improved in a simple, cost effective manner.

<FIG> are flow charts depicting exemplary embodiments of methods for providing client information and for performing behavioral baselining for clients. <FIG> is a flow chart depicting an exemplary embodiment of method <NUM> for providing client information and may be used as part of performing behavioral baselining for a client. Method <NUM> is described in the context of system <NUM>. However, method <NUM> may be used in connection with other systems including but not limited to systems <NUM> and <NUM> that employ collectors such as collectors <NUM>. For simplicity, certain steps of method <NUM> are depicted. Method <NUM> may include other and/or additional steps and substeps. Further, the steps of method <NUM> may be performed in another order including performing portions or all of some steps in parallel. In some embodiments, method <NUM> may be considered to be used in implementing <NUM> of method <NUM>. Method <NUM> is described in the context of clients <NUM>-<NUM> and <NUM>-<NUM>, collectors <NUM>-<NUM> and <NUM>-<NUM>, service <NUM>-<NUM> and data source <NUM>. Thus, method <NUM> commences after collectors <NUM> have been provided on one or more clients <NUM> utilizing data sources. However, in other embodiments, other clients, collectors, service(s) and/or other data sources may be used.

Communications for data source(s) to be issued by a client are intercepted, for example by a collector at the client, at <NUM>. In some embodiments, queries, method or API calls, commands or other messages may be intercepted before being provided from the client for transmission to the wrapper. In some embodiments, for example, a collector may attach itself to a client application and use Java Database Connectivity (JDBC) to intercept queries from the client of the data source(s). Thus, the collectors monitor the corresponding clients and intercept particular calls.

The state of the client issuing the communication is determined and attached to/associated with the intercepted communication, at <NUM>. For example, the type of call, the type of session/session identification, user identification for the session, the type of command (e.g. get, put, post, and delete commands), APIs, IP address, query attributes, method calls, order of queries, and/or application making the calls may be detected by the collector and attached to the communication at <NUM>. These attributes represent the context, or state, of the client (or client application) when issuing the communication. The collector attaches this context/state to the query or other communication being provided from the client. The communication and attached state are sent from the client, at <NUM>. In some embodiments, the attached state may be considered to be part of or included in the communication sent from the client.

In some embodiments, other clients may receive the communication from the sending client, perform other functions and then issue another communication. Thus, multiple clients may send and receive a communication before the communication is provided to the wrapper or data source. At each client that includes a collector and that receives the communication, any outgoing communication is intercepted as in <NUM>, the context for that client is determined and attached to the communication as in <NUM> and the communication and state/context sent as in <NUM>, via <NUM>. If only a single client having a collector sends the communication to the wrapper, then <NUM> may be omitted. If five clients having collectors send the communication in series, then the originating client performs <NUM>, <NUM> and <NUM>. <NUM> may be repeated four times for the four additional clients receiving and sending the communication. If five clients, only four of which have collectors, receive the communication in series, then <NUM> may be repeated three times. Thus, multiple clients may be involved in providing a communication to the data source. Each of the clients having a collector can attach their state to the communication. Further, the states may be attached in the order in which the clients sent/received the communication. The last client sending the communication provides the communication to a wrapper, such as wrapper <NUM>.

Thus, using method <NUM>, the context for a client can be provided to along with the communication. For clients providing multiple communications, the series of contexts provided with these communications may represent typical behavior for the client during interaction with the data source. Thus, the client(s) may send information relating to their state and/or behavior in addition to communications such as queries.

<FIG> is a flow chart depicting an exemplary embodiment of method <NUM> for performing behavioral baselining for a client. Method <NUM> is described in the context of system <NUM>. However, method <NUM> may be used in connection with other systems including but not limited to systems <NUM> and <NUM> that employ collectors such as collectors <NUM>. For simplicity, certain steps of method <NUM> are depicted. Method <NUM> may include other and/or additional steps and substeps. Further, the steps of method <NUM> may be performed in another order including performing portions or all of some steps in parallel. In some embodiments, method <NUM> may be considered to be used in implementing <NUM> of method <NUM>. Method <NUM> is described in the context of clients <NUM>-<NUM> and <NUM>-<NUM>, collectors <NUM>-<NUM> and <NUM>-<NUM>, service <NUM>-<NUM> and data source <NUM>. Thus, method <NUM> commences after collectors <NUM> have been provided on one or more clients <NUM> utilizing data sources. However, in other embodiments, other clients, collectors, service(s) and/or other data sources may be used. Method <NUM> may be performed in conjunction with method <NUM> and so may receive communications and states/contexts provided via method <NUM>.

The communication and context(s) of the client(s) are received at the wrapper, at <NUM>. The wrapper thus receives the communication, which may include multiple queries or method calls, as well as the states of all clients having collectors which sent the communication along before reaching the wrapper. In some embodiments, the communication and attached context(s) are received at the dispatcher. In some embodiments, the communication and attached context sent by the client at <NUM> or <NUM> of method <NUM> is received at the wrapper at <NUM>.

The context(s) are forwarded from the dispatcher to behavioral baselining service(s), at <NUM>. In some embodiments, the communications with which the context(s) are associated are also provided to the behavioral baselining service(s) at <NUM>. Also at <NUM>, the dispatcher may send the communication on to the desired data source(s). Thus, processing of the query or other calls in the communication may not be delayed by inspection of the context(s) of clients and other functions performed by behavioral baselining service(s). In other embodiments, the communication may be held at the dispatcher until behavioral baselining is completed. This may occur, for example, if the dispatcher is in step mode described above.

The state(s)/context(s) for the client(s) associated with the communication are compared with baseline(s) for client(s), at <NUM>. In some embodiments, the communication is also part of this comparison. For example, the particular query of the database provided by the client as well as the state of the client may be used for comparison with the baseline. In other embodiments, just the context(s) might be used. In some embodiments, a single context of a client associated with a single communication is compared to the baseline(s) at <NUM>. In other embodiments, multiple contexts that may be in a particular order of a client are compared to the baseline at <NUM>. For example, the behavioral baselining service may store the context received for each communication for each client having a collector. Frequently, a client issues multiple communications for a data source when utilizing the data source. A set of these contexts for a particular client represents the behavior of that client around the time the client interacts with the data source. The behavioral baselining service analyzes the behavior (series of contexts) of the client(s) providing the communication(s). In some embodiments, only the identities of the contexts are used. In some embodiments, the identities of the contexts as well as their order are used for comparison. In some embodiments, the behavioral baselining service compares the context(s) to the behavior based upon a model of the behavior (the series of states/contexts), such as a Hidden Markov Model. Thus, in <NUM> the behavioral baselining service maintains a model of requesting client(s)' behavior and compares the context in the current communication to the behavior. In some embodiments, a single context may be compared to the baseline in some cases and behavior in others. For example, for a first communication received by the wrapper, that first communication may be compared to the baseline. As additional communications are received, these communications may be compared to the baseline at <NUM>. In other embodiments, a client might first be authenticated and granted access to a data source based on another method of authentication, such as MFA. Once the client sends additional communication(s) with additional context(s), these communication(s) and context(s) may be used to compare the behavior for the client with the baseline. In some embodiments, the initial communication and authentication may be considered part of the behavior. In other embodiments, the initial communication and authentication may be considered separately from subsequent communication(s) and state(s).

If the context(s) for the current communication(s) sufficiently match the behavior, then the requesting client(s) are allowed access to the data source, at <NUM>. Thus, the data source is allowed to service the communication(s) provided by the client(s). If it is determined in <NUM> that the context does not sufficiently match the behavior, then the desired action is taken, at <NUM>. In some embodiments, the action taken may depend upon the mismatch determined in <NUM> or on other factors. For example, the client(s) initiating the communication(s) may not be allowed to access the data source. In such cases, the dispatcher may be informed and the corresponding routine used to terminate the connection to client(s). If the communication had already been forwarded to the data source(s), then the communication may be recalled from the data source(s). If the client had previously been authenticated, then the authentication may be revoked. In such embodiments, the dispatcher may be informed the client is unauthorized and the corresponding routine used to terminate the connection to client(s). Communication(s) that had been forwarded to the data source(s) may also be recalled from the data source(s). If the mismatch is sufficiently great or occurs greater than a threshold number of times, or at least a particular number of times in a row, then the client(s) may be blacklisted. In some embodiments, a secondary mechanism of authentication, such as MFA, may be invoked at <NUM>. Thus, access to the data source(s) may be determined at least in part based upon behavior of the requesting client(s). These and/or other actions may be taken at <NUM>.

The model/baseline may be updated, at <NUM>. For example, if it is determined that the context sufficiently matches the behavior at <NUM>, then the model/baseline may be updated with the context in the communication from client(s). If the context is considered inconsistent with the baseline, then the model/baseline may be updated with this information.

For example, suppose collector <NUM>-<NUM> in client <NUM>-<NUM> intercepts a communication including a query of data source <NUM> at <NUM>. The context of client <NUM>-<NUM> is determined by collector <NUM>-<NUM> and attached to the query. Client <NUM>-<NUM> then provides the communication and context to wrapper <NUM>. Because client <NUM>-<NUM> provides the communication to wrapper <NUM> without providing the communication to another client <NUM>, <NUM> is skipped. Dispatcher <NUM> receives the communication at <NUM> and provides the communication and context to behavioral baselining service <NUM>-<NUM> at <NUM>. The communication is also passed to data source <NUM> at <NUM>. Behavioral baselining service <NUM>-<NUM> compares the context received at <NUM> to the baseline for client <NUM>-<NUM> at <NUM>. If the context received is consistent with the baseline, then access is allowed to data source <NUM>, at <NUM>. Otherwise, access may be denied, for example the connection terminated, at <NUM>. Additional actions may also be taken at <NUM> such as blacklisting client <NUM>-<NUM>. The baseline may also be updated at <NUM>.

In some cases, multiple applications in multiple clients may pass a communication before the communication is sent to a data source. For example, this may occur where microservices are employed, as discussed above. For example, suppose collector <NUM>-<NUM> in client <NUM>-<NUM> intercepts the communication including a query of data source <NUM> at <NUM>. The state of client <NUM>-<NUM> is determined by collector <NUM>-<NUM> and attached to the query. Client <NUM>-<NUM> then provides the communication and state to client <NUM>-<NUM>. In some cases, client <NUM>-<NUM> may add another query to the communication or otherwise modify the communication. Collector <NUM>-<NUM> in client <NUM>-<NUM> intercepts the communication, attaches the state of client <NUM>-<NUM> and provides the communication to wrapper <NUM> at <NUM>. Thus, the communication now includes the states of clients <NUM>-<NUM> and <NUM>-<NUM>. If client <NUM>-<NUM> or <NUM>-<NUM> had passed the communication to client <NUM>-<NUM>, which does not include a collector, then <NUM> would be skipped for client <NUM>-<NUM> because no collector is present to determine and attach the state of client <NUM>-<NUM> to the communication. Dispatcher <NUM> receives the communication at <NUM> and provides the communication and states to behavioral baselining service <NUM>-<NUM> at <NUM>. The communication is also passed to data source <NUM> at <NUM>. Behavioral baselining service <NUM>-<NUM> compares the states received at <NUM> to the baselines for clients <NUM>-<NUM> and <NUM>-<NUM> at <NUM>. If the states received are consistent with the baselines, then access is allowed to data source <NUM>, at <NUM>. Otherwise, access may be denied, for example the connection terminated and the communication recalled from data source <NUM>, at <NUM>. Additional actions may also be taken at <NUM> such as blacklisting client <NUM>-<NUM> and/or <NUM>-<NUM>. The baseline(s) may also be updated at <NUM>.

Using methods <NUM> and <NUM>, security and performance for data sources may be improved. The context(s)/state(s) of client(s) in communications requesting access to data source(s) may be analyzed to determine whether the communication is consistent with previous behavior of client(s). If the state(s) of the client(s) are inconsistent with the baseline, then access to the data source(s) may be prevented and/or additional action taken. Methods <NUM> and <NUM> may also be extended to compare behavior (a series of states, for example for multiple queries) of clients to previous behavior and authenticate clients based upon their behavior. Thus, attacks from a client that has been hijacked may be detected and addressed. Further, collectors need not be present on all clients to enhance security. Instead, if a sufficiently high fraction of clients include collectors, data sources may be protected in a manner akin to herd immunity. Methods <NUM> and/or <NUM> may be coupled with other methods, such as query analysis in method <NUM>, authentication using method <NUM>, tokenization in method <NUM> and/or MFA in method <NUM> to further improve security.

As indicated above, various services may be combined. For example, wrapper <NUM> may provide multifactor authentication and/or federated identity management via service <NUM>-<NUM>, query analysis via service <NUM>-<NUM>, query rewriting via service <NUM>-<NUM> (or as part of service <NUM>-<NUM>), behavioral baselining via service <NUM>-<NUM>, tokenization of sensitive data via service <NUM>-<NUM>, and/or other service other functionality via service <NUM>-<NUM>. In such embodiments, dispatcher <NUM> may forward some or all of the request to multiple services <NUM> and/or services <NUM> may communicate with other services in order to perform the desired functions. Thus, performance of and security for data sources <NUM> and/or <NUM> may be improved by a variety of services without altering data sources <NUM> and/or <NUM>. Moreover, new services may be added to wrapper <NUM> for data source(s) <NUM> and/or <NUM> by adding service module or updating services <NUM>. These new services may be added without altering the code of data sources <NUM> and <NUM>. Thus, performance, security and/or other features of system <NUM> can continue to be improved.

Claim 1:
A method, comprising:
receiving a communication for a data source (<NUM>, <NUM>; <NUM>-<NUM>, <NUM>-<NUM>, <NUM>; <NUM>, <NUM>) at a wrapper (<NUM>; 210A, 210B; <NUM>), the wrapper including a dispatcher (<NUM>; 212A, 212B; <NUM>) and at least one service (<NUM>-<NUM>, <NUM>-<NUM>; <NUM>-1A, <NUM>-2A, <NUM>-1B, <NUM>-2B, <NUM>-3B; <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>), the dispatcher receiving the communication and being data agnostic, the communication including a header and a packet;
identifying, by the dispatcher, the data source based on an inspection of the header independent of an inspection of a payload of the packet; and
providing the communication from the dispatcher to the data source and to the at least one service, the at least one service inspecting the communication and performing at least one function based on the packet.