MALICIOUS DATA ACCESS AS HIGHLIGHTED GRAPH VISUALIZATION

One example method includes monitoring a data access pattern, registering a data access request directed to data, comparing metadata associated with the data access request to a rule, based on a result of the comparing, sending a trigger to a graph service, and using information in the trigger to generate a visual representation of the data access request, wherein the visual representation indicates an extent to which the data access request is considered to constitute a potential threat to the data.

FIELD OF THE INVENTION

Embodiments of the present invention generally relate to data access. More particularly, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and methods for using metadata about a user, data request, and data asset, for example, as a basis for generating data access rules and policies that may be used to create a visual representation of user behavior with respect to certain data.

BACKGROUND

Complex data systems and repositories such as catalogs and storage systems have created a need for handling governance and regulating access to data assets. These are typically described using security policies and rules defined manually by the security administrators, mandating who is allowed access and which users/groups are denied.

Often these rules and policies may include blind spots that lead to unwanted access, by allowing permission to an entire folder, data set, file share, or even allowing access to users of an entire LDAP (Lightweight Directory Access Protocol) group. For example, in case of unwanted access by a particular user within that LDAP group to a file, systems might generate security warnings based on risk assessment. The security administrator or DevSecOps team would have to manually inspect that warning through audit logs, which may be text-based, understand the behavior of the user within the context of the access request and, finally, take an action to permit or deny the user request.

In more detail, understanding the behavior of a user, and the nature of a malicious access request, is a tedious and time consuming task, and as such may lengthen the amount of time before action is taken. For example, evaluating a potentially malicious request involves complexity and requires an understanding of the whole system. Particularly, given the complex nature of security enforcement and monitoring systems, coupled with increasing complexity found in the geometry of data, it has become increasingly difficult and impractical to manually evaluate whether a flagged interaction should be marked as malicious or not.

For example, to perform such an evaluation, security administrators would have to review logs and audit data to evaluate a malicious access request. It is cumbersome and time consuming to deal with reviewing log and audit trail data from even a single system, let alone a series of systems. This is due to the fact that this data is rarely exposed in a consistent, parse-able format, and often only available in vendor-specific text format which is laborious to parse and comprehend.

DETAILED DESCRIPTION OF SOME EXAMPLE EMBODIMENTS

Embodiments of the present invention generally relate to data access. More particularly, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and methods for using metadata about a user, data request, and data asset, for example, as a basis for generating data access rules and policies.

In general, example embodiments of the invention may implement an approach to data access that defines access rules and policies in terms of metadata about the user, request and data assets. Example embodiments may also utilize a visualization approach that represents, in graphical form, the user behavior and interactions with the system in order to highlight risky access attempts within the context of the users and the system. This approach may reduce the amount of time needed to diagnose the behavior and provide administrators with the ability to intuitively understand the patterns in the access and comprehend the nature and scope of the behavior of the malicious users. In one particular embodiment, a workflow may be implemented that may tie security audit information to graph-based visualization of user interactions to highlight risky, or at least questionable, access.

In particular, one advantageous aspect of some embodiments is that they may create and/or use metadata about a user, a user access request, and data assets, in determining whether or not a particular access request, or a pattern of requests, is indicative of malicious behavior that may present a risk to the data or the assets where the data resides. An embodiment may provide for creation and presentation of a graphical representation of user interactions and/or attempted interactions with various data assets, and the graphical representation may be configured to readily identify possible areas of risk so as to enable an administrator to take timely and effective action to reduce or eliminate the risk.

It is noted that embodiments of the invention, whether claimed or not, cannot be performed, practically or otherwise, in the mind of a human. As indicated by this disclosure, embodiments of the invention are applicable to, and find practical usage in, environments in which hundreds or thousands of users seek access on an ongoing basis to files and other data assets which may number in the hundreds, thousands, or tens of thousands. In such environments, there is a need to quickly identify possible data security threats and take effective action concerning those. The timely identification and classification of such threats in such environments is well beyond the mental capabilities of any human to perform practically, or otherwise. Accordingly, nothing herein should be construed as teaching or suggesting that any aspect of any embodiment of the invention could or would be performed, practically or otherwise, in the mind of a human.

In a world driven by information and data, regulating access to data assets is of the utmost importance. Organizations usually use different methods depending on the importance of their data and to whom access rights are assigned. Regulations may be translated into security policies that mandate and describe how to control access to these sensitive data assets. These security policies may be evaluated by systems of record containing sensitive data in order to enforce these policies.

