Implementing dynamic policies and access visibility to detect threats.

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 the priority and benefit of U.S. Provisional Application No. 62 / 447,759, filed on January 18, 2017, entitled "Visualization of Access for Threat Detection" and U.S. Provisional Application No. 62 / 396,016, filed on September 16, 2016, entitled "Visualization of Access for Threat Detection", and the entire contents of these applications are incorporated herein by reference for all purposes.

Background Art

[0002] Background The present disclosure generally relates 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 an integrated view that includes active threats, user activities, and dynamic policies triggered by active threats and user activities.

[0003] Computer networks have become an important tool for modern business. Currently, a large amount of information is stored in such networks and is utilized by users around the world. Since most information is confidential or secret to some extent, the protection of information is necessary. Not surprisingly, various network security monitoring devices have been developed to detect attempts by unauthorized persons and / or devices to access 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 companies deploy hundreds or thousands of these products on their networks. Consequently, network security personnel are overwhelmed with responding to alarms representing possible security threats. Most companies do not have the resources or qualified personnel to individually address every alarm they receive.

[0005] Therefore, there is a need for technologies that analyze security events and provide threat visualizations to present real-time data analysis in a way that is easily understandable to end users. [Overview of the Initiative] [Means for solving the problem]

[0006] overview When user activity is extremely high (billions of events per day), static security rules cannot address threats arising from vulnerable users, applications, and hosts, thus requiring a threat intelligence platform. Several embodiments can provide real-time threat detection and analysis. Certain embodiments can provide visibility into user and application usage and performance. Some embodiments can leverage existing access controls to provide real-time execution. Certain embodiments can enforce compliance, block user access to unauthorized applications, and implement policy-based adaptive authorization. It can authenticate users and perform content inspections to prevent privacy breaches 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 action.

[0007] In particular, systems, methods, and computer-readable memory for controlling access to accessible resources in a distributed environment are disclosed. Specific techniques 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 an integrated view of active threats and user activity are disclosed. In various embodiments, the systems and methods relate to a network architecture that includes the ability to create dynamic policies (including inspection policies and execution policies), the conception of a policy bus for deploying and transmitting dynamic policies to multiple execution entities, and the ability of 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, performing real-time anomaly detection based on real-time threat models, collecting dynamic events and data based on inspection policy distribution, and classifying dynamic access policies based on threat levels.

[0008] In various embodiments, a system is provided that includes one or more processors and a non-temporary machine-readable storage medium, a distributed environment including a user device, multiple agents, a collection bus, a policy bus, and a target system having resources, and program instructions for collecting data about security events. 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 the collection bus from at least one of the multiple agents. The system further includes program instructions for creating dynamic execution policies based on the data. A dynamic execution policy includes a source, a destination, an action to be taken, and a specification for the period during which the dynamic execution policy is active. The system further includes program instructions for exposing the dynamic execution policy onto the policy bus so that multiple agents can access the dynamic execution policy. During the period in which the dynamic execution policy is active, the dynamic execution policy overrides a static execution policy, which includes the specification of the source and destination. The program instructions are stored in a non-temporary machine-readable storage medium and executed by one or more processors.

[0009] In some embodiments, the system further includes program instructions for executing action measures in response to security events based on dynamic execution policies. At least one of a plurality of agents executes the action measures.

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

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

[0012] In some embodiments, the distributed environment includes an analysis server and machine learning components. Furthermore, inspection policies and dynamic execution policies are created by the analysis server and machine learning components.

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

[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 predefined attributes using one or more data clusters, and, based on the analysis, creating a source, destination, action, and a period during which the dynamic execution policy is active.

[0015] In some embodiments, one or more data clusters are generated using supervised or unsupervised machine learning or clustering techniques, the analysis involves calculating the distance from the centroid of one or more data clusters to a set of predefined attributes, and the action to be taken is determined based on the distance.

[0016] In various embodiments, a non-temporary machine-readable storage medium is provided for storing instructions. When these instructions are executed by one or more processors, they cause one or more processors to perform a method that includes the step of collecting data about security events. 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 of a plurality of agents. The method further includes the step of creating a dynamic execution policy based on the data. The dynamic execution policy includes specifying a source, a destination, an action to be taken, and the period for which the dynamic execution policy is active. The method further includes the step of exposing the dynamic execution policy on a policy bus so that multiple agents can access it. The method further includes the step of performing an action on a security event based on the dynamic execution policy, and at least one of the plurality of agents performs the action. During the period in which the dynamic execution policy is active, the dynamic execution policy overrides a static execution policy that includes specifying a source and a destination.

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

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

[0019] In some embodiments, inspection policies and dynamic execution policies are created by the analysis server and machine learning components.

[0020] In some embodiments, the method includes the steps of creating an inspection policy based on historical data or designation of a target system or resource, and publishing the inspection policy on a policy bus so that multiple agents can access the inspection policy. This further includes the following.

[0021] In some embodiments, the step of creating a dynamic execution policy includes classifying real-time collected data and historical data into one or more data clusters, analyzing a set of predefined attributes using one or more data clusters, and, based on the analysis, creating a source, destination, action, and a period during which the dynamic execution policy is active.

[0022] In some embodiments, one or more data clusters are generated using supervised or unsupervised machine learning or clustering techniques, the analysis involves calculating the distance from the centroid of one or more data clusters to a set of predefined attributes, and the action to be taken is determined based on the distance.

[0023] In various embodiments, a method is provided that includes collecting data regarding security events using a computing system. 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 of a plurality of agents. The method further includes creating a dynamic execution policy based on the data. The method further includes creating a dynamic execution policy based on the data using a computer system. The dynamic execution policy includes a specification of the source, destination, execution action, and a period during which the dynamic execution policy is active. The method further includes publishing the dynamic execution policy on a policy bus using a computing system so that a plurality of agents can access the dynamic execution policy. The method further includes executing an execution action on a security event based on the dynamic execution policy using a computing system, and at least one of the plurality of agents executes the execution action. During the period when the dynamic execution policy is active, the dynamic execution policy overwrites a static execution policy that includes specifications 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 after the predetermined period ends and is deleted from the policy bus, 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, the collection of data is triggered by an inspection policy published on a policy bus, and the inspection policy includes rules for collecting in real time data that is a set of defined attributes regarding a security event when a set of criteria for the security event matches a defined pattern.

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

[0027] In some embodiments, creating a dynamic execution policy includes classifying data collected in real time and historical data into one or more data clusters, analyzing a set of defined attributes using the one or more data clusters, and creating, based on the analysis, a source, a destination, an execution action, and a period during which the dynamic execution policy is active.

[0028] In various embodiments, the system and method relate to providing an integrated 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 comprising one or more processors and non-temporary machine-readable storage media and program instructions for monitoring one or more live information flows. The live information flows comprise data flows from multiple sources to multiple destinations. The system further comprises program instructions for providing a user interface comprising multiple buckets. Each bucket relates to a different action, and each bucket displays the total number of current execution policies, which are triggered in real time and include associated actions. The system further comprises program instructions for determining the occurrence of security events in one or more live information flows based on the triggers of the execution policies. An execution policy comprises specifying a source, destination, and action, and an execution policy is triggered and an action is applied if data in one or more live information flows matches at least the source and destination of the execution policy. The system further includes program instructions for updating the user interface to reflect the occurrence of security events by (i) identifying buckets from multiple buckets related to the action taken by the action taken by the action policy, and (ii) increasing the total number of current action policies displayed in the identified bucket, which are triggered in real time by the action. The program instructions are stored in a non-temporary 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 a identified bucket based on the occurrence of a security event, and updating the trend indicator includes displaying an upward arrow for the identified bucket.

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

[0031] In some embodiments, the system further includes program instructions for receiving user input corresponding to the selection of a bucket from a plurality of buckets, and program instructions for displaying a live information flow in the user interface, 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 multiple sources as a tag cloud in a user interface. The tag cloud shows multiple sources corresponding to a selected bucket, in proportion to the usage rate of each source.

[0033] In some embodiments, the system further includes program instructions for receiving requests to create dynamic execution policies based on data. A dynamic execution policy includes specifying a source, destination, action to be taken, and the duration for which the dynamic execution policy is active.

[0034] In some embodiments, the system further includes program instructions for exposing dynamic execution policies onto a policy bus so that multiple agents can access them. The system further includes program instructions for executing action measures in response to one or more security events in a live information flow based on the dynamic execution policies, and at least one of the multiple agents executes the action measures. The system further includes program instructions for updating the user interface to reflect the execution of action measures in response to another security event by (i) identifying from multiple buckets the bucket associated with the action measures applied by the dynamic execution policies and (ii) increasing the total number of current execution policies displayed in the identified buckets, which are triggered in real time by the action measures.

[0035] In some embodiments, during the period in which a dynamic execution policy is active, the dynamic execution policy overrides a static execution policy that includes the same source and destination specifications as those included in the dynamic execution policy.

[0036] In various embodiments, a non-temporary machine-readable storage medium is provided for storing instructions. When these instructions are executed by one or more processors, they cause one or more processors to perform a method which includes the step of monitoring one or more live information flows. The live information flows include data flows from multiple sources to multiple destinations. The method further includes the step of providing a user interface which includes multiple buckets. Each bucket is associated with a different action, and each bucket displays the total number of current execution policies which are triggered in real time and include the associated action. The method further includes the step of determining the occurrence of a security event in one or more live information flows based on the triggers of the execution policies. An execution policy includes the specification of a source, a destination, and an 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 action is applied. The method further includes the steps of (i) identifying the buckets from among multiple buckets that are associated with the action taken by the action policy, and (ii) updating the user interface in real time, triggered by the action, and increasing the total number of current action policies displayed in the identified buckets, in order to reflect the occurrence of security events.

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

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

[0039] In some embodiments, the method further includes the step of receiving a request to create a dynamic execution policy based on data. The dynamic execution policy includes specifying the source, destination, action to be taken, and the duration for which the dynamic execution policy is active. The method further includes the step of exposing the dynamic execution policy on a policy bus so that multiple agents can access it. The method further includes the step of taking action to take action for one or more security events in a live information flow based on the dynamic execution policy, with at least one of the multiple agents taking action. The method further includes the step of updating the user interface to reflect the execution of action for another security event by (i) identifying from multiple buckets the bucket associated with the action applied by the execution policy and (ii) increasing the total number of current execution policies displayed in the identified bucket that are triggered in real time by the action.

[0040] In some embodiments, during the period in which a dynamic execution policy is active, the dynamic execution policy overrides a static execution policy that includes the same source and destination specifications as those included in the dynamic execution policy.

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

[0042] In various embodiments, a method is provided that includes the step of 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 the step of providing a user interface including multiple buckets using a computing system. Each bucket is associated with a different action, and each bucket is triggered in real time and displays the total number of current execution policies, including the associated action. The method further includes the step of determining the occurrence of a security event in one or more live information flows based on the triggers of execution policies using a computing system. An execution policy includes specifying a source, destination, and action, and an execution policy is triggered and an action is applied if data in one or more live information flows matches at least the source and destination of an execution policy. The method includes the step of updating the user interface using a computing system to reflect the occurrence of a security event by (i) identifying buckets from the multiple buckets that are associated with the action applied by the execution policy, and (ii) increasing the total number of current execution policies that are triggered in real time by the action and displayed in the identified bucket.

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

[0044] In some embodiments, the method further includes the steps of using a computing system to receive user input corresponding to the selection of a specific source from a plurality of sources, and using the computing system to display a live information flow starting from the specific source.

[0045] In some embodiments, the method further includes the steps of using a computing system to receive user input corresponding to the selection of a specific destination from a plurality of destinations, and using the computing system to display a live information flow ending at the specific destination.

[0046] In some embodiments, the method further includes the steps of using a computing system to display a live information flow including multiple sources and multiple destinations on a user interface, and providing an indicator that shows 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 the steps of using a computing system to display a live information flow including multiple sources and multiple destinations on a user interface, and providing an indicator that shows a set of higher destinations based on the amount of data flowing from the multiple sources to the multiple destinations.

[0048] In some embodiments, the method involves using a computing system to display a live information flow including multiple sources and multiple destinations in a user interface, and an indicator showing a set of higher-level execution policies based on the amount of data flowing from multiple sources to multiple destinations and a set of active execution policies exposed on a policy bus. This further includes the step of providing catering.

[0049] In various embodiments, the system and method relate to providing an integrated view of users, applications accessed by users, and possible access policies associated with access. In a particular embodiment, a system is provided comprising one or more processors and a non-temporary machine-readable storage medium and program instructions for monitoring live information flows. Live information flows include data flows from a source to a destination. The system further includes program instructions for providing a user interface that includes sources and destinations connected via lines, and program instructions for determining the occurrence of security events in live information flows based on triggers of execution policies. An execution policy includes specifying a source, a destination, and an action to be taken, and the execution policy is triggered and the action to be taken is applied if data in one or more live information flows matches at least the source and destination of the execution policy. The system further includes program instructions for updating the user interface by (i) identifying indicators of the execution policy, and (ii) displaying the lines connecting the sources and destinations passing through the indicators of the execution policy, so as to reflect the occurrence of security events. The program instructions are stored in a non-temporary machine-readable storage medium and executed by one or more processors.

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

[0051] In some embodiments, the system further includes program instructions for monitoring one or more live information flows. A live information flow includes (i) a data flow from multiple sources to multiple 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 multiple sources to each destination of the corresponding multiple destinations, and (ii) an indicator on each line showing the 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 the selection of a specific source from multiple sources, and program instructions for displaying a live information flow that starts from a specific source and includes 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 the selection of a specific destination from a plurality of destinations, and program instructions for displaying a live information flow that ends at a specific 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 requests to create dynamic execution policies based on data. The dynamic execution policy includes specifying the source, destination, action to take, and the duration for which the dynamic execution policy is active. The system further includes program instructions for exposing the dynamic execution policy onto the policy bus so that multiple agents can access it. The system further includes program instructions for taking action based on the dynamic execution policy for one or more security events in a live information flow, and at least one of the multiple agents takes action. The system reflects the execution of action for another security event by (i) identifying indicators of the execution policy and (ii) specifying the source and destination through which the indicators of the execution policy pass. The program further includes instructions for updating the user interface by displaying the connection line.

[0055] In some embodiments, during the period in which a dynamic execution policy is active, the dynamic execution policy overrides a static execution policy that includes the same source and destination specifications as those included in the dynamic execution policy.

[0056] In various embodiments, a non-temporary machine-readable storage medium is provided for storing instructions. When these instructions are executed by one or more processors, they cause one or more processors to perform a method which includes the step of monitoring a live information flow. The live information flow includes a data flow from a source to a destination. The method further includes the step of providing a user interface which includes a source and a destination connected via a line, and the step of determining the occurrence of a security event in the live information flow based on triggers of an execution policy. An execution policy which includes a source, a destination, and an action to be taken, and the execution policy is triggered and the action to be taken is applied if the data in one or more live information flows matches at least the source and destination of the execution policy. The method further includes the step of updating the user interface to reflect the occurrence of a security event by (i) identifying an indicator of the execution policy, and (ii) displaying the line connecting the source and destination passing through the indicator of the execution policy.

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

[0058] In some embodiments, the method further includes the step of monitoring one or more live information flows. The live information flows include (i) data flows from multiple sources to multiple 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 multiple sources to each destination of the corresponding multiple destinations, and (ii) an indicator on each line showing the execution policy triggered by the data flowing between each source and each destination.

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

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

[0061] In some embodiments, the method further includes the step of receiving a request to create a dynamic execution policy based on data. The dynamic execution policy includes specifying the source, destination, action to take, and the duration for which the dynamic execution policy is active. The method further includes the step of exposing the dynamic execution policy on a policy bus so that multiple agents can access it. The method further includes the step of taking action based on the dynamic execution policy for one or more security events in a live information flow, with at least one of the multiple agents taking action. The method further includes (i) identifying an indicator of the execution policy and (ii) the execution policy The further step includes updating the user interface by displaying the circuit connecting the source and destination through which the indicator passes.

[0062] In some embodiments, during the period in which a dynamic execution policy is active, the dynamic execution policy overrides a static execution policy that includes the same source and destination specifications as those included in the dynamic execution policy.

[0063] In various embodiments, a method is provided that includes monitoring live information flows using a computing system. Live information flows include data flows from a source to a destination. The method further includes the steps of providing a user interface using a computing system that includes sources and destinations connected via a circuit, and using a computing system to determine the occurrence of security events in the live information flows based on triggers of execution policies. An execution policy includes specifying a source, a destination, and an action to be taken, and the execution policy is triggered and the action to be taken is applied if data in one or more live information flows matches at least the source and destination of the execution policy. The method further includes the steps of updating the user interface using a computing system to reflect the occurrence of security events by (i) identifying indicators for the execution policy, and (ii) displaying the circuits connecting the sources and destinations passing through the indicators for the execution policy.

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

[0065] In some embodiments, the method further includes the step of monitoring one or more live information flows using a computing system. The live information flows include (i) data flows from multiple sources to multiple 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 multiple sources to each destination of the corresponding multiple destinations, and (ii) an indicator on each line showing the execution policies triggered by the data flowing between each source and each destination.

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

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

[0068] In some embodiments, the method further includes the step of using a computing system to receive a request for creating a dynamic execution policy based on data. The dynamic execution policy includes specifying the source, destination, action to be taken, and the duration for which the dynamic execution policy is active. The method further includes the step of using a computing system to expose the dynamic execution policy on a policy bus so that multiple agents can access the dynamic execution policy. The method uses a computing system to dynamically The method further includes the step of performing an action in response to one or more other security events in a live information flow based on an execution policy, wherein at least one of several agents performs the action. The method further includes the step of using a computing system to update the user interface to reflect the execution of an action in response to another security event by (i) identifying an indicator of the execution policy and (ii) displaying the circuit connecting the source and destination passing through the indicator of the execution policy. [Brief explanation of the drawing]

[0069] [Figure 1]This is a simplified block diagram illustrating a high-level threat intelligence platform according to several embodiments. [Figure 2] This is a simplified block diagram showing the detailed architecture of an information management system according to several embodiments. [Figure 3] This is a simplified block diagram showing some functional elements of a threat visualization system according to several embodiments. [Figure 4A] This figure shows a user interface (UI) for displaying active threat categories according to several embodiments. [Figure 4B] This figure shows a user interface (UI) for displaying active threat categories according to several embodiments. [Figure 5] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 6] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 7] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 8] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 9] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 10] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 11] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 12A] This diagram shows a UI that allows an administrator to create one or more policies, according to several embodiments. [Figure 12B] This diagram shows a UI that allows an administrator to create one or more policies, according to several embodiments. [Figure 13] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 14] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 15] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 16] This figure shows an additional UI for displaying active threat categories according to several embodiments. [Figure 17] This figure shows a UI for displaying active threats based on triggered policies, according to several embodiments. [Figure 18] This figure shows a UI for displaying tracking activities from various sources, according to several embodiments. [Figure 19] This flowchart shows the process for exposing dynamic execution policies on a policy bus in a distributed environment, according to several embodiments. [Figure 20] The flowchart shows a process for providing an integrated view of active threat categories, the number of policies triggered for each threat category, and associated trends, according to several embodiments. [Figure 21] This flowchart shows the process for providing an integrated view of users, applications accessed by users, and possible access policies associated with those accesses. [Figure 22] This is a simplified block diagram showing a distributed system that may be used to implement some embodiments of the present disclosure. [Figure 23] This is a simplified block diagram showing one or more components of a system environment that can provide a service as a cloud service according to several embodiments. [Figure 24] This figure shows an exemplary computer system that may be used to carry out some embodiments of the present disclosure. [Modes for carrying out the invention]

