Dynamic policy injection and access visualization for threat detection

Abstract

To provide a system capable of analyzing security events and providing threat visualization for presenting real-time data analysis by a method that can be easily understood by an end user.SOLUTION: A method includes: providing a distributed environment including a target system comprising a user device, a plurality of agents, a collection bus, a policy bus, and a resource; creating an inspection policy on the basis of history data or designation of the target system or the resource; publishing the inspection policy on the policy bus so that a plurality of agents can access the inspection policy; collecting data on a security event; creating a dynamic enforcement policy on the basis of the data; publishing the dynamic enforcement policy on the policy bus so that the plurality of agents can access the dynamic enforcement policy; and implementing an enforcement action for the security event on the basis of the dynamic enforcement policy.SELECTED DRAWING: Figure 19

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Application No. 62 / 447,759, filed January 18, 2017, and entitled "Access Visualization to Detect Threats," and U.S. Provisional Application No. 62 / 396,016, filed September 16, 2016, and entitled "Access Visualization to Detect Threats," the entire contents of which are incorporated herein by reference for all purposes. [Background technology]

[0002] background The present disclosure relates generally to threat detection, and more particularly to techniques (e.g., systems, methods, computer program products for storing code or instructions executable by one or more processors) for analyzing security events using dynamic policies and displaying a unified view including active threats, user activity, and dynamic policies triggered by the active threats and user activity.

[0003] Computer networks have become important tools for modern business. Currently, a large amount of information is stored on such networks and is available to users around the world. Since most information is secret or confidential to some degree, protection of the information is necessary. Not surprisingly, a variety of network security monitoring devices have been developed to detect attempts by unauthorized persons and / or devices to gain access to computer networks and the information stored therein.

[0004] Network security products primarily include intrusion detection systems (IDS), which may be network-based intrusion detection systems (NIDS) or host-based intrusion detection systems (HIDS). Other network security products include firewalls, router logs, and various other event reporting devices. Depending on the size of the network, many enterprises have hundreds or even thousands of these products deployed on their networks. Thus, network security personnel are overwhelmed with alarms that represent possible security threats. Most enterprises do not have the resources or qualified personnel to individually respond to every alarm they receive.

[0005] Therefore, techniques are desired for analyzing security events and providing threat visualization to present real-time data analysis in a manner that is easily understandable to end users. Summary of the Invention [Means for solving the problem]

[0006] overview Given the extreme volume of user activity (billions of events per day), static security rules cannot keep up with threats originating from vulnerable users, applications, and hosts, and a threat intelligence platform must be provided. Some embodiments can provide real-time threat detection and analysis. Certain embodiments can provide visibility into user, application usage, and performance. Some embodiments can leverage existing access controls to provide real-time enforcement. Certain embodiments can enforce compliance, blocking user access to unauthorized applications, and providing adaptive authorization and enforcement based on policy. The system can authenticate users and perform content inspection to prevent privacy and leaks. Certain embodiments can perform real-time enforcement using rules and analytics. Some embodiments can collect, monitor, and visualize large amounts of security data (i.e., billions of events per day) in real time and take corresponding actions.

[0007] In particular, systems, methods, and computer readable memories are disclosed for controlling access to accessible resources in a distributed environment. Particular techniques are disclosed for providing identity management solutions using access management and threat detection systems and information management systems configured to dynamically analyze security events, control access to accessible resources in a distributed environment, and display a unified view of active threats and user activity. In various embodiments, the systems and methods relate to network architectures that include the ability to create dynamic policies (including inspection policies and execution policies), the concept of a policy bus for deploying and communicating dynamic policies to multiple execution entities, and the ability of the entities to dynamically respond to policies in potentially different ways. For example, in various embodiments, methods and systems are provided for preparing and executing dynamic access policies based on threat detection, real-time anomaly detection based on real-time threat models, dynamic event and data collection based on inspection policy distribution, and classification of dynamic access policies based on threat levels.

[0008] In various embodiments, a system is provided that includes one or more processors and a non-transitory machine-readable storage medium, a distributed environment including a user device, a plurality of agents, a collection bus, a policy bus, and a target system having resources, and program instructions for collecting data related to a security event. The data includes (i) a source for identifying a user or user device, and (ii) a destination for identifying a target system or resource, and the data is collected from at least one agent of the plurality of agents by the collection bus. The system further includes program instructions for creating a dynamic execution policy based on the data. The dynamic execution policy includes a source, a destination, an execution action, and a designation of a period during which the dynamic execution policy is active. The system further includes program instructions for publishing the dynamic execution policy on the policy bus such that the dynamic execution policy is accessible to a plurality of agents. During a period during which the dynamic execution policy is active, the dynamic execution policy overwrites the static execution policy including the designation of the source and destination. The program instructions are stored in the non-transitory machine-readable storage medium and executed by the one or more processors.

[0009] In some embodiments, the system further includes program instructions for performing an enforcement action in response to the security event based on the dynamic execution policy. At least one agent of the plurality of agents performs the enforcement action.

[0010] In some embodiments, the period is a predetermined period of at least five minutes, the dynamic execution policy becomes inactive and is removed from the policy bus after the predetermined period has expired, and the static execution policy is inactive during the predetermined period, and the static execution policy becomes active after the predetermined period has elapsed.

[0011] In some embodiments, data collection is triggered by inspection policies published on the policy bus, which contain rules for collecting data, a set of predefined attributes about a security event, in real time when a set of criteria for the security event matches a predefined pattern.

[0012] In some embodiments, the distributed environment comprises an analytics server and a machine learning component. wherein the inspection policy and the dynamic execution policy are created by the analysis server and the machine learning component.

[0013] In some embodiments, the system further includes program instructions for creating an inspection policy based on historical data or specifications of a target system or resource, and program instructions for publishing the inspection policy on a policy bus so that multiple agents can access the inspection policy.

[0014] In some embodiments, creating a dynamic execution policy includes classifying real-time collected data and historical data into one or more data clusters, analyzing a set of defined attributes using the one or more data clusters, and based on the analysis, creating sources, destinations, enforcement actions, and time periods during which the dynamic execution policy is active.

[0015] In some embodiments, the one or more data clusters are generated using supervised or unsupervised machine learning or clustering techniques, the analysis includes calculating distances from the centroids of the one or more data clusters to the set of defined attributes, and an action is determined based on the distances.

[0016] In various embodiments, a non-transitory machine-readable storage medium storing instructions is provided. The instructions, when executed by one or more processors, cause the one or more processors to perform a method including collecting data related to a security event. The data includes (i) a source for identifying a user or user device, and (ii) a destination for identifying a target system or resource, and the data is collected by a collection bus from at least one agent of the plurality of agents. The method further includes creating a dynamic execution policy based on the data. The dynamic execution policy includes a specification of a source, a destination, an enforcement action, and a time period during which the dynamic execution policy is active. The method further includes publishing the dynamic execution policy on a policy bus such that the plurality of agents can access the dynamic execution policy. The method further includes performing enforcement actions on the security event based on the dynamic execution policy, and at least one agent of the plurality of agents performs the enforcement action. During the time period during which the dynamic execution policy is active, the dynamic execution policy overwrites the static execution policy including the specification of the source and destination.

[0017] In some embodiments, the period is a predetermined period of at least five minutes, the dynamic execution policy becomes inactive and is removed from the policy bus after the predetermined period has expired, and the static execution policy is inactive during the predetermined period, and the static execution policy becomes active after the predetermined period has elapsed.

[0018] In some embodiments, data collection is triggered by inspection policies published on the policy bus, which contain rules for collecting data, a set of predefined attributes about a security event, in real time when a set of criteria for the security event matches a predefined pattern.

[0019] In some embodiments, the inspection policy and the dynamic execution policy are created by an analytics server and a machine learning component.

[0020] In some embodiments, the method includes the steps of creating a verification policy based on historical data or a specification of a target system or resource; and publishing the verification policy on a policy bus so that multiple agents can access the verification policy. and

[0021] In some embodiments, creating the dynamic execution policy includes classifying the real-time collected data and historical data into one or more data clusters, analyzing a set of defined attributes using the one or more data clusters, and based on the analysis, creating sources, destinations, enforcement actions, and time periods during which the dynamic execution policy is active.

[0022] In some embodiments, the one or more data clusters are generated using supervised or unsupervised machine learning or clustering techniques, the analysis includes calculating distances from the centroids of the one or more data clusters to the set of defined attributes, and an action is determined based on the distances.

[0023] In various embodiments, a method is provided that includes using a computing system to collect data related to a security event. The data includes (i) a source for identifying a user or user device, and (ii) a destination for identifying a target system or resource, the data being collected by a collection bus from at least one agent of the plurality of agents. The method further includes creating a dynamic execution policy based on the data. The method further includes using a computer system to create a dynamic execution policy based on the data. The dynamic execution policy includes a designation of a source, a destination, an enforcement action, and a time period during which the dynamic execution policy is active. The method further includes using a computing system to publish the dynamic execution policy on a policy bus such that the plurality of agents can access the dynamic execution policy. The method further includes using a computing system to perform enforcement action on the security event based on the dynamic execution policy, and at least one agent of the plurality of agents performs the enforcement action. During the time period during which the dynamic execution policy is active, the dynamic execution policy overwrites the static execution policy including the designation of the source and destination.

[0024] In some embodiments, the period is a predetermined period of at least five minutes, the dynamic execution policy becomes inactive and is removed from the policy bus after the predetermined period has expired, and the static execution policy is inactive during the predetermined period, and the static execution policy becomes active after the predetermined period has elapsed.

[0025] In some embodiments, data collection is triggered by inspection policies published on the policy bus, which contain rules for collecting data, a set of predefined attributes about a security event, in real time when a set of criteria for the security event matches a predefined pattern.

[0026] In some embodiments, the method further includes using a computing system to create an inspection policy based on historical data or specifications of the target system or resource, and publishing the inspection policy on a policy bus so that multiple agents can access the inspection policy.

[0027] In some embodiments, creating the dynamic execution policy includes classifying the real-time collected data and historical data into one or more data clusters, analyzing a set of defined attributes using the one or more data clusters, and based on the analysis, creating sources, destinations, enforcement actions, and time periods during which the dynamic execution policy is active.

[0028] In various embodiments, systems and methods relate to providing a consolidated view of active threat categories, the number of policies triggered for each threat category, and associated trends. In a particular embodiment, a system is provided that includes one or more processors and a non-transitory machine-readable storage medium and program instructions for monitoring one or more live information flows. The live information flows include data flows from multiple sources to multiple destinations. The system further includes program instructions for providing a user interface that includes multiple buckets. Each bucket is associated with a different enforcement action, and each bucket is triggered in real time and displays a total number of current enforcement policies including associated enforcement actions. The system further includes program instructions for determining the occurrence of a security event in the one or more live information flows based on the triggering of the enforcement policy. The enforcement policy includes a designation of a source, a destination, and an enforcement action, and if data in the one or more live information flows matches at least the source and destination of the enforcement policy, the enforcement policy is triggered and the enforcement action is applied. The system further includes program instructions for updating the user interface to reflect the occurrence of a security event by (i) identifying a bucket from the plurality of buckets associated with an enforcement action applied by an enforcement policy, and (ii) incrementing a total number of current enforcement policies displayed in the identified bucket triggered in real time by the enforcement action. The program instructions are stored in a non-transitory machine-readable storage medium and executed by one or more processors.

[0029] In some embodiments, the system further includes program instructions for updating a trend indicator for the identified bucket based on the occurrence of the security event, where updating the trend indicator includes displaying an up arrow for the identified bucket.

[0030] In some embodiments, increasing the total number of execution policies includes incrementing a count number n of the total number of execution policies to a count number n+1.

[0031] In some embodiments, the system further includes program instructions for receiving user input corresponding to a selection of a bucket from the plurality of buckets, and program instructions for displaying in the user interface a live information flow including a plurality of sources and a plurality of destinations corresponding to the selected bucket.

[0032] In some embodiments, the system further includes program instructions for displaying the multiple sources in a user interface as a tag cloud, the tag cloud showing the multiple sources corresponding to the selected bucket in proportion to the usage of each source.

[0033] In some embodiments, the system further includes program instructions for receiving a request to create a dynamic execution policy based on the data, the dynamic execution policy including a specification of a source, a destination, an execution action, and a time period during which the dynamic execution policy is active.

[0034] In some embodiments, the system further includes program instructions for publishing the dynamic execution policy on a policy bus so that the multiple agents can access the dynamic execution policy. The system further includes program instructions for taking an enforcement action on another security event in one or more live information flows based on the dynamic execution policy, where at least one agent of the multiple agents takes the enforcement action. The system further includes program instructions for updating a user interface to reflect the execution of the enforcement action on the other security event by (i) identifying a bucket from the multiple buckets that is associated with the enforcement action applied by the dynamic execution policy, and (ii) triggered in real time by the enforcement action and incrementing a total number of current execution policies displayed in the identified bucket.

[0035] In some embodiments, during the period during which a dynamic execution policy is active, the dynamic execution policy overwrites a static execution policy that contains the same specifications for source and destination contained in the dynamic execution policy.

[0036] In various embodiments, a non-transitory machine-readable storage medium storing instructions is provided. The instructions, when executed by one or more processors, cause the one or more processors to perform a method including monitoring one or more live information flows. The live information flows include data flows from multiple sources to multiple destinations. The method further includes providing a user interface including a plurality of buckets. Each bucket is associated with a different enforcement action, and each bucket is triggered in real time to display a total number of current execution policies including the associated enforcement action. The method further includes providing a user interface including a plurality of buckets. Each bucket is associated with a different enforcement action, and each bucket is triggered in real time to display a total number of current execution policies including the associated enforcement action. The method further includes determining an occurrence of a security event in the one or more live information flows based on a trigger of the execution policy. The execution policy includes a designation of a source, a destination, and an enforcement action, and if data in the one or more live information flows matches at least a source and a destination of the execution policy, the execution policy is triggered and the enforcement action is applied. The method further includes updating the user interface to reflect the occurrence of a security event by (i) identifying a bucket from the plurality of buckets that is associated with an enforcement action applied by an enforcement policy, and (ii) increasing a total number of current enforcement policies triggered in real time by the enforcement action and displayed on the identified bucket.

[0037] In some embodiments, the method further includes receiving user input corresponding to a selection of a bucket from the plurality of buckets and displaying in the user interface a live information flow including a plurality of sources and a plurality of destinations corresponding to the selected bucket.

[0038] In some embodiments, the method further includes displaying the multiple sources in a user interface as a tag cloud, the tag cloud showing the multiple sources corresponding to the selected bucket in proportion to the usage of each source.

[0039] In some embodiments, the method further includes receiving a request to create a dynamic execution policy based on the data. The dynamic execution policy includes a designation of a source, a destination, an enforcement action, and a time period during which the dynamic execution policy is active. The method further includes publishing the dynamic execution policy on a policy bus so that a plurality of agents can access the dynamic execution policy. The method further includes performing enforcement actions on another security event in one or more live information flows based on the dynamic execution policy, where at least one agent of the plurality of agents performs the enforcement action. The method further includes updating a user interface by (i) identifying a bucket from the plurality of buckets that is associated with the enforcement action applied by the execution policy, and (ii) triggering in real time by the enforcement action and incrementing a total number of current execution policies displayed on the identified bucket to reflect the execution of the enforcement action on the another security event.

[0040] In some embodiments, during the period during which a dynamic execution policy is active, the dynamic execution policy overwrites a static execution policy that contains the same specifications for source and destination contained in the dynamic execution policy.

[0041] In some embodiments, the period is a predetermined period of at least five minutes, the dynamic execution policy becomes inactive and is removed from the policy bus after the predetermined period has expired, and the static execution policy is inactive during the predetermined period, and the static execution policy becomes active after the predetermined period has elapsed.

[0042] In various embodiments, a method is provided that includes monitoring one or more live information flows using a computing system. The live information flows include data flows from multiple sources to multiple destinations. The method further includes providing, using the computing system, a user interface that includes a plurality of buckets. Each bucket is associated with a different enforcement action, and each bucket is triggered in real time and displays a total number of current execution policies including the associated enforcement action. The method further includes determining, using the computing system, an occurrence of a security event in the one or more live information flows based on a trigger of the execution policy. The execution policy includes a specification of a source, a destination, and an enforcement action, and if data in the one or more live information flows matches at least a source and a destination of the execution policy, the execution policy is triggered and the enforcement action is applied. The method includes updating, using the computing system, the user interface to reflect the occurrence of the security event by (i) identifying, from the plurality of buckets, a bucket associated with the enforcement action applied by the execution policy and (ii) incrementing a total number of current execution policies triggered in real time by the enforcement action and displayed in the identified bucket.

[0043] In some embodiments, the method further includes, with the computing system, receiving user input corresponding to a selection of a bucket from the plurality of buckets, and displaying in a user interface a live information flow including a plurality of sources and a plurality of destinations corresponding to the selected bucket.

[0044] In some embodiments, the method further includes receiving, with the computing system, user input corresponding to a selection of a particular source from the plurality of sources, and displaying, with the computing system, a live information flow originating from the particular source.

[0045] In some embodiments, the method further includes receiving, with the computing system, user input corresponding to a selection of a particular destination from a plurality of destinations, and displaying, with the computing system, a live information flow ending at the particular destination.

[0046] In some embodiments, the method further includes using a computing system to display in a user interface a live information flow including multiple sources and multiple destinations, and providing an indicator of a set of top sources based on the amount of data flowing from the multiple sources to the multiple destinations.