An important aspect of securing data assets is having the ability to intelligently categorize and classify these assets. The process of categorization and classification may entail examining the data and generating metadata and annotations that will allow the system to predict the importance, relevance, and sensitivity of an asset relative to a requesting user. Such metadata, or data about the data, may include information such as file type, file location, file size, and file owner, and annotations may include flags that indicate the type of data found.

Historically, organizations used to define access policies based on hierarchical groups to which users belong, such as an LDAP for example, and, based on the resource exposed by the system of record that contains the data in question, such as a share or a folder on a file server. However, these approaches have proven inadequate and there is a need for alternative methods.

Thus, example embodiments may provide, among other things, methods for defining security policies based on contextual information. Such embodiments may employ information about the user, such as UserID, Group, and Location, for example, who is trying to access the asset, metadata about the asset itself, such as Sensitivity, Category, and Location, for example, as well as metadata about the access attempt, such as IP Address, Location, Time, and Date, to make a final decision of either allowing or denying access. This process may enable IT administrators and security specialists to define their policies without having to manually specify users and data assets to which those users are allowed access. Thus, enabling context such as knowing the reason for the access request and the way in which the data will be utilized, may provide information that is useful for security risk assessment, namely, corollary data.

Consider that security policies might allow for some unwanted behavior in particular cases. In a legacy model, a user could attempt to access separate files and enforcement would simply be based on inherited permissions for the file or the resource, such as a file share or bucket, as exposed by the system of record. In contrast, example embodiments may create chains of actions that include details on the data itself and its usage.

For example, consider a user who does not have permission to view files that have been tagged with both the tags “employee name” and “salary.” In a conventional data access system, user access to a file with “employee name” and access to a separate file with “salary” would have gone undetected. In contrast, the metadata and annotations employed in some example embodiments may provide a level of detail on the data that enables a business to trigger an investigation when a potential security violation occurs. One example of such a violation may be when a user accesses two disparate data assets, where such access is considered problematic when those access attempts occur together or near in time or location to one another.

To continue with the foregoing example, embodiments of the invention may chain together or associate the fact that a user accessed, or attempted to, a file with the tag “employee name,” with the fact that the user separately accessed, or attempted to, a file with the tag “salary.” In this example, an embodiment may operate to trigger a notification to an administrator to investigate the access pattern, without necessarily denying the user access to the files.

However, just creating the notification may not always be enough. For example, in conventional approaches, DevSecOps admins are unable to easily identify if the access requests are benign or if the user behavior should be categorized as malicious. To understand the user behavior using current approaches, a DevSecOps admin would have to manually trace the user interactions with different data assets. This is a time-consuming, impractical process.

Thus, some example embodiments of the invention may reduce the time to diagnose user behavior, and act on that behavior, by collating the triggering event, relevant secondary data, and creating a graphic visualization of the user interactions with data. Particularly, such collated data may enable creation of a graphical presentation, such as a map for example, of the hierarchical user and group structure, including any metadata and annotations for each, as well as the data assets that belong to an organization, also including any metadata and annotations for each. An example graph may also include edges or other indicators that describe or denote the interactions of the users with these assets, metadata about the interactions, and the result of such interaction such as whether or not the user successfully accessed a data asset. The graph structure provided by some embodiments may enable administrators to answer questions about the user behavior such as which users that have attribute ‘X’ have succeeded or failed in attempts to access assets containing sensitive information.

With reference now toFIG.1, an example of a behavioral graph100indicating user behavior with respect to various data assets is disclosed. In the example graph100, some nodes indicate hierarchal groups to which users, belong to. Other nodes represent the data assets that users are trying to access, where data assets may be individually identified by a globally unique ID as shown inFIG.1. Inputs that may be used as the basis for creation of a graph, such as the example graph100, may include, for example, 1. identity sources (such as LDAP) such as a group or groups that a user belongs to, and 2. any system that may enable a user to query for data, interact with the data metadata, or access data itself. With regard to 1., contextual identity information may be included the graph, and in the case of 2., events related to attempts by a user to interact with metadata or data may be included in the graph.

B. Aspects of Some Example Embodiments of the Invention

In general, some example embodiments may operate to create a new workflow that ties security-audit information to graph-based visualization of user interactions, so as to highlight risky access. With particular reference now toFIG.2, details are provided concerning an example architecture200. Any element of the architecture200, such as the data discovery/pipeline for example, may communicate with a system of record (not shown) which may comprise any system containing data that could be requested by a user, such as, but not limited to, a file server, object store, or database server.