[0070] Detailed explanation I. Introduction The following disclosure describes a threat intelligence platform capable of providing real-time threat detection and analysis. In various embodiments, the provided system includes a processor and memory for storing instructions. When executed by the processor, these instructions cause the processor to receive security events from agents, including at least a destination and a source, and to trigger a policy when the security event matches a policy, which includes specifying the source, destination, and action to be taken, and to execute the action on the security event based on the policy, and to update the user interface to link the source and destination of the security event via the triggered policy. However, in some entities (e.g., a company, a country), thousands or hundreds of thousands of employees and other individuals (e.g., users, advisors, guests) constantly access various services (e.g., sources) through the network, thus triggering security events. As people attempt to access a wide variety of services, various access violations and password errors occur, requiring monitoring. Currently, static security rules within security policies cannot cope with the ever-evolving threats to vulnerable users, vulnerable applications, and vulnerable hosts. When user activity is extremely high (e.g., billions of events per day), manual or in-house analysis using the user interface becomes prohibitively expensive. Furthermore, performing highly accurate automated pattern detection for such a large number of users to prevent unauthorized users from accessing the service would be extremely difficult.

[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 using dynamic policies and displaying an integrated view including 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 analyses, and take corresponding corrective actions. By collecting data in real time or near real time, corrective actions determined based on this data can be applied immediately. For example, when authenticating a user to an application, the time to take measures to prevent an unauthorized user from accessing content may be short (e.g., milliseconds). In additional or alternative embodiments, by collecting data in real time or near real time and storing a history of this data, real-time By applying corrective measures determined based on data and historical data, it is possible to prevent unauthorized users from accessing the network even after user authentication, and to remove such users from the network.

[0072] Some embodiments can visualize user IDs, resource usage patterns, and performance characteristics. Certain embodiments can provide real-time enforcement using specific access controls. For example, certain embodiments can enforce compliance or block user access to unauthorized applications, implement 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 visualizations to present real-time data analytics in a way that is easily understandable to end users. By summarizing large amounts of data and presenting analytical data in a real-time and meaningful way, end users can identify actionable items, ensure that appropriate policies are updated, and ensure that specific policies are enforced.

[0073] In one example, when a user enters their username and password on a login page and submits these user credentials, these 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), data collection and transmission can be performed in less than 1 second or 30 milliseconds. Except for network latency (e.g., if the agent is located on the host machine collecting the information and the data collection bus is on another machine, e.g., the cloud), data transfer occurs with little to no delay (i.e., near real time). However, when a user enters their credentials, the system can determine whether these credentials originated from a specific server and whether additional authentication should be presented to the user if there is suspicious activity. When a user is accessing a page, if the system determines that the user should not be authorized, even if the credentials are valid, it can remove the user from accessing that page.

[0074] In some embodiments, after a user logs into an account, the web proxy can continuously monitor and learn the user's activity and behavior and trigger anomalies (thereby presenting the user with additional authentication). For example, a user attempts to transfer a large sum of money. 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), and the collected data is supplied and analyzed in real time. When a user accesses a protected application or a cloud application not protected by an agent, the proxy server can determine the user's activity, for example, that the user is accessing a specific website and downloading information. The proxy server can monitor the user's activity and, based on the collected data, provide information that the user is blacklisted. Furthermore, the proxy can provide historical information. This allows the system to consider the user's historical information when granting access to a new site.

[0075] Some embodiments can supply available real-time data to a real-time visualization server and present analysis results to customers in real time. When data is provided to customers in real time, actions can be decided quickly in response to the real-time analysis results. Some embodiments store data and use the stored data or historical data. This allows for the creation of additional rules and policies that can be applied in real time. By mining historical data, certain embodiments can create execution policies based on historical data. Certain embodiments can use both historical data and real-time analysis results to trigger anomalies. Advantageously, these techniques can collect, monitor, and visualize extremely large amounts of security data (i.e., billions of streaming events) in real time and take corresponding action.

[0076] II. System Architecture for Threat Detection Figure 1 shows an embodiment of System 100 for real-time threat detection by detecting abnormal access requests from users, according to at least one embodiment of the present disclosure. In some embodiments, System 100 includes an access management and threat detection system 105 and an information management system 110, which are communicably connected to user devices 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 ID Access Manager. Various types of agents exist as part of the ID Access Manager, and these agents protect access to web servers or applications. For example, when a user attempts to access a mail server or document server, a protection agent communicates with the server (e.g., an OAM (Oracle Access Manager) server) Yes, it exists. This agent verifies whether a user can access this server, for example, by verifying authentication information related to their ID. Certain embodiments may have an extended agent and an access manager server. Thus, when a user is requesting data, information that someone is accessing something is transmitted in real time to the data collection engine of the information management system 110.