[0047] In some embodiments, the method further includes using a computing system to display in a user interface a live information flow including multiple sources and multiple destinations, and providing an indicator of a set of top destinations based on the amount of data flowing from the multiple sources to the multiple destinations.

[0048] In some embodiments, a method includes using a computing system to display a live information flow including multiple sources and multiple destinations in a user interface, and displaying an indicator of a set of top execution policies based on the amount of data flowing from the multiple sources to the multiple destinations and the set of active execution policies published on a policy bus. and providing the caterer.

[0049] In various embodiments, systems and methods relate to providing a unified view of users, applications being accessed by the users, and possible access policies associated with the access. In a particular embodiment, a system is provided that includes one or more processors and a non-transitory machine-readable storage medium and program instructions for monitoring live information flows. The live information flows include data flows from sources to destinations. The system further includes program instructions for providing a user interface that includes sources and destinations connected through lines, and program instructions for determining the occurrence of a security event in the live information flows based on a trigger of an execution policy. The execution policy includes a designation of a source, a destination, and an enforcement action, and if data in one or more live information flows matches at least a source and a destination of the execution policy, the execution policy is triggered and the enforcement action is applied. The system further includes program instructions for updating the user interface to reflect the occurrence of a security event by (i) identifying an indicator of the execution policy, and (ii) displaying a line connecting a source and a destination that passes through the indicator of the execution policy. The program instructions are stored in the non-transitory machine-readable storage medium and executed by the one or more processors.

[0050] In some embodiments, the source is displayed on one side of a user interface window and the destination is displayed on the other side of the window opposite the side having the source, and an indicator of the execution policy is displayed on the line between the source and destination.

[0051] In some embodiments, the system further includes program instructions for monitoring one or more live information flows, the live information flows including (i) data flows from a plurality of sources to a plurality of destinations, and (ii) one or more execution policies triggered by the data, and the user interface further includes (i) one or more lines for connecting each source of the plurality of sources to a corresponding each destination of the plurality of destinations, and (ii) an indicator on each line indicating an execution policy triggered by the data flowing between each source and each destination.

[0052] In some embodiments, the system further includes program instructions for receiving user input corresponding to a selection of a particular source from the plurality of sources, and program instructions for displaying a live information flow originating from the particular source including one or more execution policies triggered by data in the live information flow.

[0053] In some embodiments, the system further includes program instructions for receiving user input corresponding to a selection of a particular destination from the plurality of destinations, and program instructions for displaying a live information flow terminating at the particular destination including one or more execution policies triggered by data in the live information flow.

[0054] In some embodiments, the system further includes program instructions for receiving a request to create a dynamic execution policy based on the data. The dynamic execution policy includes a designation of a source, a destination, an enforcement action, and a time period during which the dynamic execution policy is active. The system further includes program instructions for publishing the dynamic execution policy on a policy bus such that a plurality of agents can access the dynamic execution policy. The system further includes program instructions for taking enforcement action for another security event in one or more live information flows based on the dynamic execution policy, where at least one agent of the plurality of agents takes the enforcement action. The system further includes program instructions for (i) identifying an indicator of the execution policy and (ii) identifying a source and destination that pass through the indicator of the execution policy to reflect taking enforcement action for the another security event. The method further includes program instructions for updating a user interface by displaying a line connecting the destination.

[0055] In some embodiments, during the period during which a dynamic execution policy is active, the dynamic execution policy overwrites a static execution policy that contains the same specifications for source and destination contained in the dynamic execution policy.

[0056] In various embodiments, a non-transitory machine-readable storage medium storing instructions is provided. The instructions, when executed by one or more processors, cause the one or more processors to perform a method including monitoring live information flows. The live information flows include data flows from sources to destinations. The method further includes providing a user interface including sources and destinations connected via lines, and determining an occurrence of a security event in the live information flows based on a trigger of an execution policy. The execution policy includes a designation of a source, a destination, and an enforcement action, and if data in one or more live information flows matches at least a source and a destination of the execution policy, the execution policy is triggered and the enforcement action is applied. The method further includes updating the user interface to reflect the occurrence of a security event by (i) identifying an indicator of the execution policy, and (ii) displaying a line connecting a source and a destination that passes through the indicator of the execution policy.

[0057] In some embodiments, the source is displayed on one side of a user interface window and the destination is displayed on the other side of the window opposite the side having the source, and an indicator of the execution policy is displayed on the line between the source and destination.

[0058] In some embodiments, the method further includes monitoring one or more live information flows, the live information flows including (i) data flows from a plurality of sources to a plurality of destinations, and (ii) one or more execution policies triggered by the data, and the user interface further includes (i) one or more lines for connecting each source of the plurality of sources to each destination of a corresponding plurality of destinations, and (ii) an indicator on each line indicating an execution policy triggered by the data flowing between each source and each destination.

[0059] In some embodiments, the method further includes receiving user input corresponding to a selection of a particular source from the plurality of sources, and displaying a live information flow originating from the particular source including one or more execution policies triggered by data in the live information flow.

[0060] In some embodiments, the method further includes receiving user input corresponding to a selection of a particular destination from a plurality of destinations, and displaying a live information flow terminating at the particular destination including one or more execution policies triggered by data in the live information flow.

[0061] In some embodiments, the method further includes receiving a request to create a dynamic execution policy based on the data. The dynamic execution policy includes a specification of a source, a destination, an enforcement action, and a time period during which the dynamic execution policy is active. The method further includes publishing the dynamic execution policy on a policy bus such that a plurality of agents can access the dynamic execution policy. The method further includes performing enforcement actions for another security event in one or more live information flows based on the dynamic execution policy, where at least one agent of the plurality of agents performs the enforcement action. The method further includes (i) identifying an indicator of the execution policy and (ii) updating an indicator of the execution policy to reflect the execution of the enforcement action for the another security event. The method further includes updating a user interface by displaying a line connecting the source and destination passing through the indicator.

[0062] In some embodiments, during the period during which a dynamic execution policy is active, the dynamic execution policy overwrites a static execution policy that contains the same specifications for source and destination contained in the dynamic execution policy.

[0063] In various embodiments, a method is provided that includes monitoring live information flows using a computing system. The live information flows include data flows from sources to destinations. The method further includes using the computing system to provide a user interface including sources and destinations connected via lines, and using the computing system to determine the occurrence of a security event in the live information flows based on a trigger of an execution policy. The execution policy includes a designation of a source, a destination, and an enforcement action, and if data in one or more live information flows matches at least a source and a destination of the execution policy, the execution policy is triggered and the enforcement action is applied. The method further includes using the computing system to update the user interface to reflect the occurrence of a security event by (i) identifying an indicator of the execution policy, and (ii) displaying a line connecting a source and a destination that passes through the indicator of the execution policy.

[0064] In some embodiments, the source is displayed on one side of a user interface window and the destination is displayed on the other side of the window opposite the side having the source, and an indicator of the execution policy is displayed on the line between the source and destination.

[0065] In some embodiments, the method further includes using the computing system to monitor one or more live information flows, the live information flows including (i) data flows from a plurality of sources to a plurality of destinations, and (ii) one or more execution policies triggered by the data. The user interface further includes (i) one or more lines for connecting each source of the plurality of sources to each destination of a corresponding plurality of destinations, and (ii) an indicator on each line indicating an execution policy triggered by the data flowing between each source and each destination.

[0066] In some embodiments, the method further includes using the computing system to receive user input corresponding to a selection of a particular source from the plurality of sources, and using the computing system to display a live information flow originating from the particular source including one or more execution policies triggered by data in the live information flow.

[0067] In some embodiments, the method further includes using the computing system to receive user input corresponding to a selection of a particular destination from a plurality of destinations, and using the computing system to display a live information flow terminating at the particular destination including one or more execution policies triggered by data in the live information flow.

[0068] In some embodiments, the method further includes receiving, with the computing system, a request to create a dynamic execution policy based on the data. The dynamic execution policy includes a specification of a source, a destination, an execution action, and a time period during which the dynamic execution policy is active. The method further includes publishing, with the computing system, the dynamic execution policy on a policy bus such that multiple agents can access the dynamic execution policy. The method further includes publishing, with the computing system, the dynamic execution policy on a policy bus such that multiple agents can access the dynamic execution policy. and performing an enforcement action on another security event in the one or more live information flows based on the enforcement policy, where at least one of the plurality of agents performs the enforcement action. The method further includes updating, with the computing system, a user interface to reflect the enforcement action on the another security event by (i) identifying an indicator of the enforcement policy and (ii) displaying a line connecting a source and a destination that passes through the indicator of the enforcement policy. [Brief description of the drawings]

[0069] [Figure 1]FIG. 1 is a simplified block diagram illustrating a high-level threat intelligence platform according to some embodiments. [Diagram 2] FIG. 2 is a simplified block diagram illustrating a detailed architecture of an information management system according to some embodiments. [Diagram 3] FIG. 1 is a simplified block diagram illustrating some functional elements of a threat visualization system according to some embodiments. [Figure 4A] FIG. 1 illustrates a user interface (UI) for displaying active threat categories according to some embodiments. [Figure 4B] FIG. 1 illustrates a user interface (UI) for displaying active threat categories according to some embodiments. [Diagram 5] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 6] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 7] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 8] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 9] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 10] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 11] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 12A] FIG. 1 illustrates a UI for enabling an administrator to create one or more policies according to some embodiments. [Figure 12B] FIG. 1 illustrates a UI for enabling an administrator to create one or more policies according to some embodiments. [Figure 13] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 14] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 15] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 16] FIG. 13 illustrates an additional UI for displaying active threat categories according to some embodiments. [Figure 17] FIG. 1 illustrates a UI for displaying active threats based on triggered policies according to some embodiments. [Figure 18] FIG. 1 illustrates a UI for displaying tracking activity from various sources according to some embodiments. [Figure 19] 1 is a flowchart illustrating a process for publishing dynamic execution policies on a policy bus in a distributed environment according to some embodiments. [Figure 20] 1 is a flowchart illustrating a process for providing a consolidated view of active threat categories, the number of policies triggered for each threat category, and associated trends according to some embodiments. [Figure 21] 1 is a flowchart illustrating a process for providing a unified view of users, applications accessed by the users, and possible access policies associated with the access. [Figure 22] FIG. 1 is a simplified block diagram illustrating a distributed system that may be used to implement some embodiments of the present disclosure. [Diagram 23] FIG. 1 is a simplified block diagram illustrating one or more components of a system environment in which services can be provided as cloud services in accordance with some embodiments. [Figure 24] FIG. 1 illustrates an example computer system that can be used to implement some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0070] Detailed Description I. Introduction The following disclosure describes a threat intelligence platform that can provide real-time threat detection and analysis. In various embodiments, the provided system includes a processor and a memory that stores instructions. When executed by the processor, the instructions cause the processor to receive a security event from an agent, the security event including at least a destination and a source, trigger a policy when the security event matches the policy, the policy including a specification of a source, a destination, and an action to be taken, and to update a user interface to link the source and destination of the security event through the triggered policy. However, in an entity (e.g., a company, a country), thousands or hundreds of thousands of employees and other individuals (e.g., users, consultants, guests) are constantly accessing various services (e.g., sources) through a network, thus triggering security events. When people try to access a wide variety of services, various access violations and password errors, etc. occur, which need to be monitored. Currently, static security rules in a security policy cannot keep up with the ever-evolving threats to vulnerable users, vulnerable applications, and vulnerable hosts. Given the extremely high volume of user activity (e.g., billions of events per day), manual or home-grown analysis using a user interface would be cost prohibitive, and for a very large number of users, it would be difficult to perform highly accurate automated pattern detection to prevent unauthorized users from accessing the service.

[0071] To address these issues, various embodiments provide techniques (e.g., systems, methods, computer program products that store code or instructions executable by one or more processors) for analyzing security events with dynamic policies and displaying a unified view that includes active threats, user activity, and dynamic policies triggered by active threats and user activity. Some embodiments can track user access and collect information in real time to identify patterns, generate analytics, and take corresponding corrective actions. By collecting data in real time or near real time, corrective actions determined based on these data can be applied immediately. For example, when authenticating a user to an application, there may be a short time (e.g., milliseconds) to take action to prevent unauthorized users from accessing content. In additional or alternative embodiments, by collecting data in real time or near real time and storing a history of these data, real time By applying corrective actions determined based on the data and historical data, unauthorized users can be prevented from gaining access even after authenticating the user, and the user can be kicked off the network.

[0072] Some embodiments can provide visibility into user identities, resource usage patterns, and performance characteristics. Certain embodiments can utilize specific access controls to provide real-time enforcement. For example, certain embodiments can enforce compliance or block users from accessing unauthorized applications, perform adaptive authorization, authenticate users based on policies, and perform content inspection to prevent privacy and leaks. Certain embodiments can provide real-time enforcement using dynamic rules and analytics. Some embodiments can provide threat visualization to present real-time data analytics in a manner that is easily understandable to end users. By summarizing large amounts of data and presenting the analytics data in a real-time and meaningful manner, end users can identify actionable items and ensure that appropriate policies are updated and specific policies are enforced.

[0073] In one example, when a user enters a username and password into a login page and submits these user credentials, these user credentials are sent to the data collection bus in real-time or near real-time. In some examples, depending on tuning parameters (e.g., whether the collection bus is located in the cloud or not), data can be collected and sent in less than one second or 30 milliseconds. The transfer of data occurs with little delay (i.e., near real-time) except for network delays (e.g., if the agent is located on the host machine that collects the information and the data collection bus is located on another machine, e.g., the cloud). However, when the user enters the credentials, the system can determine whether these credentials are from a particular server and, in the case of suspicious activity, whether additional authentication needs to be presented to the user. When the user is accessing a page, if the system determines that the user should not be authorized even if the credentials are valid, the system can kick the user out of accessing the page.

[0074] In some embodiments, after a user logs into an account, the web proxy can constantly monitor and learn the user's activities and behaviors and can trigger anomalies (thereby presenting the user with additional authentication). For example, the user attempts to transfer a large amount of funds. This action triggers the system to present the user with additional authentication. In certain embodiments, the proxy can provide another source of information (e.g., traffic flow), where collected data is fed and analyzed in real time. When a user accesses a protected application or a cloud application that is not protected by an agent, the proxy server can determine the user's activities, for example, the user accesses a particular website to download information. The proxy server can monitor the user's activities and provide information that the user is blacklisted based on the collected data. Additionally, the proxy can provide historical information. This allows historical information about the user to be taken into account when granting access to the user when the user accesses a new site.

[0075] Some embodiments may provide available real-time data to a real-time visualization server to present analysis results to customers in real-time. When providing data to customers in real-time, action decisions can be made quickly depending on the real-time analysis results. Some embodiments may store data and use stored or historical data to By mining historical data, certain embodiments can create execution policies based on the historical data. Certain embodiments can trigger anomalies using both historical data and analysis results obtained in real time. Advantageously, these approaches can collect, monitor, and visualize very large amounts of security data (i.e., billions of streaming events) in real time and take corresponding actions.

[0076] II. System Architecture for Threat Detection FIG. 1 illustrates aspects of a system 100 for detecting threats in real-time by detecting anomalous access requests from a user, in accordance with at least one embodiment of the present disclosure. In some embodiments, the system 100 includes an access management and threat detection system 105 and an information management system 110 communicatively connected to a user device 115 via a network 120 in a distributed environment. The access management and threat detection system 105 and the information management system 110 are part of an identity access manager. There are various types of agents as part of the identity access manager that protect access to a web server or application. For example, when a user tries to access a mail server or a document server, a protection agent that communicates with the server (e.g., an OAM (Oracle Access Manager) server) may be configured to: The agent verifies whether the user has access to the server, for example by verifying the authentication information associated with the identity. Certain embodiments may have an extended agent and an access manager server. Thus, when a user is requesting data, information about who is accessing something is sent in real time to the data collection engine of the information management system 110.

[0077] The network 120 can facilitate communication and data exchange between the user devices 115, the access control and threat detection system 105, and the information management system 110. The network 120 can include, but is not limited to, TCP / IP, SNA, IPX, AppleTalk, and the like. Data communications may be supported using any of a variety of commercially available protocols, including but not limited to, any type of network known to those skilled in the art. By way of example only, network 115 may be a local area network (LAN), such as an Ethernet network, a token ring network, a wide area network, a virtual network, including but not limited to a virtual private network (VPN), the Internet, an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., using the IEEE 802.1X protocol suite, the Bluetooth protocol, and / or other protocols known in the art). or networks operating under any other wireless protocol) and / or combinations of these and other networks.

[0078] The user device 110 may be a PC running a variety of operating systems (e.g., various versions of Microsoft Windows and / or any part running the Apple Macintosh operating system The user device 110 may be a general-purpose personal computer (including a personal digital computer and / or laptop computer), a mobile phone or PDA (e.g., running software such as Microsoft Windows Mobile® and enabled for Internet, email, SMS, Blackberry® or other communications protocols), a workstation computer running any of the various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, the various GNU / Linux® operating systems), or other computing device. For example, the user device 110 may be a thin-client computer, an Internet-enabled gaming system, and / or a personal digital assistant (PC) capable of communicating over a network (e.g., network 115). The user devices may be other electronic devices such as social messaging devices. Although the exemplary system environment 100 is shown with one user device, in other embodiments, any number of user devices and / or client computing devices may be supported.