As indicated in the particular example ofFIG.2, the example architecture200may include various tools and services including, for example, a data catalog202. The data catalog202may house and/or index all the data assets that belong to a given organization and may communicate with the system(s) of records where the actual data is stored. Further, the data catalog202may also contain metadata about these assets, and the metadata may be used to categorize and distinguish the assets.

The architecture200may also comprise a metadata control plane204that may comprise an interface through which metadata is exposed and managed. The structure of the metadata may be defined and managed in one or more data dictionaries.

An orchestration engine206may operate to orchestrate the operation of various components of the architecture200. Such components may include, for example, the data catalog202, data governance control plane208, graph service210, and malicious behavior service212, as discussed in further detail below.

As well, the example architecture200may include a data integration module214, a data discovery/pipeline216, graph visualization tool218, and various secondary sources220that may provide input usable by the graph service212to generate graphs and other visually perceptible renderings of potential and/or actual data risks. With continued reference to the example ofFIG.2, the data governance control plane208may comprise a system that relies on the context of a user request for data access to evaluate whether access should be granted based on the metadata of the asset, the properties of the user and the groups to which they belong, metadata about the access request itself, and any additional information that should be deemed necessary.

As noted earlier, the example architecture200may include a malicious behavior service210which may comprise a component tied to the data governance control plane208that may operate to flag certain access requests or strings of requests as malicious or risky. This malicious behavior service210may communicate with the graph service212to create or append data gathering requests. That is, the malicious behavior service210may provide input to the graph service212that the graph service212may use a basis to generate a graph or other representation of possibly risky behavior by a user or users. In some embodiments, the malicious behavior service210may employ, for example, intent of use and available access rights to calculate a risk score.