[0077] Network 120 facilitates communication and data exchange between user equipment 115, access management and threat detection system 105, and information management system 110. Network 120 includes TCP / IP, SNA, IPX, AppleTalk, etc. Data communication can be supported using any of the various commercially available protocols, which are not limited to these, and may be any type of network known to those skilled in the art. For example, network 115 may include, but is not limited to, local area networks (LANs) such as Ethernet® networks and Token Ring networks, wide area networks, virtual networks including but not limited to virtual private networks (VPNs), the Internet, intranets, extranets, public switched telephone networks (PSTNs), infrared networks, and wireless networks (e.g., the IEEE 802.1X protocol suite, the Bluetooth® protocol known in the art, and / or (or networks operating under any other radio protocol) and / or combinations of these networks and other networks.

[0078] User device 110 (for example, various versions of Microsoft Windows®) and / or persons running the Apple Macintosh® operating system The user device 110 may be a general-purpose personal computer (including a smartphone and / or laptop computer), a mobile phone or PDA (for example, running software such as Microsoft Windows Mobile® and with Internet, email, SMS, BlackBerry® or other communication protocols enabled), a workstation computer (including but not limited to various commercially available UNIX® or UNIX-like operating systems, including various GNU / Linux® operating systems), or other computing device. For example, the user device 110 may be a thin client computer that can communicate over a network (e.g., network 115), an internet-enabled game system, and / or a Other electronic devices, such as a social messaging device, may also be used. Although the exemplary system environment 100 is shown to have 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, for example, PC servers, UNIX® servers, midrange servers, mainframe computers, and rack-mount servers), server farms, server clusters, or any other suitable configuration and / or combination. The computing devices comprising the access management and threat detection system 105 can run any operating system or a variety of additional server applications and / or middle-tier applications, including HTTP servers, FTP servers, CGI servers, Java® servers, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®.

[0080] In various embodiments, the access management and threat detection system 105 may include one or more elements capable of operating to protect resources 125 provided by one or more target systems 130 of an organization. In some embodiments, “target system” may refer to any system that provides or contains one or more resources. Locally or remotely accessible resources 125 provided by the target system 130 may be of various kinds, 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 Active Directory services, such as accessing an Active Directory server. In some examples, the target system 130 may be a computing system that provides access to a meeting room, such as a computing system that provides access to a meeting room using badges. 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 within the target system 130. Accounts can be created in the target system 130 based on the resources 125 provided by the target system 130. These accounts may include various types such as user accounts, administrator accounts, and application accounts. Each type of account grants a specific level of access to one or more resources 125 provided by the target system 130. To enable users to access or log in to the target system 130, the target system 130 may include various accounts (e.g., user accounts, administrator accounts, and / or application accounts). Accounts can be created or provided for users or user groups (e.g., organizations) based on the identity of the user or user group. Specific types of accounts can be assigned to users or user groups to access specific types of resources. For example, user An email account on the Exchange server provided is an account for Exchange resources. A user can be given multiple accounts, with each type of account corresponding to a different type of resource. For example, a user may have two different accounts to log in to target system 130 and perform different types of operations. For instance, 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 administrator account for performing administrative functions related to the HR system. A particular user may have both an email account and an HR administrator account on target system 130. When logging in with an email account, the user can access their email. When logging in with an HR administrator account, the user can perform administrative tasks related to managing the organization's resources.

[0082] According to at least some embodiments, a user of user device 115 can communicate with target system 130 and request a resource 125 (e.g., an email application) by accessing a web-based request user interface (UI) on user device 115. For example, the request UI may include a graphical user interface that can be viewed through a client application (e.g., a browser) on user device 115. When a user wants to access a resource on target system 130 or attempts to perform an operation on a resource on 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 may 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 authentication information. The access management and threat detection system 105 may be configured to receive various types of access requests from users via various channels (HTTP, OAP) for various events / actions (e.g., authentication (authN), authorization (authZ), policy verification, step-up authentication, SSO, token issuance), such as web requests, SDK requests, and program requests.

[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 proxies or reverse proxies), one or more access managers 145, and / or one or more webgates 150. The access management and threat detection system 105 may be implemented in system 100 according to an agent-server model to enable communication between user equipment 115 and target system 130 (e.g., distributed environment servers) to provide access control functionality to resource 125. The agent-server model may include agent elements (one or more agents 135, one or more proxies 140, and / or one or more webgates 150, also known as single sign-on agents or policy execution agents) and server elements (one or more access managers 145, also known as single sign-on servers or policy servers). For example, one or more access managers 145 can function as decision elements for controlling access to resource 125, and one or more agents 135, one or more proxies 140 and / or one or more webgates 150 can be implemented or operate as execution elements for controlling access to resource 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 resource 125 as a plug-in to or as part of resource 125, and one or more agents 135, one or more proxies 140 or one or more webgates 150 may be deployed independently of resource 125, for example, to run on a web server prior to resource 125. One or more access managers 145 may be deployed as part of an ID access manager.

[0084] The access management and threat detection system 105 can provide SSO functionality within a distributed environment and can perform various access control-related functions to manage access to resources within 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 webgates 150 can perform authentication of users operating the user device 115. Authentication is the process of determining whether a user is the person they claim to be. To authenticate a user, the access management and threat detection system 105 can present the user with a request to request authentication information in the form of a challenge (e.g., via the user's web browser). Execution policies (e.g., authentication policies) can specify the authentication method used to authenticate users who should be granted access rights to a given resource. These policies define how access to the resource should be protected (e.g., type of encryption). One or more access managers 145 can determine authorization for users accessing resource 125. Authorization is the process of determining whether a user has access rights to the requested resource. An execution policy (for example, an authorization policy) may be defined to specify the conditions under which a user or user group has access to a particular resource. For example, an administrator may authorize specific users within a group to have access to a particular resource.

[0085] One or more agents 135 may be policy execution agents that function as filters for resource requests. One or more agents 135 can 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 is forwarded to one or more access managers 145, which can determine whether the user requesting the protected resource has access to it. In certain embodiments, one or more webgates 150, an innovative solution developed by Oracle, can be used as agents to filter resource requests. According to some embodiments, one or more agents 135 and one or more webgates 150 may be hardware structures or a combination of hardware and software implementations.

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

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

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

[0089] Based on the appropriate authentication information received from the user, one or more access managers 145 will route the user to one or more agents 135, one or more proxies 140 and / or 1 By returning to one or more webgates 150, one or more agents 135, one or more proxies 140, and / or one or more webgates 150 can verify authentication and establish a first session for the authenticated user. As a result, the user logs into that session on the target system 130 (e.g., a distributed environment server). Once logged in, the user can utilize the resources they have been granted access to, such as running different applications or using cloud storage. When a user logs into the target system 130, one or more access managers 145 can create a cookie to track the user's session activity. This cookie may include the time the user was active on that session. This cookie may be stored in the information management system 110 as session activity data.

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

[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, for example, PC servers, UNIX® servers, midrange servers, mainframe computers, and rack-mount servers), server farms, server clusters, or any other suitable configuration and / or combination. The computing devices comprising the information management system 110 can run any operating system or a variety of additional server applications and / or middle-tier applications, including HTTP servers, FTP servers, CGI servers, Java®, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®. In various embodiments, the information management system 110 supports an access management and threat detection system 105 to protect and authorize user access to resource 125. The information management system 110 may be configured to obtain additional information related to user access requests in order to authenticate / authorize user access to target system 130. This information may include, for example, the IP address of the client that sent 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 and create and publish new policies (e.g., dynamic inspection and execution policies) to override static policies over a predetermined period. In some embodiments, available real-time data is presented visually to the customer as part of the system threat analysis results. Providing data to the customer in real time allows for rapid decision-making regarding actions based on the real-time threat analysis results. This is possible. Various embodiments can 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 can create dynamic inspection and execution policies based on historical data by mining the historical data. Other embodiments can create dynamic inspection and execution policies using both historical data and the results of analysis of information obtained in real time.

[0092] Figure 2 shows an embodiment of an information management system 200 (e.g., the information management system 110 described with reference to Figure 1) for collecting information on users accessing resources, publishing policies based on the analysis of the information, and visualizing the analysis results. In some embodiments, the information management system 200 includes a collection bus 205 and a policy bus 210 that are communicably connected to an access management and threat detection system 215 (e.g., the access management and threat detection system 105 described with reference to Figure 2) via a network (i.e., the network 120 described with reference to Figure 1). The information management system 200 may further 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 that are communicably connected to the collection bus 205 and the policy bus 210.

[0093] The collection bus 205 and policy bus 210 include a network topology. In this network topology, nodes such as the analysis server 220, machine learning components 225, visualization servers 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 branched) link called a bus or enterprise service bus. The collection bus 205 and policy bus 210 implement a software architecture for 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 data collection based on inspection policies, and exposing various policies (inspection and execution policies) to listeners (i.e., agents).

[0094] The analysis server 220, machine learning component 225, and 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, for example, PC servers, UNIX® servers, midrange servers, mainframe computers, and rack-mount servers), server farms, server clusters, or any other suitable configuration and / or combination. The computing devices comprising the analysis server 220, machine learning component 225, and visualization server 230 can run any operating system or a variety of additional server applications and / or middle-tier applications, including HTTP servers, FTP servers, CGI servers, Java®, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®.

[0095] The system memory 255 may be one or more storage media, including, for example, a non-temporary 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-temporary storage devices, or any combination thereof. According to different embodiments, the memory 255 stores computer-readable program instructions, data structures, program modules, and other data related to the operation of the system 200. According to particular embodiments, the memory 255 is, In this system, data information related to the operating system, application programs, policies, user activities and access requests, and program data can be stored.

[0096] Once the system in Figure 2 is deployed, the access management and threat detection system 105 (composed of 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 Figure 1) can determine whether an end user's access to a resource on a target system is authenticated and / or authorized, based on rules in static and dynamic execution policies. Rules may include a destination (e.g., URL, hostname, destination IP address, or port of the target system or resource, such as an application or service), a source (e.g., user ID, user group specification, client device IP address), a duration (e.g., a predetermined time for which the policy is in effect), and an action to be taken (e.g., blocking user access, requesting an authentication / authorization factor, monitoring activity). If network traffic or user activity patterns match the rules in the policy, the policy is triggered and the action to be taken is applied. Static and dynamic execution policies may be stored in memory 255 as a cache 265 for static policies and a cache 270 for dynamic policies, respectively.

[0097] In a particular embodiment, the general method is as follows: The end user enters a URL or ID to request a resource on a protected policy domain. The user's browser sends the URL to the web server as part of an HTTP request. One or more agents 235, one or more proxies 240, and / or one or more webgates 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 webgates 250 request 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 webgates 250. One or more agents 235, one or more proxies 240, and / or one or more webgates 250 send an authentication request to one or more access managers 245, which determine whether the login information provided by the user is authentic. One or more access managers 245 perform authentication using the user's ID information attributes and the authentication criteria for resources 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 terminates.

[0098] After authenticating the user, one or more agents 235, one or more proxies 240, and / or one or more webgates 250 query one or more access managers 245 to determine whether the user is authorized to access the requested resource. The one or more access managers 245 then query the information management system 200 for the appropriate authorization criteria for the requested resource. The one or more access managers 245 retrieve the resource's authorization criteria and, based on the resource's authorization criteria and the user's ID information, respond to the authorization queries from the one or more agents 235, one or more proxies 240, and / or one or more webgates 250. If the user is authorized, the user is granted access to the resource. Otherwise, the user's request is denied. Various alternatives to the flow described above are also included in 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). Policy domains are web services. A policy domain is a logical group containing a host ID, hostname, URL prefix, and rules. The hostname and URL prefix specify the course-grain portion of the web namespace protected by a particular policy domain. The rules of a policy domain specify the conditions under which access to a requested resource is permitted or denied, 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. First-level default rules can apply to any resource within a policy domain not associated with a policy, and second-level rules can apply to any resource within a policy domain associated with a policy. A policy is a group that includes URL patterns, resource types, operation types (such as request methods), rules to restrict access to specific resources on a per-user basis, static or dynamic group membership, time or day of the week, IP (Internet Protocol) addresses, etc. A policy may be a static or dynamic policy associated with a policy domain and specifies the fine-grain portion of the web namespace protected by the policy. In practice, the hostname and URL prefix of the policy domain are logically related to the policy's URL pattern. The entire resulting pattern is compared to the received URL. If a match is found, the system determines whether to authorize or deny the request by evaluating the various rules of the policy. If no match is found, the default policy domain rules are used.

[0100] Static and dynamic execution policies are statements that group attributes to express what is allowed and what is not. Execution policies can use any type of attribute (user attributes, resource attributes, object attributes, action attributes, environment attributes, etc.) and include logic such as Boolean logic. In this case, the rule includes statements (e.g., "IF, THEN") to evaluate the attributes and determine what is allowed and what is not (e.g., whether the requesting user is authenticated, whether the requesting user is authorized to access the requested resource, and whether the requesting user is authorized to perform the action of requesting the requested resource). For example, if the requester is a manager, read / write access to sensitive data is permitted. Static execution policies include default rules, or rules that are written / rewritten over the lifetime of the system (e.g., created by the system administrator) to evaluate the evolving dynamics or attributes of the system. However, rules contained within static policies are not written / rewritten in real time. This allows the policy to evaluate the evolving dynamics or attributes of the system in real time. On the other hand, dynamic execution policies include rules that are written / rewritten (e.g., created by machine learning techniques or system administrators) to evaluate the dynamics or attributes of an evolving 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 the 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 being applied to the respective locations of agents in the execution path. In some embodiments, dynamic policies may be created manually by an administrator or automatically introduced into the system by a machine learning component 225. Also, in certain embodiments, the execution period of a dynamic policy (e.g., a predetermined period) can 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 for anomalies based on data within that predetermined period. After the predetermined period has elapsed, the policy becomes invalid. Therefore, some embodiments can monitor the behavior of a system with newly added dynamic policies and ensure system stability. The monitored dynamic policies may be modified to become solid or permanent (i.e., not limited by a predetermined period) policies. Some embodiments use machine learning capabilities to create dynamic policies over a predetermined period (e.g., the next 30 minutes) and ultimately use these dynamic policies to permanently override static policies set on the system. It should be noted that it is inefficient and resource-intensive for security administrators viewing a visualization application to quickly generate and deploy these policies to the system, regardless of whether a full approval process is required.