[0079] The access management and threat detection system 105 may include one or more computers and / or servers. These computers and / or servers may be general-purpose computers, dedicated server computers (including, by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers), server farms, server clusters, or any other suitable configuration and / or combination. The computing devices that make up the access management and threat detection system 105 may run any operating system or a variety of additional server applications and / or mid-tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, and the like. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle, Microsoft, Sybase, IBM, and the like.

[0080] In various embodiments, the access management and threat detection system 105 may include one or more elements operable to protect resources 125 provided by one or more target systems 130 of an organization. In some embodiments, a "target system" may refer to any system that provides or includes one or more resources. The locally or remotely accessible resources 125 provided by the target system 130 may be of various types including software products, applications (e.g., cloud applications, enterprise applications or other applications), cloud services, various types of data (e.g., network files, directory information, databases, etc.) and other resources. The target system 130 may include one or more databases, Lightweight Directory Access Protocol (LDAP) servers, Active Directory (AD) systems, email systems, UNIX systems, etc. For example, the target system 130 may be an Active Directory (AD) system that provides access to an Active Directory service, such as accessing an Active Directory server. In some examples, the target system 130 may be a computing system that provides access to a conference room, such as a computing system that provides access to a conference room using a badge. In some embodiments, the target system 130 may be referred to as an application instance.

[0081] In certain embodiments, access to resources 125 provided by the target system 130 can be managed using various types of accounts in the target system 130. Accounts can be created in the target system 130 based on the resources 125 provided by the target system 130. The accounts may include various types of accounts such as user accounts, administrative accounts, application accounts, etc. Each type of account grants a particular level of access to one or more resources 125 provided by the target system 130. To allow a user to access or log in to the target system 130, the target system 130 can include respective accounts (e.g., user accounts, administrative accounts, and / or application accounts). Accounts can be created or provisioned for a user or a user group based on the identity of the user or user group (e.g., an organization). A user or a user group can be given a particular type of account to access a particular type of resource. For example, a user An email account on an Exchange server given to is an account for an Exchange resource. A user may be given multiple accounts, with each type of account corresponding to each type of resource. For example, a user may have two different accounts to log into the target system 130 and perform different types of operations. For example, the target system 130 may host an email exchange server and provide an email account. The same target system 130 may also host a human resources (HR) system and provide an HR administrative account to perform administrative functions related to the HR system. A particular user may have an email account on the target system 130 as well as an HR administrative account on the target system 130. When logging in with the email account, the user may access emails. When logging in with the HR administrative account, the user may perform administrative tasks related to managing resources for the organization.

[0082] According to at least some embodiments, a user of the user device 115 can communicate with the target system 130 to request a resource 125 (e.g., an email application) by accessing a web-based request user interface (UI) on the user device 115. For example, the request UI can include a graphical user interface viewable via a client application (e.g., a browser) on the user device 115. When a user wishes to access or attempt to perform an operation on a resource on the target system 130, the access management and threat detection system 105 intercepts the access request from the user and attempts to authenticate / authorize the user. For example, the access management and threat detection system 105 can obtain the user's authentication information (e.g., login ID and password) by providing the user with a login page. The access management and threat detection system 105 can then determine whether the user is an authorized user based on the user's login credentials. The access management and threat detection system 105 may be configured to receive various types of access requests, e.g., web requests, SDK requests, programmatic requests, from users over various channels (HTTP, OAP) for various events / actions (e.g., authentication (authN), authorization (authZ), policy validation, step-up authentication, SSO, token issuance).

[0083] In various embodiments, the access management and threat detection system 105 includes one or more agents 135, one or more proxies 140 (e.g., forward or reverse proxies), one or more access managers 145, and / or one or more web gates 150. The access management and threat detection system 105 may be implemented in the system 100 according to an agent-server model for enabling communication between the user device 115 and the target system 130 (e.g., distributed environment server) to provide access control functions to the resource 125. The agent-server model may include an agent element (e.g., one or more agents 135, also known as single sign-on agents or policy enforcement agents, one or more proxies 140, and / or one or more web gates 150) and a server element (e.g., one or more access managers 145, also known as single sign-on servers or policy servers). For example, one or more access managers 145 may act as decision elements for controlling access to resources 125, and one or more agents 135, one or more proxies 140, and / or one or more webgates 150 may be implemented or operate as enforcement elements for controlling access to resources 125. In some embodiments, one or more agents 135, one or more proxies 140, and / or one or more webgates 150 may be deployed with resources 125, as plug-ins to or as part of resources 125, and one or more agents 135, one or more proxies 140, or one or more webgates may be implemented or operate as enforcement elements for controlling access to resources 125. 150 may be deployed separately from resources 125, for example running on a web server in front of resources 125. One or more access managers 145 may be deployed as part of an identity access manager.