With continued reference toFIG.2, and as noted earlier, the example architecture200may comprise a graph service212. The graph service212may collect data and build a graph of all, or selected, user interactions and access attempts with the data catalog and systems of record. Data collected by the graph service212may include, but is not limited to, content from a system of record, data catalog, information from the metadata control plane such as metadata, annotations, and other rules, orchestration engine information such as audit content if needed, and information and data concerning the data governance control plane, asset data, and the access request itself. An example for a graph backend that could be used in the graph service212is ArangoDB (https://www.arangodb.com/), which allows for flexible JSON (JavaScript Object Notation) documents and schemas within the graph and the edges of the graph.

With reference nowFIG.3, a hypothetical comparative example301is used to illustrate various details of an example embodiment302concerning the handling of a suspicious request for data access. More particularly,FIG.3discloses a workflow that comprises a method for detecting and collecting data for suspicious access patterns for graph-based investigation.

In the illustrative example ofFIG.3, suppose that a rule for defining a suspicious data access request is formulated as follows: “If anyone from GroupB accesses data with tag ‘gemini,’ then data with tag ‘judo’ within 72 hours, trigger Low-level malicious behavior notification.” In the comparative workflow301, a user accesses303an asset with the tag ‘gemini’ and also305an asset with the tag ‘judo.’ Both the access attempt303and the access attempt305may be registered307by a governance control plane. At this point, a notification309might or might not be sent, but the security service may not be able to easily diagnose whether or not the notification309actually identified a risk. Assuming that DevSecOps was able to find an issue, the investigation would be manual, involving manual access311of the data that was accessed, or attempted to be accessed, and would involve accessing audit logs and singular access views in an attempt by DevSecOps to comprehend the behavior to visualize and diagnose313the problem.

With continued reference to the example ofFIG.3, the workflow302may generally involve proactively triggering and collating the data, and building a graph that may enable diagnosis. Pulling together data from across all architectural components and secondary sources, as may be defined by the malicious service notification type, implementation of the workflow302may provide the ability to gather the right data, including data about secondary user behaviors such as querying available datasets, updating entities of a dataset, and retrieving existing metadata about a data asset. The data access requests may be gathered from a data catalog, and a graph service may collect certain information such as user information including User ID, Group, and Location, and the graph service may also collect request information, that is, information about the requests that were made, and such information may include action type (read, write, replicate, copy, delete), source IP address of the device from which the request was originated, and the time of the requests. From the governance control plane, a resulting access decision may be retrieved based on the security provider, and from the metadata control plane, metadata about the entity may be gathered. That metadata may then be collated in the graph service in a format that is readable by the graph database, which may be made available to a user based on an authorizer user login.

With specific reference now to the workflow302, and similar to the comparative workflow301, a user may access304an asset with the tag ‘gemini’ and also306an asset with the tag ‘judo.’ Both the access attempt304and the access attempt306may be registered308by a governance control plane. At310, however, a malicious behavior service that is monitoring user access patterns may be notified by the governance control plane of the access attempts304and306.

The malicious behavior service may then compare the access pattern with the rule, or rules, established to defined suspicious behavior. If the malicious behavior service determines that an access pattern or access attempt runs afoul of one or more rules, the malicious behavior service may then send312a trigger to the graph service. The trigger may include, for example, details concerning the access requests that were the basis for generation of the trigger.

The graph service may then pull data314from various sources. Those sources may include the trigger, user credentials, group information indicating which group(s) the user belongs to, and data access nodes which may have information about the user, when the user attempted access, and the data assets that were accessed or attempted to be accessed. Some or all of the data pulled314by the graph service may then be collated316, and/or otherwise processed, so that it may be used for generation of a graph.

The processed316data may then be used318to create a graph that may illustrate both suspicious user behavior, and behavior that is not of a suspicious nature. The graph may visually indicate, for example, users and the data assets they have accessed or attempted to access. The graph may also indicate which group or groups a user belongs to. By visually examining the graph, DevSecOps may then be able to distinguish320between normal behavior and anomalous behavior. Appropriate action may then be taken based on the anomalous behavior, if any, that has been identified.

With the discussion ofFIG.3in view, attention is directed now toFIG.4, which discloses a JSON format of example data collated by a graph service, resulting in content which could be visualized by the graph database and used to create a graph. One example of such a graph is indicated at400inFIG.5. The example graph400contains user, group, and data asset, nodes. These nodes are connected via edges describing a certain relationship between a group and a user or an access request from a user to a given data asset. Particularly, example users, groups of users, and data assets accessed by one or more of the users, are disclosed.

Using all of the information collated by the graph service, anomalies and risky access patterns may then be identified. The malicious behavior service may proactively prompt the graph service to populate data into a graph from access requests which are flagged by the governance control plane, metadata control plane or catalog as ‘risky.’ This new data may be highlighted within the user behavior graph, and may also be independently filtered or queried using the API (Application Program Interface). In instances where the customer has adopted risk scoring, which refers to a numerical method of applying weighting to the severity of risk to a behavior or set of behaviors, highlighting may be varied to reflect the relative risk of the issue in the graph. Various methods for highlighting this behavior can be used. For example, edges representing malicious behavior may be colored in red to represent that such behavior requires attention, while edges representing behavior that is not problematic may be colored green. Other methods include using third-party graph visualization tools to depict the malicious behavior using a different line type/weight, or line size.

Among other things then, the workflow and visualization techniques implemented by example embodiments may provide administrators with an intuitive and fast method to identify and diagnose anomalies in the access behavior. Understanding an access attempt within the context of the overall access may ultimately reduce the time needed to take the appropriate actions.

C. Further Discussion

As disclosed herein, example embodiments of the invention may include or provide various useful features and functionalities. For example, an embodiment of the invention may implement anomalous behaviors diagnosis through the visualization of data asset access and/or access attempts whether successful or not. Particularly, some embodiments may leverage visual aids to provide IT administrators and security operators the ability to examine user interactions with data in such a way that normal behavior can be identified and distinguished from anomalous behavior. As such, some embodiments may be advantageous relative to conventional approaches which may rely on the manual parsing, by a human, of log messages where anomalous behavior may be overlooked due to human error.

As another example, an embodiment of the invention may provide and/or enable visual analysis of multiple disparate data asset access operations. For example, an action that may appear to be normal or conventional when viewed in isolation, may be considered anomalous when performed, and considered in connection, with other actions. Thus, embodiments may provide a rich context for analyzing user data access operations by considering, automatically in some embodiments, such operations not necessarily in isolation but in connection with other data access operations by the same and/or other user(s). For example, embodiments may visualize multiple disparate actions over a historical period, allowing actions to be assessed simultaneously, rather than requiring a DevSecOps admin to manually parse through multiple log files in an attempt to relate actions from the same user.

As a final example, embodiments may operate to highlight data assets that may be potential targets of malicious users. Particularly, by visually representing their anomalous behavior, relationships between the assets being accessed can be drawn, and possible justification for the unwarranted access detected. This can then be used to increase security measures around data sets of interest to malicious users.

D. Example Use Case

One example use case for one or more embodiments may involve the evaluation of risky data access attempts. Particularly, upon receiving a notification for a possible risky access attempt, IT administrators may be given the opportunity to visually evaluate whether the attempt should be flagged as malicious. This may be done by using the visual tool to view a graph representing access attempts made by the user, and the graph may also highlight all risky attempts associated with the user, and possibly other users related in some way such as by the group to which they belong, to enable the admins to make an informed decision. With particular reference to the example ofFIG.6, a graph500is disclosed that highlights context and risky access attempt that has taken place within that context. In the graph500, the designated edges represent successful attempts, other edges indicate risky behavior, which may be identified by comparing data and metadata concerning an attempt with the criteria of one or more rules, and still other edges indicate attempts from a flagged user.

Another example use case may concern determinations of potential malicious behavior. In this use case, an administrator may request visual information about datasets that might be potentially prone to malicious behavior by linking and associating different data assets using their metadata. This may enable IT administrators to obtain a real-time view of their data assets and visually be able to detect dangerous, or potentially dangerous, situations through a graph view.

E. Example Methods

It is noted with respect to the example method ofFIG.3, and the other processes, methods, and operations, disclosed herein that any of the disclosed processes, operations, methods, and/or any portion of any of these, may be performed in response to, as a result of, and/or, based upon, the performance of any preceding process(es), methods, and/or, operations. Correspondingly, performance of one or more processes, for example, may be a predicate or trigger to subsequent performance of one or more additional processes, operations, and/or methods. Thus, for example, the various processes that may make up a method may be linked together or otherwise associated with each other by way of relations such as the examples just noted.

F. Further Example Embodiments

Embodiment 1. A method, comprising: monitoring a data access pattern; registering a data access request directed to data; comparing metadata associated with the data access request to a rule; based on a result of the comparing, sending a trigger to a graph service; and using information in the trigger to generate a visual representation of the data access request, wherein the visual representation indicates an extent to which the data access request is considered to constitute a potential threat to the data.

Embodiment 2. The method as recited in embodiment 1, wherein the monitoring and the sending are performed by a malicious behavior service.

Embodiment 3. The method as recited in any of embodiments 1-2, wherein generation of the visual representation of the data access request is performed by the graph service.

Embodiment 4. The method as recited in any of embodiments 1-3, wherein the visual representation of the data access request comprises a graph that indicates a group to which a user, that generated the data access request, belongs.

Embodiment 5. The method as recited in any of embodiments 1-4, wherein the visual representation of the data access request comprises a graph that indicates data access attempts directed to various data assets by one or more users.

Embodiment 6. The method as recited in any of embodiments 1-5, wherein the metadata comprises metadata of a user who originated the data access request.

Embodiment 7. The method as recited in any of embodiments 1-6, wherein the visual representation of the data access request is generated based in part on user metadata of a user who made the data access request, group metadata of a group to which the user belongs, and data asset metadata of the data with which the data access request is concerned.

Embodiment 8. The method as recited in any of embodiments 1-7, wherein the trigger is based on the data access request in combination with another data access request that also concerns the data, and the another data access request is made by a same user that made the data access request or is made by a different user than the user that made the data access request.

Embodiment 9. The method as recited in any of embodiments 1-8, wherein, in the visual representation, a data access request that is considered a potential threat to the data is visually distinguishable from another data access request that is not considered to be a potential threat to the data.

Embodiment 10. The method as recited in any of embodiments 1-9, further comprising taking an action regarding the data based on information presented in the visual representation.

Embodiment 11. A method for performing any of the operations, methods, or processes, or any portion of any of these, disclosed herein.

Embodiment 12. A computer readable storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations comprising the operations of any one or more of embodiments 1-11.

F. Example Computing Devices and Associated Media

In the example ofFIG.7, the physical computing device600includes a memory602which may include one, some, or all, of random access memory (RAM), non-volatile memory (NVM)604such as NVRAM for example, read-only memory (ROM), and persistent memory, one or more hardware processors606, non-transitory storage media608, UI device610, and data storage612. One or more of the memory components602of the physical computing device600may take the form of solid state device (SSD) storage. As well, one or more applications614may be provided that comprise instructions executable by one or more hardware processors606to perform any of the operations, or portions thereof, disclosed herein.