[0102] In some embodiments, if the machine learning component 225 does not affect the policy, it can create sticky policies (i.e., static policies that cannot be overridden). In other embodiments, the machine learning component 225 can learn default policies or policies created by administrators (e.g., overridable static policies) and modify these policies or override them using dynamic policies. In certain embodiments, machine learning can modify default or static policies previously created by system administrators based on additional data, and can override default or static policies. For example, it can classify anomalies into a specific category corresponding to a blocking policy. This blocking policy is a high-warning policy and can override another category, such as second-factor authentication. This allows the user to be presented with a form or question for additional authentication if they take some action, even if they are in an active session. In other embodiments, it can be specified not to create blocking policies (e.g., policies with logic configured to block a user or group of users from performing actions such as read / write to a resource). This allows administrators to monitor the types of policies triggered by machine learning. For example, during the first few months, administrators can monitor whether machine learning generates multiple high alerts under specific circumstances or patterns, verify these alerts, and determine that machine learning is not generating a large number of false-positive alerts. Then, administrators can adjust policies to create a second-factor authentication policy for a pattern instead of generating a high alert for that pattern.

[0103] In one example, a user might access a server (e.g., the target system) from home or another location between 7:00 AM and 9:00 AM daily, and from their workplace or headquarters between 10:00 AM and 4:00 PM daily. If the user moves to another location and attempts to access the server, the analysis server 220 will determine that the access is abnormal and trigger second-factor authentication, because the system is configured with an anomaly default policy 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, based on the user's behavior patterns, decide not to trigger an anomaly when the user moves to another location. The system can also identify the user's behavior patterns. The system can intelligently determine whether or not to trigger an anomaly based on 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 historical and real-time data. This identity information and policies are updated in real time, rather than weekly or bi-weekly. This means that all historical and real-time data of user activity will be considered for the next anomaly detection. Therefore, anything that could be identified as an anomaly can be quickly taken into consideration for the next decision. Thus, in this example, the new location is updated in memory 255. Because of this, the next time the user logs in while in this geographical location, system activity will not trigger anomaly detection. In effect, a new dynamic policy has been created that overrides the previous policy.

[0104] Figure 2 further illustrates the mechanism for collecting events / data. In some embodiments, if 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, event / data collection is dynamic, and the inspection policy mechanism can facilitate data collection. The collected data can be fed to machine learning, which can then create even more execution policies and trigger anomalies triggered by those policies. For example, when installing a new application, the system can invoke inspection policies (automatically via the collection bus 205 and analysis server 220 or manually via an administrator) to understand how the application functions. The inspection policies can generate data by examining user activity on the application, taking into account the rules of the inspection policies. The collection bus 205, analysis server 220, and machine learning component 225 can automatically classify the activities based on the collected data and determine whether the activities are low-warning, medium-warning, or high-warning activities based on patterns identified from the data. Subsequently, the analysis server 220 and machine learning component 225 can automatically generate dynamic inspection and execution policies based on the data collected by the collection bus 205. The generated policies are published on the policy bus 210 and can be used by agents for a predetermined period, overriding static policies.

[0105] In certain embodiments, all data exposed within the enterprise (e.g., on the enterprise network) can be collected in real time via the collection bus 205 and used and analyzed by the analysis server 220. In some embodiments, the analysis 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 the user interface via the visualization server 230. The machine learning component 225 also uses real-time event and historical data from the collection bus 205, memory 255, and report bus 275. Thus, the machine learning component 225 can detect anomalies and publish policies (inspection policies or execution policies) to the policy bus 210.

[0106] In conventional technology, an agent is configured to collect data, record it as log-ASCII name-value pairs, and send the logs periodically (e.g., every 5 or 10 minutes) to a server. Because the agent may reside in the cloud and the server may be located within or outside the enterprise, the transfer of these logs can be costly. Furthermore, accumulating and sending logs in batches is time-consuming. Various embodiments transfer data from various agents to a collection bus 205 in real time using binary data to highly compress the data, instead of collecting and sending log-ASCII name-value pairs. Certain embodiments transfer values ​​and mechanisms to map the data. For example, an agent sends values ​​to the collection bus 205, which can then determine the format (e.g., schema 1) sent from the agent. Once the format is identified, the values ​​are translated. This is a way to compress and efficiently transfer the data.

[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. Threats can be detected and triggered based on data captured and transmitted by agents, including 0. A set of predefined attributes (e.g., user attributes, resource attributes, object attributes, action attributes, environment attributes, etc.) may not be sufficient when agents need to support newer target systems, applications, and changes to existing application interfaces. Therefore, the system can use dynamic inspection policies to request agents to collect / inspect additional information or attributes, such as data within various payloads (e.g., HTTP), by sending dynamic rules to the agents. This information is reported as part of normal access request events. The machine learning component 225 can then detect anomalies in this new data or information and trigger more anomalies by injecting dynamic execution policies. As more anomalies are triggered, additional execution policies can be created to prevent specific types of traffic. This completes the collection, detection, and execution cycle.

[0108] The collection bus 205 may be configured to acquire information related to security events, such as access requests from end users, and report that 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 the data and notifies the administrator when certain criteria match a predefined pattern. The inspection policy does not trigger an alert when a pattern exists, but collects a set of predefined attributes when a pattern exists. For example, the system may provide an inspection policy user interface (UI) that allows the 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 period). In other embodiments, 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 criteria for the set of predefined attributes to be collected and the 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 memory 255 and becomes part of the historical data. The machine learning component 225 can create and modify inspection and execution policies to efficiently collect the information necessary for threat assessment of user activity on the system by constantly learning from historical and real-time data.

[0109] Event-related information is 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 (as described with reference to Figure 1), and may include, for example, the IP address of the client that sent the request, device information, user information, the requested resource, and the time the request was sent. In certain embodiments, information may be further collected from third-party agents, including GPS applications, weather applications, monitoring software, hardware sensors, load balancing software, etc., within the client device. Information may be collected asynchronously by a collection bus 205. For example, the collection bus 205 may include a queue 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 access requests received from users, such as client context, resource context, user context, The collection bus 205 may be configured to organize information or data obtained and organized from user activity into various categories, such as server context, timestamps, session information, and server instances for processing requests. In various embodiments, the collection bus 205 is configured to store information or data obtained and organized from user activity in an information database 260 in memory 255.

[0110] Figure 2 illustrates a mechanism for creating dynamic execution policies based on collected events / data and exposing these dynamic execution policies to be executed 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 the policy bus 210. In some embodiments, the analysis server 220 and machine learning component 225 are configured to create dynamic execution policies 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, the analysis server 220 and machine learning component 225 may be configured to generate dynamic execution policies for a user or user group by identifying a subset of parameters related to the real-time incoming data and historical data of access requests by the user or user group, and to create dynamic execution policies by analyzing the real-time incoming data and historical data of access requests against the parameter subset. For example, the analysis server 220 and the machine learning component 225 may be configured to create an execution policy by analyzing access requests from a user or user group based on time parameters (e.g., time) that a user or user group typically uses to access one or more applications stored in the target system over a certain period, and by monitoring the user's access time. If a user or user group attempts to access one or more applications at a time outside of the normal time parameters, the execution policy may include rules that require second-factor authentication or rules that block the user or user group.

[0111] In some embodiments, a subset of the parameters to be monitored may be identified / defined by a resource on the target system accessed by the user (e.g., a target application), and the target application may provide this information to the analysis server. For example, a target application (e.g., a financial application) may want to track user access requests based on parameters such as user ID, access time, and access duration. These parameters are configured using the analysis server 220, and the machine learning component 225 can create execution policies for a user or user group by analyzing real-time incoming and historical data of access requests over a period of time against these parameters. In certain embodiments, if data satisfying the subset of parameters to be monitored has not been collected, the analysis server 220 and the machine learning component 225 may be configured to create dynamic inspection policies that are triggered to acquire 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 analysis server 220 and the 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 the user or user group against different sets of parameters related to the access request. For example, as described above, the analysis server 220 and the machine learning component 225 may generate policies based on the time a user or user group typically accesses various applications stored in the target system. The analysis server 220 and machine learning component 225 may be configured to generate time-dependent policies for a user or user group by analyzing access requests from a user or user group. In another example, the analysis server 220 and machine learning component 225 may be configured to generate application access pattern policies for a user by analyzing patterns of how a user accesses various applications stored in the target system. The analysis server 220 and machine learning component 225 may also be configured to generate policies for a user by capturing features of security threats, intrusions, and denial-of-service (DoS) attacks from access requests.

[0113] In some embodiments, the analysis server 220 and the machine learning component 225 may be configured to generate policies by classifying real-time incoming and historical data of access requests associated with a user or user group into one or more data clusters. In certain embodiments, the analysis 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 from the centroid of a cluster to an access request using density-based clustering algorithms and unsupervised learning with Euclidean distance. In a particular example, the radius of a cluster is calculated based on the average distance of each point in the cluster from the centroid. Based on the standard deviation, points located outside the radius have a higher risk. The closer user activity on the corporate network is to the centroid, the lower the risk of access.

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

[0115] In some embodiments, the analysis server 220 and machine learning component 225 may be further configured to classify policies based on threat levels after establishing clusters. The threat level may be determined based on the distance from the center of the cluster. As an example, traffic patterns on an enterprise network may have attributes used to generate policies according to a set of criteria, e.g., the distance from one or more clusters to the traffic pattern. If the distance is 1x (e.g., one 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., two 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 three standard deviations from the mean), the policy is classified as blocking, and the associated traffic pattern triggers a block of activity. Thus, customers do not need to worry about whether a traffic pattern is an abnormal pattern or not. Instead, customers focus on whether the traffic pattern has generated a low alert, medium alert, high alert, second-factor authentication, or block. It is possible.

[0116] As described herein, policies may be generated by the analysis server 220 and machine learning component 225 or by an administrator (the person observing the occurrence of anomalies). Some embodiments use STIX (Structured Threat Information eXpression) as a standard for declaring policies. In various embodiments, once established or generated, a policy (e.g., a new dynamic execution policy) is exposed to the policy bus 210 and executed by agents (e.g., one or more agents 235, one or more proxies 240, one or more access managers 245 and / or one or more webgates 250). When a policy is executed by agents, the agents become part of the execution ecosystem. For example, when a new access request is received from a user or user group, one or more agents 235, one or more proxies 240, one or more access managers 245 and / or one or more webgates 250 are configured to determine whether the user or user group's access request is anomalous by analyzing information related to the access request against an 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 first be configured to select a policy for a user or user group from a plurality of execution policies exposed on the policy bus 210. In certain embodiments, the policy may be specifically associated with a user or user group. The selection may be based, for example, on the type of application for 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 a 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 a 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 the access request from the 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 a plurality of execution policies exposed on the policy bus 210 and analyze access requests from a user or user group based on parameters from all or some of the policies.

[0118] 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 determine whether a user's access request is abnormal by selecting or retrieving a specific policy and then analyzing information related to the access request in relation to that policy. 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 determine an abnormal request by determining a deviation of the access request from one or more data clusters generated by the analysis server 220 and machine learning components 225. If the deviation exceeds a predetermined threshold, the request is determined to be abnormal. The threshold may be determined by a user of the system (e.g., an administrator) or may be determined automatically by the analysis server 220 and machine learning components 225. In certain embodiments, the threshold may be the Mahalanobis distance, taking into account the correlation of the cluster's datasets.