[0084] The access management and threat detection system 105 can provide SSO functionality in the distributed environment and can perform various access control related functions to manage access to resources in the distributed environment. For example, one or more agents 135, one or more proxies 140, one or more access managers 145, and / or one or more web gates 150 can perform authentication of a user operating a user device 115. Authentication is the process for determining that a user is who he or she claims to be. To authenticate a user, the access management and threat detection system 105 can present a request to the user (e.g., via the user's web browser) to request authentication information in the form of a challenge. An execution policy (e.g., an authentication policy) can specify the authentication method to be used to authenticate a user who should be granted access to a given resource. These policies define how access to the resource should be protected (e.g., type of encryption, etc.). One or more access managers 145 can determine the authorization of a user to access a resource 125. Authorization is the process for determining whether a user has access to a requested resource. Execution policies (e.g., authorization policies) may be defined to specify the conditions under which a user or group of users has access to certain resources. For example, an administrator may authorize a particular user in a group to have access to a particular resource.

[0085] The one or more agents 135 may be policy enforcement agents that act as filters for resource requests. The one or more agents 135 may intercept resource requests and determine whether the requested resource is protected by the access management and threat detection system 105 by applying static and dynamic execution policies. If protected, the resource request may be forwarded to one or more access managers 145 that may determine whether the user requesting the protected resource may access the protected resource. In certain embodiments, one or more web gates 150, an innovative solution developed by Oracle Corporation, may be used as agents to filter resource requests. According to some embodiments, the one or more agents 135 and the one or more web gates 150 may be hardware structures or a combination of hardware and software implementations.

[0086] The one or more proxies 140 may be policy enforcement agents that act as filters for resource requests. For example, the one or more proxies 140 may be authentication proxies for handling user authentication for resources. The authentication proxies may be invoked (e.g., instantiated) by web applications or resources to provide authentication functionality. In some embodiments, the authentication proxies may include a high-level API that integrates one or more low-level authentication schemes to allow programs that rely on authentication to be designed and written independent of the underlying authentication scheme. The one or more proxies 140 may intercept resource requests and determine whether the requested resource is protected by the access management and threat detection system 105 by applying static and dynamic execution policies. If protected, the resource request may be forwarded to one or more access managers 145 to determine whether the client requesting the protected resource may access the protected resource. An example of an authentication proxy is the pluggable authentication module (PAM) used in Linux systems. According to some embodiments, The one or more proxies 140 may be hardware structures or a combination of hardware and software implementations.

[0087] The one or more access managers 145 may have multiple elements for performing the authentication and / or authorization process. The one or more access managers 145 may also include one or more authentication schemes. The authentication scheme may be configured to protect resources with one or more access policies (e.g., static execution policies and dynamic execution policies as described herein). The authentication scheme may include details regarding the credential collection mechanism and the type of credential collector used to collect the credential information. For example, the collection of the credential information may be performed using an HTTP(S) transport channel for handling HTTP(S) requests from a remote user. In certain embodiments, the authentication scheme may specify a redirect Uniform Resource Locator (URL) that is used to notify the user device 115 of the success or failure of the authentication and / or authorization process. The authentication scheme may also specify an authentication level that represents a trust level for protecting the transfer of the credential information from the user device 115. For example, a Lightweight Directory Access Protocol (LDAP) may be used to identify the authentication level. The LDAP (Internet Directory Access Protocol) scheme may be a second level of authentication using an LDAP authentication module to protect manager-related resources such as URLs based on a form authentication method. In the form authentication method, an HTML form with one or more text input fields may be used to collect authentication information. In some embodiments, the form authentication may collect authentication information such as a username, password, social security number, date of birth, one-time password, or other common combination of parameters.

[0088] 1 further illustrates an example of an SSO session managed in a distributed environment implementing an access management and threat detection system 105 including one or more agents 135, one or more proxies 140, one or more access managers 145, and / or one or more web gates 150. For example, a user may operate a user device 115 to request access to a resource 125 controlled by a target system 130. The request is routed to or intercepted by one or more agents 135, one or more proxies 140, and / or one or more web gates 150 that control access to the resource 125. In some embodiments, some resources managed by one or more agents 135, one or more proxies 140, and / or one or more web gates 150 may not be protected. In this case, one or more agents 135, one or more proxies 140, and / or one or more web gates 150 may determine whether the requested resource is protected by querying one or more access managers 145. The one or more access managers 145 determine whether authentication is required to access the resource 125 by checking an execution policy associated with the resource 125. If the requested resource is protected and requires authentication upon use, the one or more access managers 145 may determine whether a session exists for the user. If it determines that a session does not exist for the user, the one or more access managers 145 forward the user to a login service (e.g., an authentication service) of an identity access manager. The authentication service may request authentication information (e.g., username / password, etc.) from the user. Upon receiving the appropriate authentication information, the authentication service may authenticate the user by comparing the received authentication information with that stored in a user directory or identity store.

[0089] Based on the received user's appropriate authentication information, the one or more access managers 145 may then assign the user to one or more agents 135, one or more proxies 140 and / or one or more The one or more agents 135, one or more proxies 140, and / or one or more web gates 150 may verify the authentication and establish a first session for the authenticated user. As a result, the user is logged into that session on the target system 130 (e.g., a distributed environment server). Once logged in, the user may utilize resources to which he or she has been granted access, such as running different applications, utilizing cloud storage, etc. When the user logs into the target system 130, the one or more access managers 145 may create a cookie to track the user's session activity. The cookie may include the time the user has been active on the session. The cookie may be stored in the information management system 110 as session activity data.

[0090] If it is determined that the user is authenticated to the SSO session, the one or more agents 135, the one or more proxies 140 and / or the one or more webgates 150 process the original request for the resource 125 by forwarding an authorization query to the one or more access managers 145. The one or more access managers 145 determine whether the user is permitted to access the resource 125 by checking an execution policy associated with the resource 125. The one or more access managers 145 send an allow or deny message to the one or more agents 135, the one or more proxies 140 and / or the one or more webgates 150 based on the execution policy. If it is determined that the user is permitted to access the resource 125, the one or more agents 135, the one or more proxies 140 and / or the one or more webgates 150 authorize the request to access the resource 125 from the user device 115. This allows the user to access the resource 125 on the target system 130 from the user device 115. If it is determined that the user's access to the resource 125 is denied, the one or more agents 135, the one or more proxies 140 and / or the one or more webgates 150 notify the user device 115 that the user's access to the resource 125 is not permitted.

[0091] The information management system 110 may include one or more computers and / or servers. These computers and / or servers may be general purpose computers, dedicated server computers (including, by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers), server farms, server clusters, or any other suitable configuration and / or combination. The computing devices that make up the information management system 110 may run any operating system or a variety of additional server applications and / or mid-tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, and the like. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle, Microsoft, Sybase, IBM, and the like. In various embodiments, the information management system 110 supports the access management and threat detection system 105 to protect and authorize users' access to the resources 125. The information management system 110 may be configured to obtain additional information related to a user's access request to authenticate / authorize the user's access to the target system 130. This information may include, for example, the IP address of the client sending the request, device information, user information, the requested resource, and the time the request was sent. The information management system 110 may also be configured to analyze this information to create and publish new policies (e.g., dynamic inspection and execution policies) to override static policies over a period of time. In some embodiments, the available real-time data is visually presented to the customer as part of the system threat analysis results. Providing data to the customer in real-time allows for quick action decisions to be made in response to the real-time threat analysis results. Various embodiments may store data and use the stored data (i.e., historical data) to create additional rules and policies that can be applied in real time. Certain embodiments may mine the historical data to create dynamic inspection and execution policies based on the historical data. In other embodiments, dynamic inspection and execution policies may be created using both historical data and analysis of information obtained in real time.

[0092] FIG. 2 illustrates aspects of an information management system 200 (e.g., the information management system 110 described with reference to FIG. 1) for collecting information of users accessing resources, publishing policies based on analysis results of the information, and visualizing the analysis results of the information. In some embodiments, the information management system 200 includes a collection bus 205 and a policy bus 210 communicatively connected to an access management and threat detection system 215 (e.g., the access management and threat detection system 105 described with reference to FIG. 2) via a network (i.e., the network 120 described with reference to FIG. 1). The information management system 200 may also include an analysis server 220, a machine learning component 225, a visualization server 230, one or more agents 235, one or more proxies 240, one or more access managers 245, one or more webgates 250, and a system memory 255 communicatively connected to the collection bus 205 and the policy bus 210.

[0093] The collection bus 205 and the policy bus 210 comprise a network topology in which nodes such as the analysis server 220, the machine learning component 225, the visualization server 230, one or more agents 235, one or more proxies 240, one or more access managers 245, and / or one or more webgates 250 are connected to a common linear (or branching) link called a bus or enterprise service bus. The collection bus 205 and the policy bus 210 implement a software architecture for performing distributed computing. Distributed computing includes routing messages and data between various nodes, managing the placement of various policies (inspection and execution policies), providing services to facilitate the collection of data based on the inspection policies, and publishing various policies (inspection and execution policies) to listeners (i.e., agents).

[0094] The analysis server 220, the machine learning component 225, and the visualization server 230 may include one or more computers and / or servers. These computers and / or servers may be general-purpose computers, dedicated server computers (including, by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers), server farms, server clusters, or any other suitable configuration and / or combination. The computing devices that make up the analysis server 220, the machine learning component 225, and the visualization server 230 may run any operating system or a variety of additional server applications and / or mid-tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, and the like. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle, Microsoft, Sybase, IBM, and the like.

[0095] System memory 255 may be one or more storage media including, for example, a non-transitory machine-readable storage medium such as flash memory, permanent memory such as read only memory (ROM), semi-permanent memory such as random access memory (RAM), other suitable types of non-transitory storage devices, or any combination thereof. According to different aspects, memory 255 stores computer-readable program instructions, data structures, program modules, and other data associated with the operation of system 200. According to particular aspects, memory 255 may be a non-transitory memory, such as ... In the system, data information relating to the operating system, application programs, policies, user activities and access requests, and program data can be stored.

[0096] 2 is deployed, the access management and threat detection system 105 (configured by one or more agents 235, one or more proxies 240, one or more access managers 245 and / or one or more webgates 250 as described with reference to FIG. 1) can determine whether an end user is authenticated and / or authorized to access a resource on a target system based on the rules in the static and dynamic execution policies. The rules can include a destination (e.g., URL of the target system or resource such as an application or service, host name, destination IP address or port), a source (e.g., user ID, user group designation, IP address of the client device), a time period (e.g., a predetermined time for which the policy is in effect), and an enforcement action (e.g., block access by the user, require authentication / authorization factors, monitor activity). If network traffic or user activity patterns match a rule in a policy, the policy is triggered and enforcement action is applied. The static and dynamic execution policies may be stored in memory 255 as a static policy cache 265 and a dynamic policy cache 270, respectively.

[0097] In a particular embodiment, the general method is as follows: An end user enters a URL or ID to request a resource on a protected policy domain. The user's browser sends the URL as part of an HTTP request to a web server. One or more agents 235, one or more proxies 240, and / or one or more web gates 250 recognize and intercept the request. If the end user is not yet authenticated, one or more agents 235, one or more proxies 240, and / or one or more web gates 250 ask the web server to issue a challenge to the browser requesting login information. The received login information is then returned to the web server and passed to one or more agents 235, one or more proxies 240, and / or one or more web gates 250. One or more agents 235, one or more proxies 240, and / or one or more web gates 250 send an authentication request to one or more access managers 245, which determine whether the login information provided by the user is authentic. The one or more access managers 245 perform authentication using attributes of the user's identity information and the resource's authentication criteria stored in memory 255. If the login information provided by the user meets the authentication criteria, the process proceeds as follows, otherwise the end user is notified that access to the requested resource is denied and the process ends.

[0098] After authenticating the user, the one or more agents 235, the one or more proxies 240 and / or the one or more webgates 250 inquire to the one or more access managers 245 whether the user is authorized to access the requested resource. Accordingly, the one or more access managers 245 inquire to the information management system 200 for the appropriate authorization criteria of the requested resource. The one or more access managers 245 retrieve the authorization criteria of the resource and respond to the authorization query of the one or more agents 235, the one or more proxies 240 and / or the one or more webgates 250 based on the authorization criteria of the resource and the user's identity information. If the user is authorized, the user's access to the resource is permitted. Otherwise, the user's request is denied. Various alternatives to the above flow are also within the spirit and scope of the present invention.

[0099] Authentication and authorization decisions may be made based on policy domains and policies (e.g., static execution policies and dynamic execution policies). A policy domain is a logical group that includes the server host IDs, host names, URL prefixes, and rules. The host names and URL prefixes specify the course-grain portion of the web namespace that is protected by a particular policy domain. The rules of a policy domain specify the conditions that allow or deny access to requested resources, and the end users to whom these conditions apply. A policy domain consists of two levels of rules: first-level default rules and second-level rules that are included in the policy. The first-level default rules can apply to any resource in the policy domain that is not associated with a policy, and the second-level rules can apply to any resource in the policy domain that is associated with a policy. A policy is a group that includes URL patterns, resource types, operation types (such as request methods), and rules to restrict access to specific resources per user, static or dynamic group membership, time or day of the week, IP (Internet Protocol) addresses, and so on. A policy can be a static or dynamic policy associated with a policy domain, and specifies the fine-grain portion of the web namespace that is protected by the policy. In practice, the hostnames and URL prefixes of a policy domain are logically associated with the URL patterns of a policy. The entire resulting pattern is compared with the incoming URL. If there is a match, it is decided whether to authorize or deny the request by evaluating the various rules of the policy. If there is no match, the default policy domain rules are used.

[0100] Static and dynamic execution policies are statements that summarize attributes to express what is allowed and what is not allowed. An execution policy can use any kind of attribute (user attribute, resource attribute, object, action, environment attribute, etc.) and includes logic such as Boolean logic. In this case, the rules include statements (e.g., "IF, THEN") to evaluate the attributes and determine what is allowed and what is not allowed (e.g., whether the requesting user is authenticated, whether the requesting user is authorized to access the requested resource, whether the requesting user is authorized to make the request to the requested resource). For example, if the requester is a manager, read / write access to sensitive data is allowed. Static execution policies include default rules or rules that are written / rewritten (e.g., created by an administrator of the system) over the life of the system to evaluate the evolving system dynamics or attributes. However, the rules included in a static policy are not written / rewritten in real time. This allows the policy to evaluate the evolving system dynamics or attributes in real time. A dynamic execution policy, on the other hand, includes rules that are written / rewritten (eg, created by machine learning techniques or by an administrator of the system) to evaluate the evolving dynamics or attributes of the system in real time.

[0101] In various embodiments, systems and methods are provided for creating and executing static and dynamic policies based on threat detection. Static and dynamic execution policies may be executed along an execution path by various agents (e.g., one or more agents 235, one or more proxies 240, and / or one or more webgates 250). These policies may be understood as applying to the agent's position in the execution path, respectively. In some embodiments, dynamic policies may be created manually by an administrator or automatically deployed to the system by the machine learning component 225. Also, in certain embodiments, a period of execution (e.g., a predetermined period) of a dynamic policy may be specified. For example, by setting a policy for a predetermined period (e.g., 5 minutes, 10 minutes, 4 hours, 1 day, 2 weeks, etc.), the analysis server 220 and / or administrator can monitor and trigger anomalies based on data within the predetermined period. After the predetermined period has elapsed, the policy is invalidated. Thus, some embodiments can monitor the behavior of the system with newly added dynamic policies, ensuring system stability. The monitored dynamic policies may be modified to become solid or permanent (i.e., not limited by a predefined time period). Some embodiments use machine learning capabilities to create dynamic policies for a predefined time period (e.g., the next 30 minutes) and eventually use the dynamic policies to permanently overwrite the static policies set in the system. It is noted that it is inefficient and resource-consuming for security administrators looking at visualization applications to quickly generate and deploy these policies to the system, regardless of whether a full approval process needs to be performed.

[0102] In some embodiments, if the machine learning component 225 does not affect the policy, a sticky policy (i.e., a static policy that cannot be overridden) can be created. In other embodiments, the machine learning component 225 can learn a default policy or a policy created by an administrator (e.g., a static policy that can be overridden) and can modify these policies or override these policies with a dynamic policy. In certain embodiments, the machine learning can modify a default policy or a static policy previously created by a system administrator based on additional data and can override the default policy or the static policy. For example, an anomaly can be classified into a specific category that corresponds to a block policy. The block policy can be a high warning policy and can override another category, such as second factor authentication. This can present the user with a form or question for additional authentication if the user performs some action, even if the user is in a valid session. In other embodiments, a block policy (e.g., a policy with logic configured to block a user or user group from actions such as reading / writing to a resource) can be specified not to be created. This allows an administrator to monitor the types of policies triggered by the machine learning. For example, an administrator might watch for the first few months to see that the machine learning creates multiple high alerts under certain circumstances or when there are certain patterns, validate those alerts, and determine that the machine learning is not creating a large number of false positive alerts. The administrator could then adjust the policy to create a second factor authentication policy for a pattern rather than creating a high alert for that pattern.

[0103] In one example, a user may access a server (e.g., a target system) from home or another location from 7:00 am to 9:00 am every day and from work or headquarters from 10:00 am to 4:00 pm every day. If the user travels to another location and tries to access the server, the analysis server 220 determines that the access is anomalous and triggers second factor authentication because the system is configured with an anomaly default or static policy that triggers second factor authentication when the location data does not match the historical data. After a certain period of time, the system can learn and adapt from the default or static policy and determine based on the user's behavioral patterns not to trigger an anomaly when the user is traveling to another location. The system can also identify the user's behavioral patterns. The system can intelligently determine whether an anomaly should be triggered or not based on the historical data and updated real-time data. The machine learning component 225 can create and modify end-user identity information or behavioral models and policies for managing behavior by constantly learning from the historical data and real-time data. These identity information and policies are updated in real time, rather than updated weekly or biweekly. This ensures that the next anomaly detection takes into account all historical and real-time data of user activity. Thus, the next decision can quickly take into account what may be identified as an anomaly. Thus, in this example, the new location is updated in memory 255. Because the policy is set, the next time the user logs in while in this geographic location, activity on the system will not trigger the anomaly detection. In effect, a new dynamic policy has been created that overwrites the previous policy.

[0104] FIG. 2 further illustrates a mechanism for event / data collection. In some embodiments, when the machine learning has more processing data, the machine learning component 225 can generate more execution policies and find more and more complex patterns. In certain embodiments, the event / data collection is dynamic and the inspection policy mechanism can facilitate the collection of data. The collected data can be fed into the machine learning. This can create more execution policies and trigger anomalies triggered by the execution policies. For example, when installing a new application, the system can launch an inspection policy (either automatically via the collection bus 205 and the analysis server 220 or manually via an administrator) to understand how the application functions. The inspection policy can generate data by examining user activity on the application, taking into account the rules of the inspection policy. The collection bus 205, the analysis server 220, and the machine learning component 225 can automatically classify the activity based on the collected data and determine whether the activity is a low warning activity, a medium warning activity, or a high warning activity based on patterns identified from the data. The analysis server 220 and machine learning component 225 can then automatically generate dynamic inspection and execution policies based on the data collected by the collection bus 205, and the generated policies can be published on the policy bus 210 and used by agents for a given period of time to overwrite static policies.

[0105] In certain embodiments, all data published within the enterprise (e.g., on the enterprise's network) can be collected in real time via the collection bus 205 and used and analyzed by the analytics server 220. In some embodiments, the analytics server 220 can perform event correlation, generate reports, and publish the reports on the report bus 275. The machine learning component 225 continuously receives information in real time from the report bus 275 and provides the information to a user interface via the visualization server 230. The machine learning component 225 also uses real-time events and historical data from the collection bus 205, memory 255, and report bus 275. Thus, the machine learning component 225 can discover anomalies and publish policies (check policies or execution policies) to the policy bus 210.

[0106] In the prior art, agents are configured to collect data, record the data as log ASCII data name and value pairs, and send the logs to a server periodically (e.g., every 5 or 10 minutes). Because agents are located in the cloud and servers may be located within or outside the enterprise, transferring these logs can be expensive. Also, it takes time to accumulate logs and send them in bulk. Instead of collecting and sending log ASCII data name and value pairs, various embodiments transfer data from various agents to the collection bus 205 in real time using binary data so that the data is highly compressed. Certain embodiments transfer values ​​and mechanisms to map the data. For example, an agent can send a value to the collection bus 205, and the collection bus 205 can determine the format (e.g., Schema 1) sent from the agent. Once the format is identified, the value is translated. This is a way to compress and transfer data efficiently.

[0107] In various embodiments, the system includes one or more agents 235, one or more proxies 240, one or more access managers 245, and one or more webgates 25. 0, threats can be detected and triggered based on the data captured and sent by the agent. When the agent needs to support newer target systems, applications and changes to existing application interfaces, a set of predefined attributes (e.g., user attributes, resource attributes, object, action, environment attributes, etc.) may not be sufficient. Thus, with a dynamic inspection policy, the system can ask the agent to collect / inspect additional information or attributes, such as data in various payloads (e.g., HTTP), by sending dynamic rules to the agent. This information is reported as part of the normal access request event. The machine learning component 225 can then detect anomalies in this new data or information and trigger more anomalies by inserting dynamic execution policies. As more anomalies are triggered, additional execution policies can be created to prevent certain types of traffic. This completes the collection, detection and execution cycle.

[0108] The collection bus 205 may be configured to obtain information related to security events, such as access requests from end users, and report the information or data to the report bus 275. The collection bus 205 may be configured based on a default or static inspection policy that includes rules for collecting a set of predefined attributes (e.g., user attributes, resource attributes, object, action, environment attributes, etc.) when certain criteria are met. In certain embodiments, the inspection policy monitors data and notifies an administrator when certain criteria match a predefined pattern. The inspection policy does not trigger an alert when the pattern exists, but collects a set of predefined attributes when the pattern exists. For example, the system may provide an inspection policy user interface (UI) to allow an administrator to specify a particular inspection policy to be triggered when a set of criteria is met (e.g., when header data matches a threshold time window). According to other aspects, the collection may be configured based on a dynamic inspection policy that includes rules for collecting data or attributes. For example, the collection bus 205 and the analysis server 220 can work together to collect a set of predefined attributes and trigger anomalies based on previously configured rules (default policy, static policy, or dynamic inspection and execution policy). The inspection policy can specify the set of predefined attributes to be collected and the criteria for patterns in the data to be identified. After collecting the attributes and patterns via the collection bus 205, the analysis server 220 can inspect the attributes and patterns in the data and determine whether these attributes and patterns match the rules defined in the execution policy. Once the data enters the collection bus 205, it is stored in the memory 255 and becomes part of the historical data. The machine learning component 225 can create and modify the inspection and execution policies to efficiently collect information required for threat assessment of user activities on the system by constantly learning from the historical and real-time data.

[0109] The information related to the event may be collected from one or more agents, including one or more agents 235, one or more proxies 240, one or more access managers 245, and / or one or more webgates 250 (described with reference to FIG. 1), and may include, for example, the IP address of the client sending the request, device information, user information, the requested resource, and the time the request was sent. In certain embodiments, the information is further collected from third party agents, including GPS applications, weather applications, monitoring software, hardware sensors, load balancing software, etc. in the client device. The information may be collected asynchronously by the collection bus 205. For example, the collection bus 205 may include queues configured to process the information, index the information in real time, and perform data aggregation and query operations on the information. In some examples, the collection bus 205 collects information about the access requests received from the users, such as client context, resource context, user context, It may be configured to organize the information or data obtained and organized from the user activities into various categories such as server context, timestamp, session information, and server instance for processing the request. In various embodiments, the collection bus 205 is configured to store the information or data obtained and organized from the user activities in an information database 260 in the memory 255.

[0110] FIG. 2 illustrates a mechanism for creating a dynamic execution policy based on collected events / data and publishing the dynamic execution policy for execution by agents (e.g., one or more agents including one or more agents 235, one or more proxies 240, one or more access managers 245, and one or more webgates 250) via policy bus 210. In some embodiments, analysis server 220 and machine learning component 225 are configured to create a dynamic execution policy for a user or user group by analyzing real-time incoming data and historical data regarding access requests received from the user or user group (e.g., stored in memory 255) over a period of time. In one embodiment, analysis server 220 and machine learning component 225 may be configured to generate a dynamic execution policy for a user or user group by identifying a parameter subset associated with the real-time incoming data and historical data of access requests by the user or user group, and create the dynamic execution policy by analyzing the real-time incoming data and historical data of access requests against the parameter subset. For example, the analytics server 220 and the machine learning component 225 may be configured to create an execution policy by analyzing access requests of a user or user group and monitoring the access times of the users based on time parameters (e.g., times) during which the users or user groups typically access one or more applications stored on the target system over a period of time. The execution policy may include rules to request second factor authentication or to block the user or user group if the user or user group attempts to access one or more applications at times other than the normal time parameters.

[0111] In some embodiments, the monitored parameter subset may be specified / defined by the resources (e.g., target application) on the target system accessed by the user, and the target application may provide this information to the analytic server. For example, the target application (e.g., financial application) may want to track the access requests of users based on parameters such as user ID, access time, and access duration. These parameters are set with the analytic server 220, and the machine learning component 225 can create an execution policy for a user or user group by analyzing real-time incoming data and historical data of access requests against these parameters over a period of time. In certain embodiments, if data satisfying the monitored parameter subset is not collected, the analytic server 220 and the machine learning component 225 may be configured to create a dynamic inspection policy that is triggered to obtain data satisfying the parameter subset when certain criteria are met (e.g., when a user or user group logs into the system).

[0112] In certain embodiments, the analytics server 220 and machine learning component 225 may be configured to generate multiple policies for a user or user group. These policies may be generated by analyzing real-time incoming and historical data of access requests by a user or user group against different sets of parameters associated with the access requests. For example, as described above, the analytics server 220 and machine learning component 225 may generate policies for a user or user group based on the time that the user or user group typically accesses various applications stored on the target system. In another example, the analysis server 220 and the machine learning component 225 may be configured to generate a time-dependent policy for a user or a user group by analyzing an access request of the user or the user group. In another example, the analysis server 220 and the machine learning component 225 may be configured to generate an application access pattern policy for a user by analyzing a pattern of the user accessing various applications stored in the target system. The analysis server 220 and the machine learning component 225 may be configured to generate a policy for a user by obtaining characteristics of security threats, intrusions, and denial of service (DOS) attacks from the access request.

[0113] In some embodiments, the analytics server 220 and the machine learning component 225 may be configured to generate policies by classifying real-time incoming data and historical data of access requests associated with a user or user group into one or more data clusters. In certain embodiments, the analytics server 220 and the machine learning component 225 may be configured to generate one or more data clusters using supervised or unsupervised machine learning or other clustering (e.g., K-means) techniques. In various embodiments, the machine learning component 225 may be configured to calculate the distance of the access request from the centroid of the cluster using a density-based clustering algorithm and unsupervised learning using Euclidean distance. In certain examples, the radius of the cluster is calculated based on the average distance of each point in the cluster from the centroid. Points located outside the radius have a higher risk based on the standard deviation. The closer the user activity on the enterprise network is to the centroid, the lower the risk of access.

[0114] In a particular example, real-time incoming data and historical data of parameters configured by the analytic server 220, the machine learning component 225, and / or the integrated application (e.g., the application that the user is trying to access) become data points for constructing clusters. After constructing the clusters, the analytic server 220 and the machine learning component 225 may be configured to generate a policy including rules for one or more data clusters. For example, a rule may be constructed such that if certain parameters (x, y, and z) of a request by a user or user group do not match the parameters (x, y, and z) of the cluster, an action is performed, for example, performing second factor authentication or blocking the user or user group. As a result, when a new request is received from a user or user group, it may be determined whether the access request from the user or user group is abnormal by matching the values ​​of the parameters obtained from the request with the rules in the policy including the parameters of the already established cluster.

[0115] In some embodiments, the analytics server 220 and the machine learning component 225 may be further configured to classify policies based on a threat level after establishing the clusters. The threat level may be determined based on the distance from the center of the cluster. As an example, a traffic pattern on an enterprise network may have attributes that are used to generate policies according to rules set in a criteria, such as the distance of the traffic pattern from one or more clusters. If the distance is 1x (e.g., 1 standard deviation from the mean), the policy is classified as low risk and the associated traffic pattern triggers a low alert. If the distance is 2x (e.g., 2 standard deviations from the mean), the policy is classified as medium risk and the associated traffic pattern triggers a medium alert. If the distance is more than 3x (e.g., more than 3 standard deviations from the mean), the policy is classified as a block and the associated traffic pattern triggers a block of the activity. Thus, the customer does not need to worry about whether the traffic pattern is an abnormal pattern or not. Instead, the customer focuses on whether the traffic pattern created a low alert, a medium alert, a high alert, a second factor authentication, or a block. It is possible.

[0116] As described herein, policies may be generated by the analysis server 220 and machine learning component 225 or an administrator (a person who sees anomalies occurring). Some embodiments use Structured Threat Information eXpression (STIX) as a standard for declaring policies. In various embodiments, once a policy (e.g., a new dynamic execution policy) is established or generated, it is published to the policy bus 210 and executed by an agent (e.g., one or more agents 235, one or more proxies 240, one or more access managers 245, and / or one or more web gates 250). When a policy is being executed by an agent, the agent becomes part of the execution ecosystem. For example, upon receiving a new access request from a user or user group, the one or more agents 235, one or more proxies 240, one or more access managers 245, and / or one or more web gates 250 are configured to determine whether the access request of the user or user group is anomalous by analyzing information related to the access request against the execution policy (default, static, or dynamic policy).

[0117] In some embodiments, one or more agents 235, one or more proxies 240, one or more access managers 245, and / or one or more webgates 250 may be configured to first select a policy for a user or user group from a plurality of execution policies published on the policy bus 210. In certain embodiments, a policy may be specifically associated with a user or user group. The selection may be based, for example, on the type of application to which the user or user group is requesting access. For example, if a user or user group is requesting access to a financial application on the target system, one or more agents 235, one or more proxies 240, one or more access managers 245, and / or one or more webgates 250 may be configured to select a policy from the plurality of policies to analyze a subset of parameters defined by the financial application. For example, as described above, the financial application may want to analyze an access request from a user or user group based on parameters such as user ID, access time, and access duration. In other embodiments, one or more agents 235, one or more proxies 240, one or more access managers 245 and / or one or more webgates 250 may be configured to retrieve all of the execution policies published on the policy bus 210 and analyze an access request from a user or user group based on parameters from all or some of the policies.

[0118] After selecting or obtaining a particular policy, the one or more agents 235, the one or more proxies 240, the one or more access managers 245, and / or the one or more webgates 250 may be configured to determine whether a user's access request is anomalous by analyzing information related to the access request against the policy. In some embodiments, the one or more agents 235, the one or more proxies 240, the one or more access managers 245, and / or the one or more webgates 250 may be configured to determine an anomalous request by determining a deviation of the access request from one or more data clusters generated by the analytics server 220 and the machine learning component 225. If the deviation exceeds a predetermined threshold, the request is determined to be anomalous. The threshold may be determined by a user (e.g., an administrator) of the system or automatically by the analytics server 220 and the machine learning component 225. In certain embodiments, the threshold may be a Mahalanobis distance that takes into account the correlation of the data sets of the clusters.

[0119] Each agent can react independently to the published policy to achieve the same end goal (e.g., not granting access to the protected resource to unauthorized / unauthenticated users). In certain embodiments, once an anomaly is detected and a policy to block a user is created (e.g., in STIX format) and published to the policy bus 210, one or more agents 235, one or more proxies 240, one or more access managers 245, and / or one or more webgates 250 can select or retrieve the policy and determine a role to play in blocking a user or user group. For example, when a user or user group is accessing an application, one or more access managers 245 become the entity to validate the user's credentials and authenticate the user to be part of an authentication session, and one or more agents 235, one or more proxies 240, and / or one or more webgates 250 can initiate, maintain, or disconnect the session so that the user can be challenged and authenticated at any time when the user is accessing a resource in any part of the execution ecosystem. One or more proxies 240 can continuously monitor and learn the user or user group activities taking place and, based on the policy, can take action to trigger anomalies and block the activities. For example, one or more proxies 240 can obtain information of a blocked user from the policy, and when a session request is received from an IP address corresponding to the user, one or more proxies 240 can block the creation of the session. Thus, even if the resource is not protected by other agents, one or more proxies 240 can take their own action on the user activities because they have the same policy as the policy bus 210.

[0120] Additionally or alternatively, the one or more agents 235, the one or more access managers 245, and / or the one or more web gates 250 can continuously monitor and learn the activities that a user or group of users is performing (e.g., a user is trying to enter a username or password into a login page, a user is trying to access a protected application, or a user is trying to access another web site from an authorized session) and take action to trigger anomalies and block the activities based on the same policy. For example, the one or more agents 235 and / or the one or more web gates 250 can check whether a session is still valid based on whether a period has expired. In some examples, a time session is valid for a predefined period of time, e.g., 1 hour or 8 hours. When a session becomes invalid, a user is requested to log in again. The one or more agents 235 and / or the one or more web gates 250 can validate the session with the policy and disconnect the session when the session becomes invalid. The one or more access managers 245 can also obtain the same policy. Thus, the next time the same user attempts to log in using the correct username and password, one or more of the access managers 245 may not allow the user access. Thus, even if a resource is not protected by one or more of the agents, e.g., one or more of the proxies 240, one or more of the agents 235, one or more of the access managers 245 and / or one or more of the webgates 250 may take their own actions in response to user activity because they have the same policies as the policy bus 210. Thus, unlike conventional systems where agents react similarly as a group once a rule is determined, each agent may react to a policy in a different way.

[0121] 2 further illustrates a mechanism for providing a user interface based on the execution of static and dynamic policies on event / data collection and user activity. In various embodiments, a unified user interface 280 is provided from visualization server 230. In some embodiments, unified user interface 280 provides a list of active threat categories, the number of policies triggered for each threat category, and and associated trends. In another embodiment, the unified user interface 280 includes users, sources being accessed by the users, and possible policies associated with such activities. In yet another embodiment, real-time statistics are exposed and displayed on the unified user interface 280 at predefined time intervals (e.g., 2 seconds, 4 seconds, 5 seconds, 30 seconds), at different time frames such as 5 minutes or 15 minutes. This allows security administrators to take appropriate action on the "real-time trends."

[0122] The integrated user interface 280 may be presented to the security administrator when he logs into the system. The integrated user interface 280 may present the top users generating network traffic and the sources these users are accessing. Real-time data collected from the collection bus 205 may be fed into the system. The integrated user interface 280 may present how frequently users accessed different sources on the network over a period of time (e.g., 5 minutes or 30 minutes). The integrated user interface 280 may be continually updated as new data comes in, for example showing "current time - 5 minutes". The top active IP addresses may also be shown. Some embodiments may show correlations between highly active IP addresses and popular and high traffic sources (e.g., URLs). Certain embodiments may also mark (e.g., with a star) the IP addresses of unidentified users.

[0123] Some embodiments may present client IP address-application mappings in addition to user-application mappings. Particular embodiments may show that many different sources can be accessed from a particular IP address, or vice versa, all different users can access a particular URL. The unified user interface 280 presents the end users (or client IP addresses) on one side and the end sources on the other side. Some embodiments may also use color to distinguish between groups. Certain embodiments may also present information such as the number of times each application was accessed. Some embodiments may present the number of times an application was accessed from a particular user or client IP address by selecting the particular user or client IP address.

[0124] In some embodiments, an administrator can specify one or more comparison criteria and criteria values ​​via the integrated user interface 280. In certain embodiments, an administrator can also specify, via the integrated user interface 280, a desired alert and alert period when one or more criteria and criteria values ​​of an event match the criteria and criteria values ​​specified by the administrator. For example, in some embodiments, a corresponding alert specified by the administrator can be provided when a user and client IP address matches a destination (e.g., a hostname, a specific IP address, a service) that the user is accessing or matches a user's activity.

[0125] III. Unified User Interface 3 is a block diagram illustrating some functional elements of a threat visualization system 300, according to various embodiments. The illustrated system includes three layers: a presentation layer 305, an application layer 310, and a database layer 315. The presentation layer 305 includes multiple user interfaces (e.g., graphical user interfaces (GUIs)). A user (e.g., a customer or an administrator) can monitor user activities on a company's network through the multiple user interfaces to detect threats in real time. The multiple user interfaces include multiple UIs. 3, including integrated user interfaces 320, 325, 330, and 335 (e.g., integrated user interface 280 described with reference to FIG. 2). In some embodiments, UIs 320, 325, 330, and 335 reside on one or more workstations. In other embodiments, UIs 320, 325, 330, and 335 reside on one or more personal computers. In general, UIs 320, 325, 330, and 335 may reside on any computing system. Note that although four UIs are shown in FIG. 3, any number of UIs may be developed and provided in accordance with aspects described herein.

[0126] The UIs 320, 325, 330, and 335 are connected to one or more application servers 340 and 345 in the application layer 310 (e.g., the analytics server 220, the machine learning component 225, and the visualization server 230 described with reference to FIG. 2). The application servers 340 and 345 perform operations to facilitate real-time assessment of security and threats on the enterprise infrastructure network by exchanging and processing information between the UIs 320, 325, 330, and 335 and the enterprise network. In various embodiments, the application servers 340 and 345 facilitate the assessment of security and threats through a set of mechanisms described herein. The application servers 340 and 345 can be located in several places in the distributed computing system, including computational or database servers, and can communicate with any UI in the presentation layer.

[0127] The application servers 340 and 345 are connected to a database management system 350 (e.g., memory 255 described with reference to FIG. 2) in the database layer 315. The database management system 350 may be any type of custom or commercially available database system capable of managing the storage and retrieval of data. In some embodiments, the database management system 350 includes a database server or the like. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®. The database management system 350 is connected to a cache and database 355 (e.g., caches 265, 270 and database 260 described with reference to FIG. 2). The cache and database 355 may be any type of cache or database capable of storing and retrieving data. Examples of databases include, but are not limited to, hierarchical and relational databases.

[0128] In various embodiments, the presentation layer 305, application layer 310, and database layer 315 operate to provide UIs 320, 325, 330, and 335 that include active threat categories, the number of policies triggered for each threat category, and associated trends. As shown in FIG. 4A and FIG. 4B, some embodiments can provide a consolidated UI 400 of active threats based on a classification scheme of threat levels. As described herein, the execution policies (e.g., static policies and dynamic policies) can be classified into block policies, step-up or second factor policies, high warning policies, medium warning policies, and low warning policies, respectively. For example, the analytics server 220 and machine learning component 225 can dynamically create an “Abnormal Application Access” policy, e.g., as a low warning if only one access is observed. However, based on other factors, the same policy can be deployed as a second factor policy to block access by unauthorized users. The application layer 310 can use such a classification scheme of policy enforcement actions to display a dashboard 402 in the integrated UI 400 that includes various buckets corresponding to block 405, step up or second factor 410, high warning 415, medium warning 420, and low warning 425. The classification scheme of threat levels of policy enforcement actions allows administrators to evaluate policies and escalate from low to high levels and vice versa. Some embodiments may also include a machine learning component 225 when evaluating policies or determining whether to raise or lower the threat level of a policy. Additionally, by providing an integrated active threat UI 400 based on threat level instead of policy name, security management groups can focus on different types of threats and actions based on classification instead of interpreting threat levels based on policy names.

[0129] Buckets 405, 410, 415, 420, and 425 may include a total number "n" 430 of policies that are triggered by user activity on the enterprise network at any given time and have a corresponding classification. Buckets 405, 410, 415, 420, and 425 may further include, for each classification, an associated trend in the number "n" 430 of triggered policies. For example, a graphic such as a marker 435 and a graph 440 may be used to show a historical trend corresponding to the number "n" 430 of triggered policies. In some embodiments, if the number "n" 430 of triggered policies is increasing (e.g., n+1, 5, 10, 15, etc.), an up arrow may be used to easily show such a trend. In contrast, if the number "n" 430 of triggered policies is decreasing (e.g., n-1, 5, 10, 15, etc.), a down arrow may be used to easily show such a trend. If the number of triggered policies "n" 430 is substantially similar (e.g., + / - 5%, 10%, or 15%), the circles can be used to easily show such trends. In certain embodiments, buckets 405, 410, 415, 420, and 425 further include a drop-down box 445 that an administrator can utilize to further explore details regarding the policies triggered on the enterprise network and the activities being performed by users (sources being accessed). In certain embodiments, unified UI 400 further includes an additional bucket 450 to show the total number of policies "m" (all classification groups) being executed at any given time.

[0130] According to various aspects described herein, user behavior on the enterprise network can be monitored and one or more dynamic policies can be created for the user. In some embodiments, an administrator or machine learning component 225 can set an execution policy for a particular behavior to trigger a block, a second factor authentication, a low warning, a medium warning, or a high warning. For example, the machine learning component 225 can detect a fluctuation or deviation in real-time data from historical data (e.g., a user normally accesses from home around 7:00 or 8:00 PM, but today the user is accessing from a different location) and can create a policy for this anomalous access. The policy can specify a warning level (e.g., low, medium, or high warning), a second factor authentication, or a block for the access. Based on whether the user was authenticated with the challenge presented via the second factor authentication, the system can utilize the historical data to modify the policy. If the user's further behavior increases the warning level and the new policy specifies the user's behavior as a high warning behavior, the unified user interface 400 can start presenting the high warning behavior via the dashboard 402. If there have been multiple (e.g., 10 or 20) high alerts for this user in a short period of time (e.g., the last 10 seconds or last 20 seconds), there may be a problem and the machine learning component 225 can alert an administrator via the integrated user interface 400.

[0131] In some embodiments, the dashboard 402 can include various windows 455 that display information including top access activity, top users accessing sources, top IP addresses being used to access sources, and top sources being accessed. Top or bottom may be defined as a threshold number, for example, top or bottom 5, 10, 15, 35, or 50. Alternatively, top or bottom may be defined as a threshold number, for example, top or bottom 5, 10, 15, 35, or 50. For example, the top or bottom 5%, 10%, 15%, 35%, or 50% threshold percentages may be defined. The window 455 may display the information using any graphical means. For example, the top access activity may be displayed using a pictogram or line diagram 460 showing a line connecting each user ID or IP address to the resource or target system being accessed. Additionally or alternatively, the top users may be displayed using a proportional area chart, bubble chart, or tag cloud 465 with typographical modifications such as font size or color. Additionally or alternatively, the top IP addresses may be displayed using a proportional area chart, bubble chart, or tag cloud 470 with typographical modifications such as font size or color. Additionally or alternatively, the application may display using a proportional area chart, bubble chart, or tag cloud 475 with typographical modifications such as font size or color.

[0132] In some embodiments, the presentation layer 305, application layer 310, and database layer 315 may further operate to provide additional functionality or information to an administrator. For example, as shown in FIG. 5, an administrator may view resources 515 accessed by a particular user 505 in a dashboard window 510 by placing an input device such as a mouse pointer over that particular user. Also, as shown in FIG. 6, an administrator may view a particular count or number of times 615 that a user or IP address accessed a resource by placing an input device such as a mouse pointer over a particular URL 605 in a dashboard window 610. As shown in FIG. 7, an administrator may view various users 715 accessing a particular URL 705 in a dashboard window 710 by placing an input device such as a mouse pointer over that URL. As shown in FIG. 8, an administrator may selectively monitor a particular user 805 by selecting the particular user 805 from a dashboard window 810 with an input device such as a mouse pointer. As shown in FIG. 9, an administrator may monitor the activity 905 of a particular user 910 using a proportional area chart 915 or a bubble chart. As shown in Figure 10, an administrator can view the number of times 1005 a particular user 1010 has accessed a URL 1015 in a proportional area chart 1020 or bubble chart by placing an input device, such as a mouse pointer, over the URL. As shown in Figure 11, an administrator can monitor the activity of multiple users 1105 using multiple proportional area charts 1110 or bubble charts.

[0133] In some embodiments, the presentation layer 305, application layer 310, and database layer 315 may further operate to provide an administrator with additional functionality for creating one or more policies (e.g., inspection policies or execution policies). FIGS. 12A and 12B show an example of a UI 1205 for enabling an administrator to create one or more policies according to certain embodiments. In some embodiments, an administrator may create one or more policies using any of the UIs described herein after observing anomalous activity. An administrator may specify a source 1210 of the policy by specifying a user ID, IP address, or group, or may specify any source by leaving source 1210 blank. An administrator may specify a destination 1215 of the policy by using a hostname, target system name or ID, IP address, resource name, or may specify any destination by leaving destination 1215 blank. An administrator may specify an enforcement action 1220 of the policy. Enforcement action 1220 may include low warning, medium warning, high warning, second factor authentication, or block. Additionally, the threat level detected from anomalous activity can be used to classify policies as low risk, medium risk, high risk, second factor authentication risk, or block risk. Administrators can An administrator can specify a period or a predefined period 1225 for which the policy will be active. In some embodiments, the period 1225 can be 5, 15, 30, or 60 minutes. This allows an administrator to see the impact of the policy on network traffic through any of the UIs described herein for the predefined period. Then, if the policy does not have the intended effect or is no longer applicable to anomalous activity, the administrator can let the policy expire or extend its active state by changing the period 1225. In certain embodiments, the period 1225 can be permanent. This allows an administrator to permanently override a static policy or change the security strategy on the enterprise network in real time.

[0134] In some embodiments, the presentation layer 305, application layer 310, and database layer 315 may further operate to provide additional functionality or information to an administrator. Some embodiments may show an administrator the number of policies of a particular type (e.g., block policies) in a particular time interval. In certain embodiments, an administrator may view (e.g., by selecting a UI element) the policies that caused a particular action or warning (e.g., block). For example, as shown in FIG. 13, according to certain embodiments, an administrator may view the names of the top policies 1305 of each category in window 1310 by selecting the corresponding mode 1315 (e.g., top block policies mode). Also, in some embodiments, an administrator may view the top users 1320 associated with the top policies 1305 and who have violated the policies multiple times in window 1325. Top or bottom may be defined as a threshold number, for example, top or bottom 5, 10, 15, 35, or 50. Alternatively, top or bottom may be defined as a threshold percentage, for example, top or bottom 5%, 10%, 15%, 35%, or 50%. As shown in FIG. 14, according to some embodiments, an administrator can view the enforcement actions (e.g., blocks) taken based on the resources 1405 and top policies 1305 in window 1410. These displays allow an administrator to see the users, resources, IP addresses, and policies associated with the top policies that have been triggered for each classification or detected threat level. In some embodiments, an administrator can select a particular user to view the number of alerts triggered by that particular user (e.g., 15 blocks and 2 second factors triggered by that user).

[0135] By presenting different types of information to the administrator, the administrator can take appropriate action (e.g., in response to different trends). By the UI described herein showing an upward trend for a particular alert, the administrator can take appropriate action only in response to the upward trend when seeing an upward trend for the alert. In some embodiments, the administrator can see the users / client IP addresses / sources accessing a particular application that were blocked by a high alert according to a particular policy. When viewing policies, some attributes allow the administrator to distinguish between manually deployed policies and machine learning policies. In some embodiments, the administrator can only edit manually created policies, not machine learning policies.

[0136] In various embodiments, an administrator monitors low, medium, and high alerts and provides recommendations on the need to modify the particular policy that caused the alert, e.g., the high alert for a block policy. Other system administrators are notified of the recommended policy to change and can decide whether or not to upgrade the policy to a block policy. As shown in FIG. 15, according to certain embodiments, an administrator can view the names of the top policies 1505 for each classification (e.g., high alert) in window 1510 by selecting the corresponding mode 1515 (e.g., high alert policy mode). 16, according to some embodiments, an administrator can view resources 1605 in window 1610 and the action taken based on higher level policies 1505 (e.g., high warning), and can view IP addresses 1615 in window 1620 and the action taken based on higher level policies 1505 (e.g., high warning).

[0137] In various embodiments, the presentation layer 305, application layer 310, and database layer 315 operate to provide UIs 320, 325, 330, and 335 that include users, resources being accessed by the users, and possible policies associated with the access activities. As shown in FIG. 17, some embodiments can provide a unified UI 1700 that shows active threats based on triggered policies. For example, in certain embodiments, an administrator can see which policies caused a particular action or alert (e.g., block). As shown in FIG. 17, an administrator can see a window 1705 that shows the source 1705 (e.g., user ID, group designation, IP address, client device ID, etc.) of the activity on the enterprise network that is triggering the policy, an indicator showing the name or classification of the triggered policy 1710 (e.g., static execution policy and dynamic execution policy), and the destination 1715 (e.g., resource or service being accessed) of the activity from the source 1705. These displays allow an administrator to see which policies and resources were triggered by each user. In some embodiments, an administrator can select a particular user to focus on policies triggered by that particular user (e.g., this user triggered 15 block policies and 2 second factor policies). As shown in Figure 18, an administrator can view trace activity for various sources 1805, client IP address 1810, destination IP port 1815, destination hostname 1820, request URL 1825, each policy 1830 that was triggered, and policy classification 1840 showing the action taken against policy 1830. In some embodiments, a search bar 1845 can be used to search for trace activity.

[0138] IV. PROCESSES AND OPERATIONS FOR UTILIZING THE THREAT INTELLIGENCE PLATFORM 19-21 illustrate techniques for analyzing security events using dynamic policies to provide a unified view including active threats in a distributed environment, user activity, and dynamic policies triggered by active threats and user activity, according to some embodiments. Individual embodiments may be described as a process that is depicted as a flowchart, flow diagram, data flow diagram, structure diagram, or block diagram. Although a flowchart describes operations as a sequential process, many operations may be performed in parallel or simultaneously. Also, the order of operations may be changed. A process terminates when the operations are completed, but may include additional steps not included in the drawings. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, and the like. When a process corresponds to a function, the termination of the process may correspond to a return to the calling function or the main function.

[0139] The processes and / or operations illustrated in FIGS. 19-21 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processor cores) hardware, or a combination thereof. The software may be stored in memory (e.g., memory device, non-transitory computer-readable storage medium). The particular sequence of process steps illustrated in FIGS. 19-21 is not intended to be limiting. Other sequences of steps may be performed according to alternative embodiments. For example, in alternative embodiments, the steps described above may be performed in a different order. Also, each step illustrated in FIGS. 19-21 may include multiple sub-steps that may be performed in various orders as appropriate for each step. Furthermore, additional steps may be added or removed depending on the particular application. Those skilled in the art will recognize many variations, modifications, and alternatives.

[0140] FIG. 19 is a flowchart 1900 illustrating a process for creating and publishing a dynamic policy, according to various embodiments. In some embodiments, the process illustrated in the flowchart 1900 may be implemented by the access management and threat detection system 105 and the information management system 110 illustrated in FIG. 1 and described with reference to FIG. 2. In step 1905, a distributed environment is provided or instantiated, including a user device, a plurality of agents, a collection bus, a policy bus, and a target system having resources. In some embodiments, the distributed environment further includes an analysis server and a machine learning component, and the inspection policy and the dynamic execution policy are created by the analysis server and the machine learning component. In certain embodiments, the distributed environment further includes a memory for storing the inspection policy, the dynamic execution policy, and historical data received from one or more information flows.

[0141] In optional step 1910, a verification policy may be created based on historical data or a target system or resource specification. In some embodiments, the collection of data is triggered by a verification policy published on the policy bus. For example, the collection bus may be configured to obtain information related to security events, such as end-user access requests, and report the information or data to the report bus. The collection bus may be configured based on a default or static verification policy that includes rules for collecting a set of predefined attributes (e.g., user attributes, resource attributes, object, action, environment attributes, etc.) when certain criteria are met. In certain embodiments, the system may provide a verification policy UI through which an administrator can create a verification policy by specifying a specific verification policy that is triggered when a set of criteria is met (e.g., if header data matches for a certain time interval). In other embodiments, the collection bus may be configured based on a dynamic verification policy that includes rules for collecting data or attributes. For example, the collection bus and the analysis server may work together to collect a set of predefined attributes and trigger an anomaly based on previously configured rules (default, static or dynamic verification and execution policies). The inspection policy includes rules for collecting data in real time, which is a set of predefined attributes about a security event when a set of criteria about the security event matches a predefined pattern. After the data is collected by the collection bus, it is stored in memory and becomes part of the historical data. By constantly learning from the historical and real-time data, the machine learning component can create and modify the inspection and execution policies to efficiently collect information required for threat assessment of user activity on the system.

[0142] In optional step 1915, the inspection policy may be published or deployed on a policy bus so that multiple agents can access the inspection policy. Publishing the inspection policy on the policy bus facilitates data collection by allowing listeners (i.e., agents) to access the policy and execute the policy to collect a set of predefined attributes based on previously configured rules. In step 1920, data regarding the security event may be collected. In various embodiments, the data includes (i) a source to identify a user or user device, and (ii) a destination to identify a target system or resource. The data may be collected from at least one agent of the multiple agents by the collection bus. In some embodiments, the data is collected according to a default, static, or dynamic inspection policy. For example, if criteria of a live information flow, including a data flow from a source to a destination, matches a predefined pattern in a default, static, or dynamic inspection policy, the inspection policy is invoked and one or more agents are prompted to determine the attributes (e.g., source and destination) of the information flow or the attributes occurring within the information flow. The collected security events may then be sent to a collection bus for further processing according to various aspects described herein.

[0143] In step 1925, a dynamic execution policy may be created based on the data. The dynamic execution policy includes at least a source, a destination, an execution action, and a designation of a time period during which the dynamic execution policy is active. The time period may be a predetermined time period of at least 5 minutes, at least 10 minutes, at least 30 minutes, or at least 1 hour, for example, 10 minutes, 30 minutes, 1 hour, 5 hours, 1 day, or 3 days. During the time period during which the dynamic execution policy is active, the dynamic execution policy overrides a static execution policy that includes at least the same source and the same destination designation. For example, the static execution policy is default or active for a user or user group from an IP address whenever a user from that IP address attempts to access a resource on a specified target system that requires a first level of authentication. The dynamic execution policy may be exposed for a user or user group from an IP address whenever a user from that IP address attempts to access a resource on a specified target system that requires a second factor authentication. The dynamic execution policy may have a time period of 5 hours. Thus, if the static execution policy is inactive for a predetermined period of time (e.g., 5 hours), then the dynamic execution policy is active (e.g., second factor authentication is performed for access requests from an IP address to a particular target system) for the predetermined period of time (e.g., 5 hours). After the predetermined period of time (e.g., 5 hours) has elapsed, the dynamic execution policy becomes inactive and is removed from the policy bus, and the static execution policy becomes active (e.g., first level authentication is performed for access requests from an IP address to a particular target system).

[0144] In certain embodiments, the system may provide an execution policy UI, through which an administrator may create a dynamic execution policy by specifying a specific enforcement action that is triggered when a set of attributes is met (e.g., when live information flow matches the source and destination of the policy). In other embodiments, the analytics server and machine learning component create the dynamic execution policy. Creating the dynamic execution policy includes classifying real-time collected data and historical data into one or more data clusters, analyzing a set of predefined attributes with the one or more data clusters, and creating a source, destination, enforcement action, and time period for which the dynamic execution policy is active based on the analysis. The one or more data clusters may be generated using supervised or unsupervised machine learning or clustering techniques, and the analysis may include calculating a distance from a centroid of the one or more data clusters to the set of predefined attributes. Enforcement actions, such as block authentication or second factor authentication, may be determined based on a distance from a centroid of the one or more data clusters to the set of predefined attributes.

[0145] In step 1930, the dynamic execution policy may be published on a policy bus such that the multiple agents may access the dynamic execution policy. Publishing the dynamic execution policy on the policy bus facilitates, for example, threat detection on an enterprise network by allowing listeners (i.e., agents) to access the policy and actuate the enforcement actions of the policy based on previously configured rules. In step 1935, enforcement actions may be taken on security events based on the dynamic execution policy. In some embodiments, at least one agent of the multiple agents executes enforcement actions. Enforcement actions are taken when it is determined that attributes (e.g., source and destination) of an information flow or a security event occurring within an information flow match attributes (e.g., source and destination) of a specified dynamic execution policy. If so, enforcement action may be taken by at least one agent of the plurality of agents. Enforcement action may then be taken by at least one agent of the plurality of agents, for example, by (i) blocking user access to the destination before the user's access is authorized, (ii) disconnecting the user from the destination, (iii) blocking authentication of the user on the system, (iii) requiring second factor authentication or authorization, or (iv) reporting a low alert, a medium alert, or a high alert.

[0146] FIG. 20 is a flowchart 2000 illustrating a process for providing a consolidated view of active threat categories, the number of policies triggered for each threat category, and associated trends. In some embodiments, the process illustrated in flowchart 2000 may be implemented by the access management and threat detection system 105 and the information management system 110 illustrated in FIG. 1 and described with reference to FIG. 2. In step 2005, a distributed environment is provided or instantiated that includes a user device, a plurality of agents, a collection bus, a policy bus, and a target system having resources. In some embodiments, the distributed environment further includes an analysis server and a machine learning component, and the inspection policy and the dynamic execution policy are created by the analysis server and the machine learning component. In certain embodiments, the distributed environment further includes a memory for storing the inspection policy, the dynamic execution policy, and historical data received from one or more information flows.

[0147] At step 2010, one or more live information flows can be monitored. The live information flows can include data flows from multiple sources to multiple destinations. In some embodiments, the monitoring is performed by multiple agents. The monitoring can be performed according to various policies (e.g., inspection policies and enforcement policies). At step 2015, a user interface can be provided that includes multiple buckets. Each bucket can be associated with a different threat level or enforcement action, and each bucket includes an associated threat level or enforcement action and displays a total number of current enforcement policies that are being triggered in real time. As shown in FIG. 4A, the buckets are essentially graphical silos categorized according to the same classification scheme (e.g., block, second factor authentication, low warning, medium warning, high warning, etc.) that is assigned to enforcement policies based on the threat level or enforcement action declared for each policy. By providing a unified UI of active threats based on threat level or enforcement action buckets rather than policy names, security management groups can focus on different types of threats and actions based on classification rather than interpreting threat levels based on policy names.

[0148] In step 2020, the occurrence of a security event in one or more live information flows is determined based on the triggering of the execution policy. The execution policy may include a specification of a source, a destination, and an execution action, and if data in one or more live information flows matches at least the source and destination of the execution policy, the execution policy is triggered and the execution action is applied. In step 2025, the user interface may be updated to reflect the occurrence of the security event by (i) identifying a bucket from the multiple buckets associated with the execution action applied by the execution policy, and (ii) incrementing a total number of current execution policies triggered in real time by the execution action and displayed in the identified bucket. In some embodiments, incrementing the total number of execution policies includes incrementing a count number n of the total number of execution policies to a count number n+1. In optional step 230, a trend indicator indicating the identified bucket may be updated based on the occurrence of the security event. For example, updating the trend indicator may include displaying an up arrow, a down arrow, or a colorless circle in the identified bucket.

[0149] In optional step 2035, user input corresponding to a selection of a bucket from a plurality of buckets may be received. In some embodiments, in response to the selection, a live information flow including a plurality of sources and a plurality of destinations corresponding to the selected bucket may be displayed in the user interface. In other embodiments, in response to the selection, a plurality of sources corresponding to the selected bucket may be displayed in the user interface as a tag cloud. The tag cloud may show a plurality of sources corresponding to the selected bucket in proportion to the utilization of each source.

[0150] In optional step 2040, user input corresponding to a selection of a particular source from the plurality of sources may be received. In some embodiments, in response to the selection, a live information flow originating from the particular source is displayed. In optional step 2045, user input corresponding to a selection of a particular destination from the plurality of destinations may be received. In some embodiments, in response to the selection, a live information flow ending at the particular destination is displayed. In optional step 2050, the live information flow including the plurality of sources and the plurality of destinations may be displayed in a user interface. In some embodiments, an indicator may be provided that indicates a set of top sources based on an amount of data flowing from the plurality of sources to the plurality of destinations. In optional step 2055, the live information flow including the plurality of sources and the plurality of destinations may be displayed in a user interface. In some embodiments, an indicator may be provided that indicates a set of top destinations based on an amount of data flowing from the plurality of sources to the plurality of destinations. In optional step 2060, the live information flow including the plurality of sources and the plurality of destinations may be displayed in a user interface. In some embodiments, an indicator may be provided that indicates a set of top execution policies based on an amount of data flowing from the plurality of sources to the plurality of destinations and a set of active execution policies published on the policy bus.

[0151] In optional step 2065, a request to create a dynamic execution policy based on the data can be received. The dynamic execution policy can include a specification of a source, a destination, an enforcement action, and a time period during which the dynamic execution policy is active. In optional step 2070, the dynamic execution policy can be published on a policy bus so that multiple agents can access the dynamic execution policy. As described herein, the time period can be a predetermined period of at least 5 minutes, at least 10 minutes, at least 30 minutes, or at least 1 hour, for example, 10 minutes, 30 minutes, 1 hour, 5 hours, 1 day, or 3 days. During the time period during which the dynamic execution policy is active, the dynamic execution policy overwrites a static execution policy that includes at least the same source and the same destination specification. In optional step 2075, enforcement action can be performed on another security event in one or more live information flows based on the dynamic execution policy. At least one agent of the multiple agents can perform the enforcement action. In optional step 2080, the user interface can be updated to reflect the execution of an enforcement action for another security event by (i) identifying a bucket from the multiple buckets that is associated with the enforcement action applied by the enforcement policy, and (ii) increasing the total number of current enforcement policies triggered in real time by the enforcement action and displayed in the identified bucket.

[0152] 21 is a flowchart 2100 illustrating a process for providing a unified view of users, applications accessed by the users, and possible access policies associated with the access. In some embodiments, the process illustrated in flowchart 2100 may be implemented by the access management and threat detection system 105 and information management system 110 shown in FIG. 1 and described with reference to FIG. 2. Step 21 At 05, a distributed environment is provided or instantiated including a user device, a plurality of agents, a collection bus, a policy bus, and a target system having resources. In some embodiments, the distributed environment further includes an analytics server and a machine learning component. The inspection policy and the dynamic execution policy are created by the analytics server and the machine learning component. In certain embodiments, the distributed environment further includes a memory for storing the inspection policy, the dynamic execution policy, and historical data received from one or more information flows.

[0153] At step 2110, live information flows can be monitored. The live information flows can include data flows from sources to destinations. In some embodiments, the monitoring is performed by multiple agents. The monitoring can be performed according to various policies (e.g., inspection policies and execution policies). At optional step 2115, one or more live information flows can be monitored. For example, one or more additional live information flows can be monitored. The additional live information flows can include (i) data flows from multiple sources to multiple destinations, and (ii) one or more execution policies triggered by the data. At step 2120, a user interface can be provided that includes the sources and destinations connected via lines. For example, as shown in FIG. 17, each source included in the live information flow can be connected via a graphical line to one or more destinations being accessed. Optionally, when monitoring additional live information flows, the user interface can further include (i) one or more lines for connecting each source of the multiple sources to each destination of the corresponding multiple destinations, and (ii) an indicator on each line that indicates an execution policy triggered by the data flowing between each source and each destination.

[0154] In step 2125, the occurrence of a security event in a live information flow can be determined based on the triggering of an execution policy. The execution policy can include a designation of a source, a destination, and an enforcement action, and if data in one or more live information flows matches at least the source and destination of the execution policy, the execution policy is triggered and the enforcement action is applied. In step 2130, the user interface can be updated to reflect the occurrence of a security event by (i) identifying an indicator of the execution policy, and (ii) displaying a line connecting the source and destination that passes through the indicator of the execution policy. In some embodiments, the source is displayed on one side of a window of the user interface, the destination is displayed on the other side of the window opposite the side having the source, and the indicator of the execution policy is displayed on the line between the source and the destination.

[0155] In optional step 2135, user input corresponding to a selection of a particular source from the plurality of sources may be received. In some embodiments, in response to the selection, a live information flow originating from the particular source including one or more execution policies triggered by data in the live information flow is displayed. In optional step 2140, user input corresponding to a selection of a particular destination from the plurality of destinations may be received. In some embodiments, in response to the selection, a live information flow ending at the particular destination including one or more execution policies triggered by data in the live information flow is displayed. In optional step 2145, the live information flow including the plurality of sources and the plurality of destinations may be displayed in a user interface. In some embodiments, an indicator may be provided that indicates a set of top sources based on the amount of data flowing from the plurality of sources to the plurality of destinations. In optional step 2150, the live information flow including the plurality of sources and the plurality of destinations may be displayed in a user interface. In some embodiments, an indicator may be provided that indicates a set of top destinations based on the amount of data flowing from the plurality of sources to the plurality of destinations. A live information flow involving multiple sources and multiple destinations can be displayed in a user interface at step 2155. In some embodiments, an indicator can be provided that shows a set of top execution policies based on the amount of data flowing from the multiple sources to the multiple destinations and the set of active execution policies published on the policy bus.

[0156] In optional step 2160, a request to create a dynamic execution policy based on the data can be received. The dynamic execution policy can include a specification of a source, a destination, an enforcement action, and a time period during which the dynamic execution policy is active. In optional step 2165, the dynamic execution policy can be published on a policy bus so that multiple agents can access the dynamic execution policy. As described herein, the time period can be a predetermined period of at least 5 minutes, at least 10 minutes, at least 30 minutes, or at least 1 hour, for example, 10 minutes, 30 minutes, 1 hour, 5 hours, 1 day, or 3 days. During the time period during which the dynamic execution policy is active, the dynamic execution policy overwrites the static execution policy that includes at least a specification of a similar source and a similar destination. In optional step 2170, enforcement action can be taken for another security event in one or more live information flows based on the dynamic execution policy. At least one agent of the multiple agents can execute the enforcement action. In optional step 2175, the user interface may be updated to reflect the execution of enforcement actions for another security event by (i) identifying an enforcement policy indicator and (ii) displaying lines connecting the source and destination that pass through the enforcement policy indicator.

[0157] V. Computing Environment 22 is a simplified diagram illustrating a distributed system 2200 for implementing one embodiment of the disclosure. In the illustrated embodiment, the distributed system 2200 includes one or more client computing devices 2202, 2204, 2206, and 2208 configured to execute and operate client applications, such as a web browser or a dedicated client (e.g., Oracle Forms), via one or more networks 2210. A server 2212 may be communicatively coupled to the remote client computing devices 2202, 2204, 2206, and 2208 via the network 2210.

[0158] In various embodiments, the server 2212 may be configured to run one or more services or software applications, such as applications for providing services and identity management services. In certain embodiments, the server 2212 may provide other services and software applications may include non-virtualized and virtualized environments. In some embodiments, these services may be provided as web or cloud services, or as Software as a Service (SaaS). Based on the model, services provided by these components may be provided to users of client computing devices 2202, 2204, 2206, and / or 2208. Users operating client computing devices 2202, 2204, 2206, and / or 2208 can utilize the services provided by these components by using one or more client applications to exchange information with server 2212.

[0159] 22, the software components 2218, 2220, and 2222 of the system 2200 are implemented on a server 2212. In other embodiments, one or more of the components of the system 2200 and / or the services provided by these components may be implemented by one or more client computing devices 2202, 2204, 2206, and / or 2208. A user operating a client computing device can utilize the services provided by these components using one or more client applications. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that various system configurations different from the distributed system 2200 are possible. Thus, the embodiment illustrated in FIG. 22 is an example of a distributed system for implementing the system of the embodiment, and is not intended to be limiting.

[0160] The client computing devices 2202, 2204, 2206, and / or 2208 may include various types of computing systems. For example, the client devices may be implemented using software such as Microsoft Windows Mobile® and / or iOS, Windows Phone, Android, and / or other popular operating systems. The client computing devices may include handheld mobile devices (e.g., iPhone®, mobile phones, iPad®, tablets, personal digital assistants (PDAs) or wearable devices (e.g., Google Glass® head mounted displays) capable of running a variety of mobile operating systems such as Luckberry® 10 and Palm OS. The devices may support a variety of applications, such as various Internet-related applications, e-mail applications, short message service (SMS) applications, and may use a variety of other communication protocols. Additionally, the client computing devices may illustratively run Microsoft Windows® operating systems. Operating System, Apple Macintosh® Operating System and / or The client computing devices may include general purpose personal computers, including personal computers and / or laptop computers running various versions of the GNU / Linux operating system. The client computing devices may be, for example, workstation computers running various commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems, e.g., Google Chrome OS. The client computing devices may include other electronic devices, such as thin client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect gesture input devices), and / or personal messaging devices capable of communicating over the network 2210.

[0161] Although the distributed system 2200 of Figure 22 is shown with four client computing devices, any number of client computing devices may be supported. Other devices, such as devices having sensors, may exchange information with the server 2212.

[0162] Network 2210 of distributed system 2200 may support data communications using any of a variety of commercially available protocols, including, but not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Exchange), Apple Talk, etc., and may be any type of network familiar to those skilled in the art. By way of example only, network 2210 may be a local area network (LAN), an Ethernet-based network, a token ring, a wide area network, the Internet, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., the IEEE 1002.11 protocol suite, Bluetooth, and / or any other wireless protocol). The networks may include networks operating under the protocol (such as a cellular or wireless network) and / or combinations of these and other networks.