[0119] Each agent can independently react to a published policy to achieve the same ultimate goal (e.g., not granting access to protected resources to unauthorized / unauthenticated users). In a particular embodiment, when 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 their role 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 may become entities to verify the user's credentials and authenticate that the user is part of an authentication session, and one or more agents 235, one or more proxies 240 and / or one or more webgates 250 may start, maintain, or terminate the session so that the user can be challenged and authenticated at any time when the user is accessing resources in any part of the execution ecosystem. One or more proxies 240 can continuously monitor and learn about the activities of a user or user group, and based on policies, can trigger anomalies and take action to block activities. For example, one or more proxies 240 can obtain information about a user that is blocked by policy, and if they receive a session request from the IP address corresponding to that user, one or more proxies 240 can block the creation of the session. Therefore, even if the resource is not protected by other agents, one or more proxies 240 can take their own actions regarding user activity because they have the same policies as the policy bus 210.

[0120] Additionally or alternatively, one or more agents 235, one or more access managers 245, and / or one or more webgates 250 can continuously monitor and learn the activities of a user or user group (e.g., a user attempting to enter a username or password on a login page, a user attempting to access a protected application, or an attempting to access another website from an authorized session) and, based on the same policy, take action to trigger anomalies and block activities. For example, one or more agents 235 and / or one or more webgates 250 can check whether a session is still valid based on whether the period has expired. In some examples, a time-based session is valid for a predetermined period, e.g., one hour or eight hours. When a session becomes invalid, the user is asked to log in again. One or more agents 235 and / or one or more webgates 250 can validate the session using the policy and disconnect the session when it becomes invalid. Also, one or more access managers 245 can obtain the same policy. Therefore, the next time the same user attempts to log in using the correct username and password, one or more access managers 245 may deny user access. Thus, even if a resource is not protected by one or more agents, for example, one or more proxies 240, one or more agents 235, one or more access managers 245, and / or one or more webgates 250 can take their own actions regarding user activity because they have the same policies as the policy bus 210. Thus, unlike traditional systems where agents react similarly as a group once rules are determined, each agent can react to policies in a different way.

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

[0122] The integrated user interface 280 may be presented to the security administrator when they log in to the system. The integrated user interface 280 can 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 supplied to the system. The integrated user interface 280 can present how often a user accessed different sources on the network over a certain period (e.g., 5 or 30 minutes). The integrated user interface 280 may be constantly updated as new data comes in, for example, to show "current time - 5 minutes". Top active IP addresses can also be shown. Some embodiments can show a correlation between very active IP addresses and popular and high-traffic sources (e.g., URLs). Also, certain embodiments can mark the IP addresses of unidentified users (e.g., using asterisks).

[0123] Some embodiments may present client IP address-application mapping in addition to user-application mapping. Certain embodiments may indicate that a particular IP address can access many different sources, or vice versa, that all different users can access a particular URL. The integrated user interface 280 presents the end user (or client's IP address) on one side and the end source on the other. Also, some embodiments may use color to distinguish groups. Furthermore, certain embodiments may also present information such as the number of times each application has been accessed. Some embodiments may indicate the number of times an application has been accessed from a particular user or client's IP address by selecting that IP address.

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

[0125] III. Integrated User Interface Figure 3 is a block diagram showing some functional elements of the 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)). Users (e.g., customers or administrators) can monitor user activity on the enterprise network through the multiple user interfaces to detect threats in real time. The multiple user interfaces are multiple UIs. This includes UIs 320, 325, 330, and 335 (for example, the integrated user interface 280 described with reference to Figure 2). In some embodiments, UIs 320, 325, 330, and 335 reside in one or more workstations. In other embodiments, UIs 320, 325, 330, and 335 reside in one or more personal computers. Typically, UIs 320, 325, 330, and 335 can reside in any computing system. Although four UIs are shown in Figure 3, any number of UIs can be developed and provided according to the embodiments described herein.

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

[0127] Application servers 340 and 345 are connected to a database management system 350 (for example, memory 255 as described with reference to Figure 2) within the database tier 315. The database management system 350 may be any type of custom-made 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, etc. Exemplary database servers include, but are not limited to, commercially available ones from companies such as Oracle®, Microsoft®, Sybase®, and IBM®. The database management system 350 is connected to a cache and database 355 (for example, caches 265, 270, and database 260 as described with reference to Figure 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 databases 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 triggered policies for each threat category, and associated trends. As shown in Figures 4A and 4B, some embodiments can provide an integrated UI 400 for active threats based on a threat level classification scheme. As described herein, execution policies (e.g., static policies and dynamic policies) can be classified into blocking policies, step-up or second-factor policies, high-warning policies, medium-warning policies, and low-warning policies, respectively. For example, the analysis server 220 and machine learning component 225 may dynamically create an "anomalous application access" policy as a low-warning if, for example, only one access is observed. However, based on other factors, the same policy may be introduced as a second-factor policy to block access by unauthenticated users. The application layer 310 can use such a classification scheme for policy enforcement measures to display a dashboard 402 of the integrated UI 400 that includes various buckets corresponding to block 405, step up or second factor 410, high alert 415, medium alert 420, and low alert 425. The classification scheme for threat levels of policy enforcement measures allows administrators to evaluate policies and raise levels from low to high or vice versa. This is possible. Additionally, some embodiments may include a machine learning component 225 when evaluating a policy or determining whether the policy's threat level is rising or falling. Furthermore, by providing an integrated UI 400 for active threats based on threat level rather than policy name, security management groups can focus on different types of threats and measures based on classification, instead of interpreting threat levels based on policy name.

[0129] Buckets 405, 410, 415, 420, and 425 can contain the total number "n" 430 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 can further contain the associated trends for each classification in addition to the number "n" 430 triggered policies. For example, a graphic such as marker 435 and graph 440 can be used to show the historical trend corresponding to the number "n" 430 triggered policies. In some embodiments, if the number "n" 430 triggered policies is increasing (e.g., n+1, 5, 10, 15, etc.), such a trend can be easily indicated using an upward arrow. Conversely, if the number "n" 430 triggered policies is decreasing (e.g., n-1, 5, 10, 15, etc.), such a trend can be easily indicated using a downward arrow. If the number of triggered policies "n" 430 are substantially similar (e.g., + / - 5%, 10%, or 15%), such trends can be easily illustrated using circles. In certain embodiments, buckets 405, 410, 415, 420, and 425 further include a dropdown box 445, which administrators can use to further investigate details about triggered policies and activities being performed by users (sources being accessed) on the corporate network. In certain embodiments, the integrated UI 400 further includes an additional bucket 450 to show the total number of policies "m" (all classification groups) running at any given time.

[0130] According to various embodiments described herein, user behavior on an enterprise network can be monitored, and one or more dynamic policies can be created for users. In some embodiments, an administrator or machine learning component 225 can set up execution policies to trigger blocking, second-factor authentication, low alert, medium alert, or high alert based on specific behavior. For example, the machine learning component 225 can detect fluctuations or deviations from real-time data from historical data (e.g., a user usually accesses from home around 7 or 8 p.m., but today the user is accessing from a different location) and create a policy for this unusual access. This policy can specify an alert level (e.g., low, medium, or high alert), second-factor authentication, or blocking for the access. Based on whether the user was authenticated with a challenge presented via second-factor authentication, the system can use historical data to modify the policy. If further user behavior increases the alert level and the new policy designates the user's behavior as a high alert behavior, the integrated user interface 400 can begin presenting the high alert behavior via the dashboard 402. If this user has received multiple high alerts (e.g., 10 or 20 times) in a short period (e.g., the last 10 or 20 seconds), there may be a problem, and the machine learning component 225 can alert the administrator via the integrated user interface 400.

[0131] In some embodiments, the dashboard 402 may include various windows 455 that display information including top access activity, top users accessing the source, top IP addresses used to access the source, and top sources being accessed. Top or bottom may be defined as threshold numbers such as 5, 10, 15, 35, or 50. Alternatively, top or bottom may be: For example, it may be defined as a threshold percentage such as the top or bottom 5%, 10%, 15%, 35%, or 50%. Window 455 can display information using any graphic means. For example, top access activity can be displayed using pictograms or diagrams 460 that show lines connecting each user ID or IP address to the accessed resource or target system. Additionally or alternatively, top users can be displayed using proportional area charts, bubble charts, or tag clouds 465 with print modifications such as font size or color. Additionally or alternatively, top IP addresses can be displayed using proportional area charts, bubble charts, or tag clouds 470 with print modifications such as font size or color. Additionally or alternatively, applications can be displayed using proportional area charts, bubble charts, or tag clouds 475 with print modifications such as font size or color.

[0132] In some embodiments, the presentation layer 305, application layer 310, and database layer 315 can further operate to provide additional functionality or information to the administrator. For example, as shown in Figure 5, the administrator can view the resources 515 accessed by a specific user 505 by placing an input device, such as a mouse pointer, over that user 505 in the dashboard window 510. Also, as shown in Figure 6, the administrator can view a specific count or number of times 615 that a user or IP address has accessed a resource by placing an input device, such as a mouse pointer, over a specific URL 605 in the dashboard window 610. As shown in Figure 7, the administrator can view the various users 715 accessing a specific URL 705 by placing an input device, such as a mouse pointer, over that URL 705 in the dashboard window 710. As shown in Figure 8, the administrator can selectively monitor a specific user 805 by selecting that user 805 from the dashboard window 810 using an input device, such as a mouse pointer. As shown in Figure 9, the administrator can monitor the activity 905 of a specific user 910 using a proportional area chart 915 or a bubble chart. As shown in Figure 10, the administrator can see the number of times a specific user 1010 has accessed a URL 1015 within 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, the administrator can monitor the activities 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). Figures 12A and 12B show an example of a UI 1205 for enabling an administrator to create one or more policies according to a particular embodiment. In some embodiments, an administrator may create one or more policies using one of the UIs described herein after observing abnormal activity. The administrator may specify a policy source 1210 by specifying a user ID, IP address, or group, or may specify any source by leaving source 1210 blank. The administrator may specify a policy destination 1215 using a hostname, target system name or ID, IP address, resource name, etc., or may specify any destination by leaving destination 1215 blank. The administrator may specify an action 1220 for the policy. Action 1220 may include low alert, medium alert, high alert, second-factor authentication, or block. Furthermore, policies can be classified as low-risk, medium-risk, high-risk, second-factor authentication risk, or blocking risk based on the threat level detected from anomalous activity. Administrators can then determine if a policy is... A period of activity or a predetermined period 1225 can be specified. In some embodiments, the period 1225 can be 5, 15, 30, or 60 minutes. This allows the administrator to view the impact of the policy on network traffic during the predetermined period via one of the UIs described herein. Subsequently, if the policy does not have the intended effect or is no longer applicable to abnormal activity, the administrator can revoke the policy or extend its active state by changing the period 1225. In certain embodiments, the period 1225 can be made permanent. This allows the administrator to permanently override static policies 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 can further operate to provide additional functionality or information to the administrator. In some embodiments, the administrator can be shown a number of policies of a particular type (e.g., blocking policies) at a given time interval. In certain embodiments, the administrator can view policies that have triggered a particular action or warning (e.g., blocking) (e.g., by selecting a UI element). For example, as shown in Figure 13, according to a particular embodiment, the administrator can view the names of the top policies 1305 for each classification in window 1310 by selecting the corresponding mode 1315 (e.g., top blocking policy mode). Also, in some embodiments, the administrator can view, in window 1325, the top users 1320 associated with a top policy 1305 and who have violated the policy multiple times. Top or bottom may be defined as threshold numbers such as top or bottom 5, 10, 15, 35, or 50. Alternatively, upper or lower may be defined as threshold percentages, for example, 5%, 10%, 15%, 35%, or 50% of the upper or lower categories. As shown in Figure 14, according to some embodiments, the administrator can view the actions taken (e.g., blocks) based on the resource 1405 and upper policy 1305 within window 1410. These views allow the administrator to see the users, resources, IP addresses, and policies associated with the upper policies triggered for each classification or detected threat level. In some embodiments, the administrator can select a specific user and view the number of alerts caused by that specific user (e.g., 15 blocks and 2 second factors caused by that user).

[0135] By presenting administrators with various types of information, they can take appropriate action (for example, in response to different trends). The UI described herein indicates an upward trend for specific warnings, allowing administrators to take appropriate action based solely on the upward trend when they see it. In some embodiments, administrators can see the user / client IP addresses / sources accessing specific applications that have been blocked by high warnings according to a specific policy. When viewing policies, certain attributes allow administrators to distinguish between manually implemented policies and machine learning policies. In some embodiments, administrators can edit only manually created policies, and not machine learning policies.

[0136] In various embodiments, the administrator monitors low, medium, and high alerts and provides recommendations that the specific policy causing the alert needs to be modified, for example, a recommendation that a high alert needs to be modified for a blocking policy. Other system administrators receive notification of the recommended policy to be changed and can decide whether or not to upgrade that policy to a blocking policy. As shown in Figure 15, according to a particular embodiment, the administrator can see 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). As shown in Figure 16, according to several embodiments, the administrator can see the actions taken based on resource 1605 and higher policy 1505 in window 1610 (e.g., high alert), and the actions taken based on IP address 1615 and higher policy 1505 in window 1620 (e.g., high alert).