[0163] The server 2212 may be comprised of one or more general purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers), server farms, server clusters, or any other suitable configuration and / or combination. The server 2212 may include one or more virtual machines running a virtual operating system or other computing architectures including virtualization. One or more flexible pools of logical storage may be virtualized to maintain virtual storage for the server. The virtual network may be controlled by the server 2212 using software-defined networking. In various embodiments, the server 2212 may be configured to execute one or more services or software applications described in the preceding disclosure. For example, the server 2212 may correspond to a server for executing the processes described above according to an embodiment of the present disclosure.

[0164] Server 2212 may run an operating system, including any of those mentioned above, as well as any commercially available server operating system. Server 109 may also run any of a variety of additional server applications and / or mid-tier applications, including an HTTP (Hypertext Transfer Protocol) server, an FTP (File Transfer Protocol) server, a CGI (Common Gateway Interface) server, a Java® server, a database server, and the like. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®.

[0165] In some implementations, the server 2212 may include one or more applications that analyze and consolidate data feeds and / or event updates received from users of the client computing devices 2202, 2204, 2206, and 2208. By way of example, the data feeds and / or event updates may be collected from Twitter. (R) feeds, Facebook updates, or real-time updates received from one or more third sources and continuous data streams. Real-time updates may include real-time events associated with sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring devices, etc. The server 2212 may also include one or more applications for displaying data feeds and / or real-time events via one or more displays of the client computing devices 2202, 2204, 2206, and 2208.

[0166] Distributed system 2200 may also include one or more databases 2214 and 2216. These databases may provide a mechanism for storing information used by various embodiments, such as user ID information and other information. Databases 2214 and 2216 may reside in a variety of locations. By way of example, one or more databases 2214 and 2216 may reside on a non-transitory storage medium near (and / or within) server 2212. Alternatively, databases 2214 and 2216 may be remote from remote server 2212 and in communication with server 2212 via a network-based or dedicated connection. In one set of embodiments, databases 2214 and 2216 may reside on a storage area network (SAN). Similarly, any necessary files to perform functions contributed to server 2212 may be stored on server 2212 and / or remote from server 2212, as appropriate. In one set of embodiments, databases 2214 and 2216 may include relational databases, such as those provided by Oracle. These relational databases retrieve data according to SQL format instructions. The system is configured to obtain, store and update the information.

[0167] In some embodiments, the identity management services described above may be provided as a service via a cloud environment. FIG. 23 is a simplified block diagram illustrating one or more components of a system environment 2300 that can provide services as cloud services according to one embodiment of the present disclosure. In the embodiment shown in FIG. 23, the system environment 2300 includes one or more client computing devices 2304, 2306, and 2308 that users can use to interact with a cloud infrastructure system 2302 that provides cloud services including services for managing credentials stored in a company's target system. The cloud infrastructure system 2302 can include one or more computers and / or servers that can include those described above with respect to the server 2212.