[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 accessed by users, and possible policies related to access activities. As shown in Figure 17, some embodiments can provide an integrated UI 1700 that indicates active threats based on triggered policies. For example, in certain embodiments, an administrator can see the policy that triggered a particular action or warning (e.g., blocking). As shown in Figure 17, the administrator can see a window 1705 that shows the source 1705 of the activity on the corporate network that triggered the policy (e.g., user ID, group designation, IP address, client device ID, etc.), 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 of the activity from source 1705 (e.g., the resource or service being accessed). These displays allow the administrator to see the policies and resources triggered by each user. In some embodiments, the administrator can select a specific user and focus on the policies triggered by that user (for example, this user triggered 15 blocking policies and 2 second-factor policies). As shown in Figure 18, the administrator can view tracking activity for various sources 1805, client IP addresses 1810, destination IP ports 1815, destination hostnames 1820, requested URLs 1825, each triggered policy 1830, and policy classifications 1840 indicating the actions taken against policy 1830. In some embodiments, the tracking activity can be searched using a search bar 1845.

[0138] IV. Processes and operations for utilizing the threat intelligence platform Figures 19–21 illustrate techniques for analyzing security events using dynamic policies according to several embodiments, providing an integrated view including active threats, user activity, and dynamic policies triggered by active threats and user activity within a distributed environment. Individual embodiments may be described as processes shown as flowcharts, flow diagrams, data flow diagrams, structural diagrams, or block diagrams. While flowcharts describe operations as sequential processes, many operations may be performed in parallel or simultaneously. The order of operations may also be changed. A process terminates when its operation is complete, but may include additional steps not shown in the diagrams. A process may correspond to a method, function, procedure, subroutine, subprogram, etc. If a process corresponds to a function, the termination of the process may correspond to a return to the calling function or main function.

[0139] The processes and / or operations shown in Figures 19-21 can be implemented in one or more processing units (e.g., processor cores) hardware, or in software (e.g., code, instructions, programs) executed by a combination thereof. The software can be stored in memory (e.g., memory devices, non-temporary computer-readable storage media). The specific set of processing steps shown in Figures 19-21 are not intended to be limiting. Other sets of steps can 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 shown in Figures 19-21 may include multiple substeps that can be performed in various orders appropriate to each step. Furthermore, additional steps may be added or removed depending on the specific application. Those skilled in the art will recognize many variations, modifications, and alternatives.

[0140] Figure 19 is a flowchart 1900 illustrating the process for creating and publishing dynamic policies according to various embodiments. In some embodiments, the process shown in flowchart 1900 may be carried out by an access management and threat detection system 105 and an information management system 110 shown in Figure 1 and described with reference to Figure 2. In step 1905, a distributed environment is provided or instantiated, which includes a user device, multiple 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 machine learning components, and inspection policies and dynamic execution policies are created by the analysis server and machine learning components. In certain embodiments, the distributed environment further includes memory for storing inspection policies, dynamic execution policies, and historical data received from one or more information flows.

[0141] In the optional step 1910, inspection policies can be created based on historical data or the specification of a target system or resource. In some embodiments, data collection is triggered by inspection policies exposed on the policy bus. For example, the collection bus may be configured to acquire information related to security events, such as end-user access requests, and report that information or data to the report bus. The collection bus 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 system may provide an inspection policy UI, which administrators can use to create inspection policies by specifying a particular inspection policy that is triggered when a set of criteria is met (e.g., when header data matches within a certain time interval). In other embodiments, the collection bus may be configured based on a dynamic inspection policy that includes rules for collecting data or attributes. For example, the collection bus and the analysis server can work together to collect a set of predefined attributes and trigger anomalies based on previously configured rules (default, static, or dynamic inspection and execution policies). This inspection policy includes rules for collecting data in real time that is a set of predetermined attributes of a security event when a set of criteria for the security event matches a predetermined pattern. The data is collected by a collection bus, stored in memory, and becomes part of the historical data. A machine learning component can create and modify inspection and execution policies to efficiently collect the information necessary for threat assessment of user activity on the system by continuously learning from the historical and real-time data.

[0142] In the optional step 1915, the inspection policy can be exposed to or introduced into the policy bus so that multiple agents can access the inspection policy. Exposing the inspection policy to 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 about security events can 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 by the collection bus from at least one of multiple agents. In some embodiments, the data is collected according to a default, static, or dynamic inspection policy. For example, if the criteria of a live information flow, including a data flow from source to destination, match a predefined pattern in the default, static, or dynamic inspection policy, the inspection policy is triggered, and one or more agents execute the inspection policy based on attributes of the information flow (e.g., source and destination) or events occurring within the information flow. Security events can be collected. The collected attributes may then be transmitted to a collection bus in accordance with the various embodiments described herein for further processing.

[0143] In step 1925, a dynamic execution policy can be created based on data. A dynamic execution policy includes at least a source, destination, action, and a specified duration for which the dynamic execution policy is active. The duration may be a predetermined period, such as 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 period in which the dynamic execution policy is active, it overrides any static execution policies that include at least the same source and destination specifications. For example, a static execution policy is by 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 first-level authentication. A dynamic execution policy may be exposed for a user or user group from the same IP address whenever a user from that IP address attempts to access a resource on the same specified target system that requires second-factor authentication. A dynamic execution policy may have a duration of 5 hours. Therefore, if the static execution policy is inactive during a specified period (e.g., 5 hours), the dynamic execution policy is active during that period (e.g., second-factor authentication is performed for access requests from an IP address to a specific target system). After the specified period (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 specific target system).

[0144] In certain embodiments, the system may provide an execution policy UI, which an administrator can use to create a dynamic execution policy by specifying a particular action to be triggered when a set of attributes is met (for example, when a live information flow matches the source and destination of the policy). In other embodiments, the analytics server and machine learning components create the dynamic execution policy. Creating a dynamic execution policy involves classifying real-time collected data and historical data into one or more data clusters, analyzing a set of predefined attributes using one or more data clusters, and, based on the analysis, creating a source, destination, action, and duration for which the dynamic execution policy is active. One or more data clusters may be generated using supervised or unsupervised machine learning or clustering techniques, and the analysis may include calculating the distance from the centroid of one or more data clusters to a set of predefined attributes. Actions such as block authentication or second-factor authentication may be determined based on the distance from the centroid of one or more data clusters to a set of predefined attributes.

[0145] In step 1930, the dynamic execution policy can be exposed on the policy bus so that multiple agents can access it. Exposing the dynamic execution policy on the policy bus facilitates, for example, the detection of threats on the corporate network by allowing listeners (i.e., agents) to access the policy and activate the policy's enforcement actions based on previously configured rules. In step 1935, enforcement actions may be taken in response to security events based on the dynamic execution policy. In some embodiments, at least one of the multiple agents executes the enforcement action. The enforcement action is determined to be based on the attributes of the information flow (e.g., source and destination) or the security events occurring within the information flow, and which match the attributes of the specified dynamic execution policy (e.g., source and destination). If so, this may be carried out by at least one of the multiple agents. Subsequently, the action may be carried out by at least one of the multiple agents, for example, by (i) blocking user access to the destination before user access is authorized, (ii) disconnecting the connection between the user and the destination, (iii) blocking user authentication on the system, (iii) requiring second-factor authentication or authorization, or (iv) reporting a low, medium, or high alert.

[0146] Figure 20 is a flowchart 2000 illustrating a process for providing an integrated view of active threat categories, the number of policies triggered for each threat category, and associated trends. In some embodiments, the process shown in flowchart 2000 may be performed by an access management and threat detection system 105 and an information management system 110, shown in Figure 1 and described with reference to Figure 2. In step 2005, a distributed environment is provided or instantiated, including a user device, multiple 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 machine learning components, and inspection policies and dynamic execution policies are created by the analysis server and machine learning components. In certain embodiments, the distributed environment further includes memory for storing inspection policies, dynamic execution policies, and historical data received from one or more information flows.

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

[0148] In step 2020, based on the trigger of an execution policy, it is determined that a security event has occurred in one or more live information flows. An execution policy may include specifying a source, destination, and action, and the execution policy is triggered and the action is applied if the data in one or more live information flows matches at least the source and destination of the execution policy. In step 2025, the user interface can be updated to reflect the occurrence of a security event by (i) identifying the bucket associated with the action applied by the execution policy from among multiple buckets, and (ii) incrementing the total number of current execution policies that are triggered in real time by the action and displayed in the identified bucket. In some embodiments, incrementing the total number of execution policies includes incrementing the count n of the total number of execution policies to a count n+1. In an optional step 230, a trend indicator showing the identified bucket can be updated based on the occurrence of a security event. For example, updating the trend indicator may include an upward arrow, a downward arrow or neutral It may include displaying yen.

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

[0150] In an optional step 2040, user input can be received corresponding to the selection of a specific source from multiple sources. In some embodiments, depending on the selection, a live information flow starting from the specific source is displayed. In an optional step 2045, user input can be received corresponding to the selection of a specific destination from multiple destinations. In some embodiments, depending on the selection, a live information flow ending at the specific destination is displayed. In an optional step 2050, a live information flow including multiple sources and multiple destinations can be displayed in the user interface. In some embodiments, an indicator can be provided showing a set of higher-level sources based on the amount of data flowing from multiple sources to multiple destinations. In an optional step 2055, a live information flow including multiple sources and multiple destinations can be displayed in the user interface. In some embodiments, an indicator can be provided showing a set of higher-level destinations based on the amount of data flowing from multiple sources to multiple destinations. In an optional step 2060, a live information flow including multiple sources and multiple destinations can be displayed in the user interface. In some embodiments, an indicator can be provided showing a set of higher-level execution policies based on the amount of data flowing from multiple sources to multiple destinations and a set of active execution policies published on the policy bus.

[0151] In an optional step 2065, a request can be received to create a dynamic execution policy based on the data. The dynamic execution policy may include a source, destination, action, and a specification for the period during which the dynamic execution policy is active. In an optional step 2070, the dynamic execution policy can be exposed on the policy bus so that multiple agents can access it. As described herein, the period may be a predetermined period such as 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 period in which the dynamic execution policy is active, the dynamic execution policy overrides any static execution policies that include at least the same source and destination specifications. In an optional step 2075, an action can be taken based on the dynamic execution policy for one or more other security events in a live information flow. At least one of the multiple agents can take the action. In the optional step 2080, the user interface can be updated to reflect the execution of action measures in response to another security event by (i) identifying the buckets from among multiple buckets that are associated with the action measures applied by the execution policy, and (ii) increasing the total number of current execution policies displayed in the identified buckets that are triggered in real time by the action measures.

[0152] Figure 21 is a flowchart 2100 illustrating a process for providing an integrated view of users, applications accessed by users, and possible access policies associated with access. In some embodiments, the process shown in flowchart 2100 may be carried out by the access management and threat detection system 105 and the information management system 110 shown in Figure 1 and described with reference to Figure 2. Step 21 In 05, a distributed environment is provided or instantiated, which includes a user device, multiple 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 machine learning components. Inspection policies and dynamic execution policies are created by the analysis server and machine learning components. In certain embodiments, the distributed environment further includes memory for storing inspection policies, dynamic execution policies, and historical data received from one or more information flows.

[0153] In step 2110, a live information flow can be monitored. The live information flow may include a data flow from a source to a destination. In some embodiments, monitoring is performed by multiple agents. Monitoring may be performed according to various policies (e.g., inspection policies and execution policies). In the 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 flow may include (i) a data flow from multiple sources to multiple destinations, and (ii) one or more execution policies triggered by the data. In step 2120, a user interface can be provided that includes sources and destinations connected via lines. For example, as shown in Figure 17, each source included in the live information flow may be connected via a graphical line to one or more destinations being accessed. If additional live information flows are selectively monitored, the user interface may 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) indicators on each line showing execution policies 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 trigger of an execution policy. An execution policy may include the specification of a source, destination, and action to be taken, and the execution policy is triggered and the action to be taken is applied if data in one or more live information flows matches at least the source and destination of the execution policy. In step 2130, the user interface can be updated to reflect the occurrence of a security event by (i) identifying an indicator for the execution policy, and (ii) displaying the line connecting the source and destination that passes through the indicator for the execution policy. In some embodiments, the source is displayed on one side of the user interface window, the destination is displayed on the other side of the window opposite to the side with the source, and the indicator for the execution policy is displayed on the line between the source and destination.

[0155] In optional step 2135, user input can be received corresponding to the selection of a specific source from multiple sources. In some embodiments, depending on the selection, a live information flow starting from a specific source containing one or more execution policies triggered by data in the live information flow is displayed. In optional step 2140, user input can be received corresponding to the selection of a specific destination from multiple destinations. In some embodiments, depending on the selection, a live information flow ending at a specific destination containing one or more execution policies triggered by data in the live information flow is displayed. In optional step 2145, a live information flow containing multiple sources and multiple destinations can be displayed in the user interface. In some embodiments, an indicator can be provided showing a set of top sources based on the amount of data flowing from multiple sources to multiple destinations. In optional step 2150, a live information flow containing multiple sources and multiple destinations can be displayed in the user interface. In some embodiments, an indicator can be provided showing a set of top destinations based on the amount of data flowing from multiple sources to multiple destinations. In version 2155, live information flows including multiple sources and multiple destinations can be displayed in the user interface. In some embodiments, an indicator can be provided that shows a set of higher-level execution policies based on the amount of data flowing from multiple sources to multiple destinations and a set of active execution policies exposed on the policy bus.

[0156] In an optional step 2160, a request can be received to create a dynamic execution policy based on the data. The dynamic execution policy may include a source, destination, action, and a duration for which the dynamic execution policy is active. In an optional step 2165, the dynamic execution policy can be exposed on the policy bus so that multiple agents can access it. As described herein, the duration may be a predetermined period such as 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 duration for which the dynamic execution policy is active, the dynamic execution policy overrides any static execution policies that include at least similar source and destination specifications. In an optional step 2170, an action can be taken based on the dynamic execution policy for one or more other security events in a live information flow. At least one of the multiple agents can take the action. In the optional step 2175, the user interface can be updated to reflect the execution of action in response to another security event by (i) identifying the execution policy indicator and (ii) displaying the circuit connecting the source and destination through which the execution policy indicator passes.

[0157] V. Computing Environment Figure 22 is a simplified diagram showing a distributed system 2200 for carrying out one embodiment of the present disclosure. In the illustrated embodiment, the distributed system 2200 includes one or more client computing devices 2202, 2204, 2206, and 2208 configured to run 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 connected to the remote client computing devices 2202, 2204, 2206, and 2208 via the network 2210 in a communicative manner.

[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 the software applications may include non-virtual and virtual environments. In some embodiments, these services may be web services or cloud services, or SaaS (Software as a Service). Based on the model, these 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 exchanging information with server 2212 using one or more client applications.

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

[0160] Client computing devices 2202, 2204, 2206 and / or 2208 may include various types of computing systems. For example, the client devices may include software such as Microsoft Windows Mobile® and / or iOS, Windows® Phone, Android®, etc. This may include handheld mobile devices (e.g., iPhone®, mobile phones, iPad®, tablets, personal digital assistants (PDAs)) or wearable devices (Google Glass® head-mounted displays) capable of running various mobile operating systems such as Rackberry® 10 and PalmOS. The devices can support various applications, such as various internet-related applications, email applications, and short message service (SMS) applications, and can use various other communication protocols. Furthermore, the client computing device may, as an example, run Microsoft Windows®. The ting system, Apple Macintosh® operating system and / or Or it may include general-purpose personal computers, including personal computers and / or laptop computers, running various versions of the Linux® operating system. Client computing devices may also be workstation computers running various commercially available UNIX® or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems, such as Google Chrome OS. Client computing devices may also include other electronic devices such as thin client computers that can communicate over network 2210, internet-enabled game systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices), and / or personal messaging devices.

[0161] The distributed system 2200 in Figure 22 is shown to have four client computing devices, but it can support any number of client computing devices. Other devices, such as devices with sensors, can exchange information with the server 2212.

[0162] The network 2210 of the distributed system 2200 may support data communication using any of a variety of commercial protocols, including but not limited to TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internet Packet Switching), AppleTalk, etc., and may be any type of network familiar to those skilled in the art. For illustrative purposes only, the network 2210 may be a local area network (LAN), an Ethernet®-based network, 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., IEEE 1002.11 protocol suite, Bluetooth®, and / or any other wireless protocol). This may include networks operating under Tocol and / or combinations of these networks with other networks.

[0163] Server 2212 may consist of one or more general-purpose computers, dedicated server computers (including, for example, PC (personal computer) servers, UNIX® servers, midrange servers, mainframe computers, and rack-mount servers), server farms, server clusters, or any other suitable configuration and / or combination. Server 2212 may include one or more virtual machines or other computing architectures including virtualization running a virtual operating system. One or more flexible pools of logical storage can be virtualized to maintain the server's virtual storage. A virtual network may be controlled by Server 2212 using software-defined networking. In various embodiments, Server 2212 may be configured to run one or more services or software applications described in the foregoing disclosure. For example, Server 2212 may correspond to a server for performing the processing described above in accordance with embodiments of this disclosure.

[0164] Server 2212 can run any operating system, including any of the above, and any commercially available server operating system. Server 109 can also run any of a variety of additional server applications and / or middle-tier applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, Java® servers, and database servers. 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, server 2212 may include one or more applications that analyze and integrate data feeds and / or event updates received from users of client computing devices 2202, 2204, 2206, and 2208. For example, the data feeds and / or event updates may include those from Twitter (registered trademark). Real-time updates include, but are not limited to, feeds, Facebook® updates, or real-time updates received from one or more third-party sources and continuous data streams. Real-time updates include real-time events related to sensor data applications, financial indicators, network performance measurement tools (e.g., network monitoring and traffic management applications), page transition (Clickstream) analysis tools, automotive traffic monitoring devices, etc. It is possible to do so. Furthermore, the server 2212 may also include one or more applications for displaying data feeds and / or real-time events via one or more display devices of client computing devices 2202, 2204, 2206, and 2208.

[0166] Furthermore, the distributed system 2200 may include one or more databases 2214 and 2216. These databases can provide a mechanism for storing information used by various embodiments, such as user ID information and other information. Databases 2214 and 2216 can reside in various locations. For example, one or more databases 2214 and 2216 may reside on non-temporary storage media near (and / in) server 2212. Alternatively, databases 2214 and 2216 may be remote from server 2212 and communicate with server 2212 via a network-based connection or a dedicated connection. In one embodiment, databases 2214 and 2216 may reside on a storage network (SAN). Similarly, any necessary files for performing functions that contribute to server 2212 may be stored on / away from server 2212, as needed. In one embodiment, databases 2214 and 2216 may include relational databases, such as a database provided by Oracle. These relational databases retrieve data according to SQL format instructions. It is configured to obtain, save, and update data.

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

[0168] It should be understood that the cloud infrastructure system 2302 shown in Figure 8 may include components other than those illustrated. Furthermore, the embodiment shown 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 those shown, may combine two or more components, or may have components in different configurations or arrangements.

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

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

[0171] In a particular embodiment, the services provided by the cloud infrastructure system 2302 may include a number of services that can be offered to users of the cloud infrastructure system as needed. In addition to services related to identity management, various other services may also be provided, including but not limited to online data storage and backup solutions, web-based email services, hosted office suite and document collaboration services, database processing, and managed technical support services. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of users.

[0172] In certain embodiments, a specific instantiation of a service provided by the cloud infrastructure system 2302 is referred to herein as a “service instance.” Generally, any service that can be provided to a user from a cloud service provider’s system via a communication 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 different from the customer’s on-premises servers and systems. For example, the cloud service provider’s system can provide applications, and users can order and use these applications via a communication network such as the Internet, as needed.

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

[0174] In certain embodiments, the cloud infrastructure system 2302 may include a set of applications, middleware, and database services that can be delivered to customers in a manner that is flexible, scalable, reliable, highly available, and secure, based on a self-service subscription. An example of such a cloud infrastructure system is the Oracle Public Cloud provided by the Assignee.

[0175] Furthermore, the cloud infrastructure system 2302 can provide computing and analytical services related to “big data.” The term “big data” generally refers to extremely large datasets. Analysts and researchers can use 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 can compute such data, present the data, or simulate external forces acting on the data or representations of the data. These datasets include structured data and / or unstructured data (e.g., emails, images, data blobs (binary large objects), web pages, complex event processing), such as data organized in databases or data organized according to other structured models. According to one embodiment, the cloud infrastructure system can better perform tasks on large datasets based on the needs of enterprises, government agencies, research institutions, individuals, groups of individuals or organizations, or other entities, by concentrating more (or fewer) computing resources for a purpose relatively quickly.

[0176] In various embodiments, the cloud infrastructure system 2302 can be configured to automatically provide, manage, and track services of the cloud infrastructure system 2302 requested by customers. Tem 2302 can provide cloud services through various deployment models. For example, the service can be provided in a public cloud model with a cloud infrastructure system 2302 owned by an organization that sells cloud services (e.g., owned by Oracle), and can be used by the general public or companies in different industries. As another example, the service can be provided in a private cloud model with a cloud infrastructure system 2302 dedicated to a single organization, and can be used by one or more entities within that organization. The cloud service may also be provided in a collective cloud model, in which case the cloud infrastructure system 2302 and the services provided by it are shared by multiple organizations within the relevant collective. The cloud service 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 under the categories of SaaS (Software as a Service) and PaaS (Platform as a Service). (a Service) category, IaaS (Infrastructure as a Service) category, or hive It may include one or more services provided in accordance with other categories of services, including Lid services. A customer can order one or more services provided by the cloud infrastructure system 2302 by submitting a subscription application. In response, the cloud infrastructure system 2302 processes the services included in the customer's subscription application.