[0168] It should be understood that the cloud infrastructure system 2302 depicted in Figure 8 may include components other than those depicted. Additionally, the embodiment depicted in Figure 8 is only one example of a cloud infrastructure system that may incorporate embodiments of the present invention. In some other embodiments, the cloud infrastructure system 2302 may have more or fewer components than depicted, may combine two or more components, or may have components in a different configuration or arrangement.

[0169] Client computing devices 2304, 2306, and 2308 are similar to devices 2202, 2204, 2206, and 2208 described above. Client computing devices 2304, 2306, and 2308 can be configured to run client applications, such as web browsers, dedicated client applications (e.g., Oracle Forms), or other applications. Users can use these client applications to utilize services provided by cloud infrastructure system 2302 by exchanging information with cloud infrastructure system 2302. Although exemplary system environment 2300 is shown with three client computing devices, any number of client computing devices can be supported. Other devices, such as devices having sensors, can exchange information with cloud infrastructure system 2302.

[0170] Network 2310 can facilitate communication and exchange of data between clients 2304, 2306, and 2308 and cloud infrastructure system 2302. Each network can support data communications using any of a variety of commercially available protocols, including those described with respect to network 710 above, and may be any type of network familiar to those of skill in the art.

[0171] In certain embodiments, the services provided by the cloud infrastructure system 2302 may include many services that may be provided to users of the cloud infrastructure system on demand. In addition to services related to identity management, a variety of other services may also be provided, including, but not limited to, online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, and managed technical support services. The services provided by the cloud infrastructure system may be dynamically scaled to meet the needs of the users.

[0172] In particular embodiments, a particular instantiation of a service provided by cloud infrastructure system 2302 is referred to herein as a "service instance." In general, any service that can be provided from a cloud service provider's system to a user over a communications network, such as the Internet, is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's system are distinct from the customer's on-premise servers and systems. For example, the cloud service provider's system can provide an application, and a user can order and use the application as needed over a communications network, such as the Internet.

[0173] In some examples, services in a computer network cloud infrastructure can include protected computer network storage access, hosted databases, hosted web servers, software applications, or other services provided to users by a cloud vendor, or other services known in the art. For example, a service can include password-protected access to remote storage on the cloud over the Internet. As another example, a service can include a relational database hosted on a web service and a scripting language middleware engine for private use by developers on the network. As another example, a service can include access to an email software application hosted on a cloud vendor's website.

[0174] In certain embodiments, the cloud infrastructure system 2302 may include a suite of application, middleware, and database services that can be provided to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such a cloud infrastructure system is the Oracle Public Cloud offered by the assignee of the present application.

[0175] The cloud infrastructure system 2302 may also provide "big data" related computation and analysis services. The term "big data" generally refers to extremely large data sets. Analysts and researchers may utilize the stored big data to visualize large amounts of data, detect trends from the data, and / or interact with the data. Big data and related applications may be hosted and / or utilized by the infrastructure system at various levels and scales. Dozens, hundreds, or thousands of processors linked in parallel may compute such data to present the data or simulate external forces acting on or representations of the data. These data sets include structured data, such as data organized in databases or data organized according to other structured models, and / or unstructured data (e.g., emails, images, data blobs (binary large objects), web pages, complex event processing). According to one embodiment, the cloud infrastructure system may better perform tasks on large data sets based on the demands of a business, government agency, research institute, individual, group of individuals or organizations, or other entity by relatively quickly focusing more (or fewer) computing resources on the purpose.

[0176] In various embodiments, the cloud infrastructure system 2302 can be configured to automatically provision, manage, and track cloud infrastructure system 2302 services subscribed to by customers. The cloud infrastructure system 2302 can provide cloud services through a variety of deployment models. For example, the services can be provided in a public cloud model with the cloud infrastructure system 2302 owned by an organization that sells the cloud services (e.g., owned by Oracle Corporation) and available to the general public or to businesses in different industries. As another example, the services can be provided in a private cloud model with the cloud infrastructure system 2302 dedicated to a single organization and available to one or more entities within the organization. Cloud services may also be provided in a collective cloud model, whereby the cloud infrastructure system 2302 and the services provided by the cloud infrastructure system 2302 are shared by multiple organizations within an associated collective. Cloud services may also be provided in a hybrid cloud model consisting of a combination of two or more different models.

[0177] In some embodiments, the services provided by the cloud infrastructure system 2302 fall into the categories of Software as a Service (SaaS), Platform as a Service (PaaS), and the like. (Infrastructure as a Service) category, IaaS (Infrastructure as a Service) category, or hive The cloud infrastructure system 2302 may provide one or more services pursuant to a subscription order, or other categories of services, including a subscription service. A customer may order one or more services provided by the cloud infrastructure system 2302 through a subscription order. In response, the cloud infrastructure system 2302 processes the delivery of the services included in the customer's subscription order.

[0178] In some embodiments, the services provided by the cloud infrastructure system 2302 include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that conform to the SaaS category. For example, the SaaS platform may function to build and provide a suite of on-demand applications on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure to provide the SaaS services. By utilizing the services provided by the SaaS platform, customers can utilize applications that run on the cloud infrastructure system. Customers can obtain application services without having to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, but are not limited to, services that provide solutions to sales performance management, enterprise integration, and business flexibility for large organizations.

[0179] In some embodiments, platform services may be provided by cloud infrastructure system 2302 via a PaaS platform. The PaaS platform may be configured to provide cloud services that conform to the PaaS category. Examples of platform services include, but are not limited to, services that give organizations (e.g., Oracle) the ability to consolidate existing applications onto a shared common architecture and build new applications that leverage the shared services provided by the platform. The PaaS platform may manage and control the underlying software and infrastructure to provide the PaaS services. Customers may utilize the Paas services provided by cloud infrastructure system 2302 without having to purchase separate licenses and support. Examples of platform services include oracle java cloud services, ... Oracle Database Cloud Service (DBCS) and others. Not limited to.

[0180] By utilizing the services provided by the PaaS platform, customers can utilize programming languages ​​and tools supported by the cloud infrastructure system and control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system include database cloud services, middleware cloud services (e.g., Oracle Fusion middleware services), and Java cloud services. In one embodiment, the database cloud service can support a shared services deployment model that can give organizations the ability to pool database resources and can provide customers with database as a service (DBaaS) as a cloud database. The middleware cloud service can provide customers with a platform for developing and deploying various business applications on a cloud infrastructure system, and the Java cloud service can provide customers with a platform for deploying Java applications on a cloud infrastructure system.

[0181] A variety of different infrastructure services may be provided by the IaaS platform to the cloud infrastructure system that facilitate management and control of underlying computing resources, such as storage, network and other fundamental computing resources, for customers using the services provided by the SaaS and PaaS platforms.

[0182] In particular embodiments, cloud infrastructure system 1402 also includes infrastructure resources 1430 for providing resources used to provide various services to customers utilizing the cloud infrastructure system. In one embodiment, infrastructure resources 1430 may include a combination of hardware, such as server resources, storage resources, and network resources, pre-integrated and optimized to run the services offered by the PaaS and SaaS platforms and other resources.

[0183] In some embodiments, resources in cloud infrastructure system 2302 can be shared among multiple users and dynamically reallocated according to their needs. Resources can also be allocated to users in different time zones. For example, cloud infrastructure system 2302 can make cloud infrastructure system resources available to a first group of users in a first time zone for a specified period of time, and then reallocate similar resources to another group of users in a different time zone to maximize utilization of the resources.

[0184] In certain embodiments, multiple internal shared services 2332 are provided that can be shared by different components or modules of cloud infrastructure system 2302 to provide services to cloud infrastructure system 2302. These internal shared services include, but are not limited to, safety and identification services, integration services, enterprise repository services, enterprise management services, virus scanning and whitelist services, high availability backup and recovery services, services enabling cloud support, mail services, notification services, and file transfer services.

[0185] In certain embodiments, the cloud infrastructure system 2302 may include cloud services (e.g., SaaS services, PaaS services, etc.) in the cloud infrastructure system. In one embodiment, cloud management functionality may include functionality for provisioning, managing, and tracking customer subscriptions received by, for example, the cloud infrastructure system 2302.

[0186] In one embodiment, as shown in FIG. 23, the cloud management function includes one or more modules, such as an order management module 2320, an order The order management and control modules 2324, 2326, and 2328 are provided by an order orchestration module 2322, an order provisioning module 2324, an order management and monitoring module 2326, and an identity management module 2328. These modules may be implemented on one or more computers. The system may include or be formed using computers and / or servers, which may be general purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination thereof.

[0187] In example operation 2334, a customer may interact with cloud infrastructure system 2302 by using a client device, e.g., client device 2304, 2306, or 2308, to request one or more services offered by cloud infrastructure system 2302 and order a subscription for one or more services offered by cloud infrastructure system 2302. In particular embodiments, the customer may access and subscribe to a cloud user interface (UI), e.g., cloud UI 2312, cloud UI 2323, and / or cloud UI 2316, via these UIs. Order information received by cloud infrastructure system 2302 in response to the customer's order may include information identifying the customer and one or more services offered by cloud infrastructure system 2302 that the customer wishes to purchase.

[0188] At 2336, the order information received from the customer may be stored in the order database 2318. If the order is a new order, a new record may be created for the order. In one embodiment, the order database 2318 may be one of several databases operated by the cloud infrastructure system 2318 or in conjunction with other system elements.

[0189] At 2338, the order information is forwarded to the order management module 2320. The order management module 2320 may be configured to perform billing and accounting functions related to the order, such as reviewing the order and filling the order after review.

[0190] At 2340, information regarding the order may be communicated to an order coordination module 2322 configured to prepare the delivery of services and resources ordered by the customer. In some examples, the order coordination module 2322 can prepare the delivery of services and resources using the services of the order fulfillment module 1424. In certain embodiments, the order coordination module 2322 can manage business processes associated with each order and can apply business logic to determine whether to fulfill the order.