[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 comply with the SaaS category. For example, the SaaS platform may function to build and deliver a suite of on-demand applications on an integration development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure to provide SaaS services. By using 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 for sales performance management, enterprise integration, and business flexibility for large organizations.

[0179] In some embodiments, platform services may be provided by the cloud infrastructure system 2302 via a PaaS platform. The PaaS platform may be configured to provide cloud services compliant with the PaaS category. Examples of platform services include, but are not limited to, providing organizations (e.g., Oracle) with the ability to integrate existing applications onto a shared common architecture and to build new applications that leverage the shared services provided by the platform. The PaaS platform can manage and control the underlying software and infrastructure to provide PaaS services. Customers can use the PaaS services provided by the cloud infrastructure system 2302 without having to purchase separate licenses and support. Examples of platform services include Oracle Java Cloud Services. This includes JCS, Oracle Database Cloud Services (DBCS), and others. Not limited to this.

[0180] By utilizing the services provided by the PaaS platform, customers can leverage the 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. This is possible. In one embodiment, a database cloud service can support a shared service deployment model that can give organizations the ability to store database resources and can provide DBaaS (Database as a Service) to customers as a cloud database. A middleware cloud service can provide customers with a platform for developing and deploying various business applications on a cloud infrastructure system, and a Java cloud service can provide customers with a platform for deploying Java applications on a cloud infrastructure system.

[0181] Various different infrastructure services may be provided to the cloud infrastructure system by an IaaS platform. These infrastructure services facilitate the management and control of underlying computing resources, such as storage, networking, and other basic computing resources, for customers using services provided by SaaS and PaaS platforms.

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

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

[0184] In certain embodiments, the cloud infrastructure system 2302 can provide services by sharing a plurality of internal shared services 2332 with different components or modules of the cloud infrastructure system 2302. These internal shared services include, but are not limited to, security and identification services, integration services, enterprise repository services, enterprise management services, virus scanning and whitelisting services, highly available backup and recovery services, services that enable cloud support, email services, notification services, and file transfer services.

[0185] In certain embodiments, the cloud infrastructure system 2302 includes cloud services within the cloud infrastructure system (e.g., SaaS services, PaaS services). It can provide a function to comprehensively manage services and IaaS services. In one embodiment, the cloud management function may include the function to deliver, manage, and track customer subscriptions received by a cloud infrastructure system 2302, etc.

[0186] In one embodiment, as shown in Figure 23, the cloud management function consists of one or more modules, for example, an order management module 2320, and an order management module. The system is provided by the order orchestration module 2322, the order provisioning module 2324, the order management and monitoring module 2326, and the identity management module 2328. These modules are provided by one or more computers. It may include, or be formed using, computers and / or servers. These computers and / or servers may be general-purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination thereof.

[0187] In an exemplary operation 2334, the customer can exchange information with the cloud infrastructure system 2302 by using a client device, for example, client devices 2304, 2306, or 2308, to request one or more services provided by the cloud infrastructure system 2302, and by ordering a subscription to one or more services provided by the cloud infrastructure system 2302. In certain embodiments, the customer can access a cloud user interface (UI), for example, cloud UI 2312, cloud UI 2323, and / or cloud UI 2316, and apply for a subscription through these UIs. The order information received by the cloud infrastructure system 2302 in response to the customer's order may include information identifying the customer and one or more services provided by the cloud infrastructure system 2302 that the customer intends to purchase.

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

[0189] In 2338, the order information is transferred 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 order confirmation and, after confirmation, order entry.

[0190] In 2340, information regarding the order may be transmitted to an order coordination module 2322 configured to prepare the delivery of the 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 supply module 1424. In certain embodiments, the order coordination module 2322 can manage the business processes associated with each order and determine whether or not to supply the order by applying business logic.

[0191] As shown in the embodiment in Figure 23, when 2342 receives a new subscription order, the order adjustment module 2322 requests to allocate resources and configure the resources necessary to fulfill the subscription order. The information is sent to the order supply module 2324. The order supply module 2324 can allocate resources for the services ordered by the customer. The order supply module 2324 forms an abstraction level between the cloud services provided by the cloud infrastructure system 2300 and the physical implementation layer used to supply resources to provide the requested services. In this way, the order coordination module 2322 can be isolated from implementation details such as whether services and resources are supplied on the spot or in advance, or allocated / given on request.

[0192] In 2344, after providing services and resources, a notification may be sent to the subscriber indicating that the requested services are available. In some cases, information (e.g., a link) that enables the customer to use the requested services may be sent to the customer.

[0193] In 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 about the use of services purchased by customers. These statistics may include, for example, storage usage, data transfer volume, number of users, system uptime, and system downtime.

[0194] In certain embodiments, the cloud infrastructure system 2300 may include an identity management module 2328. The identity management module 2328 can be configured to provide the cloud infrastructure system 2300 with identity services, such as access management and authorization services. In some embodiments, the identity management module 2328 can control information about customers who wish to use the services provided by the cloud infrastructure system 2302. Such information may include information that authorizes the customer's identity and information that describes the permissions granted to the customer for various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). The identity management module 2328 may include descriptive information about each customer, methods for accessing and modifying the descriptive information, and management of customers who access and modify the descriptive information.

[0195] Figure 24 shows an exemplary computing system 2400 that may be used to carry out embodiments of the present disclosure. In some embodiments, computing system 2400 can be used to implement any of the various servers and computing systems described above. As shown in Figure 24, computing system 2400 includes various subsystems, including a processing subsystem 2404 that communicates with a number of peripheral subsystems via a bus subsystem 2402. 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 system memory 2410.

[0196] The bus subsystem 2402 forms a mechanism for various components and subsystems of the computer system 2400 to communicate with each other as needed. While the bus subsystem 2402 is schematically shown as a single bus in the illustration, in alternative embodiments, the bus subsystem may utilize multiple buses. The bus subsystem 2402 may have one of several types of bus structures comprising a memory bus or memory controller, a peripheral bus, and a local bus using one of various bus architectures. For example, such an architecture could be an industry standard architecture (ISA) bus, a multi-bus, or a multi-bus. This may include Microchannel Architecture (MCA) buses, Extended ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses. These buses can be implemented as manufactured mezzanine buses compliant 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. A processing unit may include one or more processors, such as a single-core processor or a multi-core processor, a processor with one or more cores, or a combination thereof. In some embodiments, the processing subsystem 2404 may include one or more dedicated coprocessors, such as a graphics processor, a digital signal processor (DSP), etc. In some embodiments, some or all of the processing units of the processing subsystem 2404 may be implemented using specially designed circuits such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs).

[0198] In some embodiments, the processing unit of the processing subsystem 2404 can execute instructions stored in system memory 2410 or computer-readable storage medium 2422. In various embodiments, the processing unit can execute various program or code instructions and maintain programs or processes running simultaneously. Some or all of the program code running at any given time can reside in system memory 2410 and / or 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) according to usage patterns, as described above.

[0199] In certain embodiments, all processing performed by the computing system 2400 can be accelerated by providing a processing acceleration unit 2406 to perform specific processing or to offload a portion of 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. Generally, 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, pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include, for example, motion detection and / or gesture recognition devices such as Microsoft Kinect® motion sensors that allow a user to control and interact with the input devices, Microsoft Xbox® 360 game controllers, and devices for providing an interface for receiving input using gestures and voice commands. User interface input devices may also include eye gesture recognition devices such as Google Glass® blink detectors. The Google Glass blink detector detects the user's eye activity (e.g., blinking when taking a photo and / or selecting a menu) and converts the eye activity into input to an input device (e.g., Google Glass). Furthermore, the user interface input device may include a voice recognition detection device that enables interaction between the user and a voice recognition system (e.g., 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, gamepads, graphic 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 rangefinders, and eye-tracking devices. Furthermore, user interface input devices may also include medical imaging input devices such as computed tomography scanners, magnetic resonance imaging scanners, ultrasound imaging scanners, and medical ultrasound devices. Additionally, user interface input devices may include audio input devices such as MIDI keyboards and electronic musical instruments.

[0202] The user interface output device may include non-visual displays such as display subsystems, indicator lights, or audio output devices. The display subsystem may be, for example, a flat-panel display using a cathode ray tube (CRT), liquid crystal display (LCD), or plasma display, a projection device, or a touchscreen. Generally, when the term “output device” is used, it is intended to include all possible types of devices and mechanisms for outputting information from the computer system 2400 to a user or another computer. For example, the user interface output device includes, but is 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, audio 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 basic programming and data structures that provide functionality in several embodiments. Software (programs, code modules, instructions) that, when executed by the processing subsystem 2404, provides the aforementioned functionality may be stored in the storage subsystem 2418. This software may be executed by one or more processing units of the processing subsystem 2404. The storage subsystem 2418 can also provide a repository for storing data used according to various embodiments.

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

[0205] As an example, not an exhaustive one, as shown in Figure 24, the system memory 2410 can store application programs 2412, program data 2414, and the operating system 2416, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc. Example As such, Operating System 2416 is compatible with Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. Various versions of the 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 Operator This can include mobile operating systems such as ping systems.

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

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

[0208] In certain embodiments, the computing system 2400 can support the execution of one or more virtual machines. The computing system 2400 can run programs such as hypervisors to facilitate the configuration and management of virtual machines. Each virtual machine can be allocated memory, computing resources (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 run by other virtual machines executed by the computing system 2400. Thus, the computing system 2400 can run multiple operating systems simultaneously. Each virtual machine typically operates independently of the other virtual machines.

[0209] The communication subsystem 2424 forms an interface to other computing systems and networks. The communication subsystem 2424 functions as an interface for receiving data from other systems and transmitting data from the computer system 2400 to other systems. The communication subsystem 2424 provides an interface for computing... The system 2400 can establish a communication channel for sending and receiving information with one or more client devices, for example, via the Internet. For example, the account management system 112 shown in Figure 1 can use the communication subsystem 2424 to receive user login information, including input related to training words, from client devices. Furthermore, the communication subsystem 2424 can be used to send notifications regarding successful logins or notifications from the account management system to the user requesting password re-entry.

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

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

[0212] In certain embodiments, the communication 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 boundaryless event updates 2430 that do not have a clear conclusion. 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, and automotive traffic monitoring.

[0213] Furthermore, the communication subsystem 2424 may 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 can communicate with one or more streaming data source computers coupled to the computer system 2400.

[0214] The computer system 1500 may be one of various types, including handheld portable devices (e.g., iPhone® mobile phones, iPad® calculating tablets, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), personal computers, workstations, mainframes, kiosks, server racks, or other data processing systems.

[0215] Because computers and networks are constantly evolving, the description of computer system 2400 shown in Figure 24 is intended only as a specific example. Figure 2 Many other configurations are possible, having more or fewer components than the system shown in 4. For example, customized hardware may be used in hardware, firmware, software (including applets), or combinations thereof, and / or certain elements may be implemented. Furthermore, connections to other computing devices, such as network input / output devices, may be utilized. Based on the disclosures and teachings provided herein, those skilled in the art will understand other means and / or methods for realizing various embodiments.

[0216] While this embodiment has been described in detail, modifications within the spirit and scope of the embodiments described herein will be readily apparent to those skilled in the art. The various aspects, parts of various aspects, and various features of the various embodiments listed above and / or in the appended claims can be combined or replaced in whole or in part. As those skilled in the art will understand, embodiments that refer to other embodiments in the above description of various embodiments can be appropriately combined with other embodiments. Furthermore, those skilled in the art will understand that the above description is illustrative and not intended to limit the invention.

Claims

1. It is a system, One or more processors, The system comprises one or more processors and a memory coupled thereto, the memory storing a plurality of instructions executable by the one or more processors, and when the plurality of instructions are executed by the one or more processors, the one or more processors cause the processors to perform processing, and the processing is This involves monitoring the live information flow, including the data flow from source to destination, The process includes providing a user interface that includes multiple buckets, each bucket relating to a different threat level or action, each bucket being triggered in real time, displaying the total number of current action policies including the associated threat level or action, and the process further includes: The process includes determining the occurrence of a security event in the live information flow based on the trigger of an execution policy, the execution policy including the specification of the source, the destination, and the action to be taken, 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, the action to be taken is applied, and the process further includes A system that includes (i) identifying from the plurality of buckets a bucket associated with the threat level associated with the execution policy or the action taken by the execution policy, and (ii) updating the user interface by increasing the total number of current execution policies displayed in the identified buckets, which are triggered in real time by the associated threat level or action taken.

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

3. The aforementioned live information flow is part of multiple live information flows, The aforementioned multiple live information flows include (i) data flows from multiple sources to multiple destinations, and (ii) execution policies triggered by the data, The system according to claim 1 or 2, wherein the user interface further includes (i) a plurality of lines for connecting each source of the plurality of sources to the 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 aforementioned process is, Receiving user input corresponding to the selection of a specific bucket from the aforementioned multiple buckets, The system according to claim 3, further comprising displaying the plurality of live information flows, each including one or more sources and one or more destinations corresponding to the selected buckets.

5. The aforementioned process is, Receiving user input corresponding to the selection of a specific source or destination from the aforementioned multiple sources or multiple destinations, The system according to claim 3, further comprising displaying the live information flow that starts from a selected specific source and includes the one or more execution policies triggered by the data in the live information flow, or the live information flow that ends at a selected specific destination and includes the one or more execution policies triggered by the data in the live information flow.

6. The system according to claim 3, further comprising providing an indicator showing a higher source for a set of the multiple sources based on the amount of data flowing from the multiple sources to the multiple destinations.

7. The system according to any one of claims 1 to 6, wherein the process further includes updating a trend indicator for the identified bucket based on the occurrence of the security event, the trend indicator including displaying an upward arrow, a downward arrow, or a neutral symbol for the identified bucket.

8. It is a method, The data processing system monitors the live information flow, including the data flow from source to destination. The data processing system includes providing a user interface that includes multiple buckets, each bucket relating to a different threat level or action, each bucket being triggered in real time, and displaying the total number of current action policies including the associated threat level or action; the method further includes The data processing system includes determining the occurrence of a security event in the live information flow based on the trigger of an execution policy, the execution policy includes specifying the source, the destination, and the action to be taken, 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 action to be taken is applied, and the method further, A method comprising the data processing system updating the user interface to reflect the occurrence of the security event by (i) identifying from the plurality of buckets a bucket related to a threat level associated with the execution policy or the action taken by the execution policy, and (ii) increasing the total number of current execution policies displayed in the identified buckets, which are triggered in real time by the associated threat level or action.

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

10. The aforementioned live information flow is part of multiple live information flows, The aforementioned multiple live information flows include (i) data flows from multiple sources to multiple destinations, and (ii) execution policies triggered by the data, The method according to 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 the 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. The data processing system receives user input corresponding to the selection of a specific bucket from the plurality of buckets, The method according to claim 10, further comprising the data processing system displaying the plurality of live information flows, each including one or more sources and one or more destinations corresponding to the selected buckets.

12. The data processing system receives user input corresponding to the selection of a specific source or destination from the plurality of sources or the plurality of destinations, The method according to claim 10, further comprising the data processing system displaying the live information flow starting from a selected specific source, which includes one or more execution policies triggered by the data in the live information flow, or the live information flow ending at a selected specific destination, which includes one or more execution policies triggered by the data in the live information flow.

13. The method according to claim 10, further comprising providing an indicator that shows a set of higher sources based on the amount of data flowing from the plurality of sources to the plurality of destinations.

14. The method according to any one of claims 8 to 13, further comprising the data processing system updating a trend indicator for the identified bucket based on the occurrence of the security event, wherein the trend indicator includes displaying an upward arrow, a downward arrow, or a neutral symbol for the identified bucket.

15. A program for causing a computer to perform the procedure described in any one of claims 8 to 14.

Images