[0191] As shown in the embodiment illustrated in FIG. 23, upon receiving a new subscription order at 2342, the order adjustment module 2322 may request and configure the resources necessary to fulfill the subscription order. to an order fulfillment module 2324, which can allocate resources for the services ordered by the customer. The order fulfillment module 2324 forms a level of abstraction between the cloud services provided by the cloud infrastructure system 2300 and the physical implementation layer used to provide the resources to provide the requested services. In this manner, the order adjustment module 2322 can be isolated from implementation details such as, for example, whether services and resources are provided on the spot or in advance, allocated / given on request, etc.

[0192] After provisioning the services and resources, a notification may be sent to the subscribing customer indicating that the requested services are available, at 2344. In some examples, information (e.g., links) may be sent to the customer to enable the customer to use the requested services.

[0193] At 2346, the order management and monitoring module 2326 can manage and track customer subscription orders. In some examples, the order management and monitoring module 2326 can be configured to collect service usage statistics regarding the customer's usage of purchased services. For example, the statistical data may include storage usage, data transfer, number of users, system start times, and system stop times.

[0194] In certain embodiments, the cloud infrastructure system 2300 can include an identity management module 2328. The identity management module 2328 can be configured to provide identity services, e.g., access management and authorization services, to the cloud infrastructure system 2300. In some embodiments, the identity management module 2328 can control information about customers who wish to utilize services provided by the cloud infrastructure system 2302. Such information can include information authorizing the identity of the customer and information describing the execution rights of the customer granted to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). The identity management module 2328 can include descriptive information about each customer, methods for accessing and modifying the descriptive information, and management of the customers who have accessed and modified the descriptive information.

[0195] 24 illustrates an exemplary computing system 2400 that may be used to implement embodiments of the present disclosure. In some embodiments, the computing system 2400 may be used to implement any of the various servers and computing systems described above. As shown in FIG. 24, the computing system 2400 includes various subsystems, including a processing subsystem 2404 that communicates with a number of peripheral subsystems via a bus subsystem 2402. The peripheral subsystems may include a processing acceleration unit 2406, an I / O subsystem 2408, a storage subsystem 2418, and a communication subsystem 2424. The storage subsystem 2418 may include a tangible computer-readable storage medium 2422 and a system memory 2410.

[0196] Bus subsystem 2402 provides a mechanism by which the various components and subsystems of computer system 2400 communicate with each other as necessary. Although the illustration shows bus subsystem 2402 diagrammatically as a single bus, in alternative embodiments, the bus subsystem may utilize multiple buses. Bus subsystem 2402 may have any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Microprocessor (MCU) bus, or a Serial ATA (SAS) bus. Examples of buses include a Microchannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, which may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0197] The processing subsystem 2404 controls the operation of the computing system 2400 and may include one or more processing units 2432, 2434, etc. The processing units may include one or more processors, e.g., single-core or multi-core processors, processors with one or more cores, or a combination thereof. In some embodiments, the processing subsystem 2404 may include one or more special-purpose co-processors, e.g., graphics processors, digital signal processors (DSPs), etc. In some embodiments, some or all of the processing units of the processing subsystem 2404 may be implemented using custom circuitry, such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA).

[0198] In some embodiments, the processing units of the processing subsystem 2404 can execute instructions stored in the system memory 2410 or the computer readable storage medium 2422. In various embodiments, the processing units can execute various program or code instructions and can maintain simultaneously executing programs or processes. Some or all of the program code being executed at any one time can reside in the system memory 2410 and / or the computer readable storage medium 2410, which may include one or more storage devices. With appropriate programming, the processing subsystem 2404 can provide various functions for dynamically modifying documents (e.g., web pages) in response to usage patterns, as described above.

[0199] In particular embodiments, all processing performed by the computing system 2400 may be accelerated by providing a processing acceleration unit 2406 to perform certain processes or offload parts of the processing performed by the processing subsystem 2404.

[0200] The I / O subsystem 2408 may include devices and mechanisms for inputting information into the computing system 2400 and / or devices and mechanisms for outputting information from or through the computing system 2400. In general, the term "input device" includes all possible devices and mechanisms for inputting information into the computing system 2400. User interface input devices may include, for example, a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen integrated into a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may also include, for example, a motion sensing and / or gesture recognizer such as a Microsoft Kinect® motion sensor that allows a user to control and interact with the input device, a Microsoft Xbox® 360 game controller, and devices for providing an interface for receiving input using gestures and voice commands. User interface input devices may also include an eye gesture recognizer such as a Google Glass® blink detector. The Google Glass blink detector detects a user's eye activity (e.g., "blinking" when taking a photo and / or selecting a menu) and converts the eye activity into input that is entered into an input device (e.g., Google Glass). Additionally, the user interface input device may include a voice recognition detector that enables a user to interact with a voice recognition system (e.g., the Siri® Navigator) via voice commands.

[0201] Other examples of user interface input devices include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads, graphics tablets, audio / visual devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser range finders, and eye-tracking devices. Additionally, user interface input devices may include medical imaging input devices such as, for example, computed tomography devices, magnetic resonance imaging devices, ultrasound emission tomography devices, and medical ultrasound devices. User interface input devices may also include audio input devices such as, for example, MIDI keyboards and electronic musical instruments.

[0202] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. The display subsystem may be, for example, a flat panel device using a cathode ray tube (CRT), liquid crystal display (LCD) or plasma display, a projection device, or a touch screen. In general, when the term "output device" is used, it is intended to include all possible types of devices and mechanisms for outputting information from computer system 2400 to a user or to another computer. For example, user interface output devices include, but are not limited to, various display devices that visually convey text, images, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0203] The storage subsystem 2418 provides a repository or data store for storing information used by the computing system 2400. The storage subsystem 2418 provides a tangible computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by the processing subsystem 2404, provide the functionality described above may be stored in the storage subsystem 2418. Such software may be executed by one or more processing units of the processing subsystem 2404. The storage subsystem 2418 may also provide a repository for storing data used in accordance with various aspects.

[0204] The storage subsystem 2418 may include one or more non-transitory memory devices, including volatile and non-volatile memory devices. As shown in FIG. 24, the storage subsystem 2418 includes a system memory 2410 and a computer-readable storage medium 2422. The system memory 2410 may include several memories, including a volatile main random access memory (RAM) for storing instructions and data during program execution, and a non-volatile read-only memory (ROM) or flash memory for storing fixed instructions. In some implementations, a basic input / output system (BIOS), containing the basic routines that help transfer information between elements of the computing system 2400, such as during start-up, may typically be stored in a ROM. The RAM typically contains data and / or program modules currently being operated on and executed by the processing subsystem 2404. In some implementations, the system memory 2410 may include several different types of memory, such as a static random access memory (SRAM) or a dynamic random access memory (DRAM).

[0205] By way of example and not limitation, as shown in Figure 24, system memory 2410 can store application programs 2412, program data 2414, and an operating system 2416, which may include client applications, web browsers, mid-tier applications, relational database management systems (RDBMS), and the like. For example, the operating system 2416 may be a Microsoft Windows, Apple Macintosh, and / or Linux operating system. various versions of the Microsoft Windows operating system, various commercially available UNIX or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome OS, etc.) , and / or iOS, Windows Phone, Android OS, BlackBerry 10 OS and Palm OS operating systems The present invention may include a mobile operating system such as a cellular operating system.

[0206] The computer readable storage medium 2422 can store programming and data structures that provide functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by the processing subsystem 2404, provide the functionality described above may be stored in the storage subsystem 2418. As an example, the computer readable storage medium 2422 can include non-volatile memory, such as a hard disk drive, a magnetic disk drive, an optical disk drive such as a CD-ROM, a DVD, a Blu-ray disk, or other optical media. The computer readable storage medium 2422 can include, but is not limited to, a Zip drive, a flash memory card, a Universal Serial Bus (USB) flash drive, a Secure Digital (SD) card, a DVD disk, a digital video tape, and the like. Also, the computer readable storage media 2422 may include solid state drives (SSDs) based on flash memory, enterprise flash drives, non-volatile memory such as solid state ROM, SSDs based on volatile memory such as solid state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs using a combination of DRAM and flash memory-based SSDs. Disk drives and their associated computer readable media may provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for the computer system 2400.

[0207] In particular embodiments, storage subsystem 2400 may include a computer readable storage medium reader 2420 that may be further coupled to a computer readable storage medium 2422. Computer readable storage medium 2422 may comprehensively represent remote, local, fixed, and / or removable storage devices in addition to storage media for storing computer readable information together with or in combination with system memory 2410 as appropriate.

[0208] In certain embodiments, computing system 2400 can support the execution of one or more virtual machines. Computing system 2400 can execute a program, such as a hypervisor, to facilitate configuration and management of the virtual machines. Each virtual machine can be assigned memory, computational (e.g., processors, cores), I / O, and network resources. Each virtual machine typically runs its own operating system. This operating system may be similar to or different from the operating systems executed by other virtual machines executed by computing system 2400. Thus, computing system 2400 can run multiple operating systems simultaneously. Each virtual machine typically operates independently of other virtual machines.

[0209] The communications subsystem 2424 provides an interface to other computing systems and networks. The communications subsystem 2424 serves as an interface for receiving data from other systems and for transmitting data from the computer system 2400 to other systems. The communications subsystem 2424 allows the computing The account management system 112 shown in FIG. 1 may use the communications subsystem 2424 to receive user login information, including input related to training words, from a client device. Additionally, the communications subsystem 2424 may be used to send notifications regarding successful logins or password re-entry requests from the account management system to the user.

[0210] The communications subsystem 2424 may support both wired and / or wireless communications protocols. For example, in some embodiments, the communications subsystem 2424 may include radio frequency (RF) transceiver elements for accessing wireless voice and / or data networks (e.g., using cellular technologies, advanced data network technologies such as 3G, 4G, or EDGE (enhanced data rates for global evolution)), WiFi (IEEE 802.11 family of standards or other mobile communications technologies, or any combination thereof), global positioning system (GPS) receiver elements, and / or other elements. In some embodiments, the communications subsystem 2424 may provide a wired network connection (e.g., Ethernet) in addition to or instead of a wireless interface.

[0211] The communications subsystem 2424 can send and receive data in various formats. For example, in some embodiments, the communications subsystem 2424 can receive incoming communications in the form of structured and / or unstructured data feeds 2426, event streams 2428, event updates 2430, etc. For example, the communications subsystem 2424 can receive Twitter feeds, Facebook updates, Rich Site Summary (RSS) feeds, and other communications from users of social networks and / or other communications services. The data feeds 2426 may be configured to receive (or transmit) data feeds 2426, including web feeds such as news, in real time, and / or to receive (or transmit) real-time updates from one or more third party sources.

[0212] In particular embodiments, the communications subsystem 2424 may be configured to receive data in the form of a continuous data stream, which may include an event stream 2428 of real-time events and / or continuous or essentially bounded event updates 2430 that have no clear ending. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0213] The communications subsystem 2424 may also be configured to output structured and / or unstructured data feeds 2426, event streams 2428, and event updates 2430, etc., to one or more databases that may communicate with one or more streaming data source computers coupled to the computer system 2400.

[0214] The computer system 1500 may be one of a variety of types, including a handheld mobile device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head mounted display), a personal computer, a workstation, a mainframe, a kiosk, a server rack or other data processing system.

[0215] Due to the ever-evolving nature of computers and networks, the description of computer system 2400 shown in FIG. 24 is intended only as a specific example. Many other configurations having more or fewer components than the system shown in FIG. 4 are possible. For example, customized hardware may also be used and / or particular elements may be implemented in hardware, firmware, software (including applets), or a combination. Additionally, connections to other computing devices, such as network input / output devices, may be utilized. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other means and / or methods for implementing various embodiments.

[0216] Although the present embodiment has been described in detail, modifications within the spirit and scope of the embodiment described herein will be easy and obvious to those skilled in the art. The aspects of the various embodiments, parts of the various aspects, and various features recited above and / or in the appended claims can be combined in whole or in part, or exchanged. As can be understood by those skilled in the art, in the above description of the various embodiments, the embodiments that refer to other embodiments can be appropriately combined with other embodiments. Furthermore, those skilled in the art will understand that the above description is merely illustrative and is not intended to limit the present invention.

Claims

1. 1. A system comprising: one or more processors; a memory coupled to the one or more processors, the memory storing a plurality of instructions executable by the one or more processors, the plurality of instructions, when executed by the one or more processors, causing the one or more processors to perform an operation, the operation comprising: monitoring live information flow including data flow from a source to a destination; providing a user interface including a plurality of buckets, each bucket associated with a different threat level or enforcement action, each bucket being triggered in real time and displaying a total number of current enforcement policies including the associated threat level or enforcement action, the process further comprising: determining an occurrence of a security event in the live information flows based on a trigger of an execution policy, the execution policy including a specification of the source, the destination, and an enforcement action, and if the data in one or more live information flows matches at least the source and the destination of the execution policy, the execution policy is triggered and the enforcement action is applied, and the processing further includes: The system includes: (i) identifying a bucket from the plurality of buckets associated with a threat level associated with the execution policy or the enforcement action applied by the execution policy to reflect the occurrence of the security event; and (ii) updating the user interface by increasing the total number of current execution policies displayed in the identified bucket, triggered in real time by the associated threat level or enforcement action.

2. 2. The system of claim 1, wherein the source is displayed on one side of a window of the user interface, the destination is displayed on another side of the window opposite the side having the source, and the plurality of buckets are displayed in a separate window above the window containing the source and the destination.

3. the live information flow is part of a plurality of live information flows; the plurality of live information flows including (i) data flows from a plurality of sources to a plurality of destinations, and (ii) a plurality of execution policies triggered by the data; 3. The system of claim 1, wherein the user interface further includes: (i) a plurality of lines for connecting each source of the plurality of sources to a corresponding destination of the plurality of destinations; and (ii) an indicator on each line indicating an execution policy triggered by data flowing between each source and each destination.

4. The process comprises: receiving user input corresponding to a selection of a particular bucket from the plurality of buckets; and displaying the plurality of live information flows including one or more sources and one or more destinations corresponding to the selected bucket.

5. The process comprises: receiving user input corresponding to a selection of a particular source or destination from the plurality of sources or the plurality of destinations; and displaying the live information flow originating from the selected particular source that includes the one or more execution policies triggered by the data in the live information flow or the live information flow terminating at the selected particular destination that includes the one or more execution policies triggered by the data in the live information flow.

6. The system of claim 3 , wherein the processing further comprises providing an indicator of a set of top sources of the plurality of sources based on an amount of data flowing from the plurality of sources to the plurality of destinations.

7. 7. The system of claim 1, wherein the processing further includes updating a trend indicator for the identified bucket based on the occurrence of the security event, the trend indicator including displaying an up arrow, a down arrow, or a neutral symbol for the identified bucket.

8. 1. A method comprising: a data processing system monitoring live information flow including data flow from a source to a destination; the data processing system providing a user interface including a plurality of buckets, each bucket associated with a different threat level or enforcement action, each bucket being triggered in real time and displaying a total number of current enforcement policies including the associated threat level or enforcement action; the data processing system determining an occurrence of a security event in the live information flows based on a trigger of an execution policy, the execution policy including a specification of the source, the destination, and an enforcement action, and when the data in one or more live information flows matches at least the source and the destination of the execution policy, the execution policy is triggered and the enforcement action is applied, the method further comprising: The method includes the data processing system (i) identifying from the plurality of buckets a bucket associated with a threat level associated with the execution policy or the enforcement action applied by the execution policy to reflect the occurrence of the security event, and (ii) updating the user interface by being triggered in real time by the associated threat level or enforcement action and increasing the total number of current execution policies displayed in the identified bucket.

9. 9. The method of claim 8, wherein the source is displayed on one side of a window of the user interface, the destination is displayed on another side of the window opposite the side having the source, and the plurality of buckets are displayed in a separate window above the window containing the source and the destination.

10. the live information flow is part of a plurality of live information flows; the plurality of live information flows including (i) data flows from a plurality of sources to a plurality of destinations, and (ii) a plurality of execution policies triggered by the data; 10. The method of claim 8 or 9, wherein the user interface further includes: (i) a plurality of lines for connecting each source of the plurality of sources to a corresponding destination of the plurality of destinations, and (ii) an indicator on each line indicating an execution policy triggered by data flowing between each source and each destination.

11. receiving, by the data processing system, a user input corresponding to a selection of a particular bucket from the plurality of buckets; 11. The method of claim 10, further comprising: the data processing system displaying the plurality of live information flows including one or more sources and one or more destinations corresponding to the selected bucket.

12. receiving, by the data processing system, user input corresponding to a selection of a particular source or destination from the plurality of sources or the plurality of destinations; 11. The method of claim 10, further comprising: the data processing system displaying the live information flow originating from the selected particular source that includes the one or more execution policies triggered by the data in the live information flow, or the live information flow terminating at the selected particular destination that includes the one or more execution policies triggered by the data in the live information flow.

13. 11. The method of claim 10, further comprising the data processing system providing an indicator of a set of top sources of the plurality of sources based on the amount of data flowing from the plurality of sources to the plurality of destinations.

14. 14. The method of claim 8, further comprising the data processing system updating a trend indicator for the identified bucket based on the occurrence of the security event, the trend indicator comprising displaying an up arrow, a down arrow, or a neutral symbol for the identified bucket.

15. A program for causing a computer to execute the method according to any one of claims 8 to 14.

Images