Dynamic policy injection and access visualization for threat detection
15 claims: 12 independent, 3 dependent
- 1システムであって、1つ以上のプロセッサおよび非一時的機械可読記憶媒体と、1つ以上のライブ情報フローを監視するためのプログラム命令とを含み、前記ライブ情報フローは、複数のソースから複数の宛先へのデータフローを含み、複数のバケットを含むユーザインターフェイスを提供するためのプログラム命令を含み、各バケットは、異なる実行措置に関連し、各バケットは、リアルタイムでトリガされ、前記関連する実行措置を含む現在の実行ポリシーの総数を表示し、実行ポリシーのトリガに基づいて、前記1つ以上のライブ情報フロー内のセキュリティイベントの発生を判断するためのプログラム命令を含み、前記実行ポリシーは、ソース、宛先、および実行措置の指定を含み、前記1つ以上のライブ情報フロー内の前記データが少なくとも前記実行ポリシーの前記ソースおよび前記宛先と一致する場合、前記実行ポリシーがトリガされ、前記実行措置が適用され、前記セキュリティイベントの発生を反映するように、(i)前記複数のバケットから、前記実行ポリシーによって適用された前記実行措置に関連するバケットを特定することおよび(ii)前記実行措置によってリアルタイムでトリガされ、前記特定されたバケットに表示されている現在の実行ポリシーの総数を増やすことによって、前記ユーザインターフェイスを更新するためのプログラム命令を含み、前記プログラム命令は、前記非一時的機械可読記憶媒体に格納され、前記1つ以上のプロセッサによって実行される、システム。
- 2前記セキュリティイベントの発生に基づいて、前記特定されたバケットのトレンドインジケータを更新するためのプログラム命令をさらに含み、前記トレンドインジケータを更新することは、前記特定されたバケットに上向き矢印を表示することを含む、請求項 1 に記載のシステム。
- 3前記実行ポリシーの総数を増やすことは、前記実行ポリシーの総数のカウント数nをカウント数n+1に増分することを含む、請求項 1または2 に記載のシステム。
- 4前記複数のバケットからバケットの選択に対応するユーザ入力を受け取るためのプログラム命令と、前記選択されたバケットに対応する前記複数のソースおよび前記複数の宛先を含む前記ライブ情報フローを前記ユーザインターフェイスに表示するためのプログラム命令とをさらに含む、請求項 1から3のいずれか1項 に記載のシステム。
- 5前記複数のソースをタグクラウドとして前記ユーザインターフェイスに表示するためのプログラム命令をさらに含み、前記タグクラウドは、各ソースの使用率に比例して、前記選択されたバケットに対応する前記複数のソースを示す、請求項 4 に記載のシステム。
- 6前記データに基づいて動的実行ポリシーを作成するための要求を受け取るためのプログラム命令を含み、前記動的実行ポリシーは、ソース、宛先、実行措置、および前記動的実行ポリシーがアクティブになる期間の指定を含み、複数のエージェントが前記動的実行ポリシーにアクセスできるように、前記動的実行ポリシーをポリシーバス上に公開するためのプログラム命令と、前記動的実行ポリシーに基づいて、前記1つ以上のライブ情報フロー内の別のセキュリティイベントに対して前記実行措置を実行するためのプログラム命令とを含み、前記複数のエージェントのうち少なくとも1つのエージェントは、前記実行措置を実行し、前記別のセキュリティイベントに対して前記実行措置の実行を反映するように、(i)前記複数のバケットから、前記実行ポリシーによって適用された前記実行措置に関連するバケットを特定することおよび(ii)前記実行措置によってリアルタイムでトリガされ、前記特定されたバケットに表示されている現在の実行ポリシーの総数を増やすことによって、前記ユーザインターフェイスを更新するためのプログラム命令をさらに含む、請求項 1から5のいずれか1項 に記載のシステム。
- 7前記動的実行ポリシーがアクティブになる前記期間中に、前記動的実行ポリシーは、前記動的実行ポリシーに含まれた前記ソースおよび前記宛先と同じ指定を含む静的実行ポリシーを上書きする、請求項 6 に記載のシステム。
- 8方法であって、コンピューティングシステムを用いて、1つ以上のライブ情報フローを監視するステップを含み、前記ライブ情報フローは、複数のソースから複数の宛先へのデータフローを含み、前記コンピューティングシステムを用いて、複数のバケットを含むユーザインターフェイスを提供するステップを含み、各バケットは、異なる実行措置に関連し、各バケットは、リアルタイムでトリガされ、前記関連する実行措置を含む現在の実行ポリシーの総数を表示し、前記コンピューティングシステムを用いて、実行ポリシーのトリガに基づいて、1つ以上のライブ情報フロー内のセキュリティイベントの発生を判断するステップを含み、前記実行ポリシーは、ソース、宛先、および実行措置の指定を含み、前記1つ以上のライブ情報フロー内の前記データが少なくとも前記実行ポリシーの前記ソースおよび前記宛先と一致する場合、前記実行ポリシーがトリガされ、前記実行措置が適用され、前記コンピューティングシステムを用いて、前記セキュリティイベントの発生を反映するように、(i)前記複数のバケットから、前記実行ポリシーによって適用された前記実行措置に関連するバケットを特定することおよび(ii)前記実行措置によってリアルタイムでトリガされ、前記特定されたバケットに表示されている現在の実行ポリシーの総数を増やすことによって、前記ユーザインターフェイスを更新するステップを含む、方法。
- 9前記コンピューティングシステムを用いて、前記複数のバケットからバケットの選択に対応するユーザ入力を受け取るステップと、前記選択されたバケットに対応する前記複数のソースおよび前記複数の宛先を含む前記ライブ情報フローを前記ユーザインターフェイスに表示するステップとをさらに含む、請求項 8 に記載の方法。
- 10前記コンピューティングシステムを用いて、前記複数のソースから特定のソースの選択に対応するユーザ入力を受け取るステップと、前記コンピューティングシステムを用いて、前記特定のソースから始まる前記ライブ情報フローを表示するステップとをさらに含む、請求項 9 に記載の方法。
- 11前記コンピューティングシステムを用いて、前記複数の宛先から特定の宛先の選択に対応するユーザ入力を受け取るステップと、前記コンピューティングシステムを用いて、前記特定の宛先で終わる前記ライブ情報フローを表示するステップとをさらに含む、請求項 9 に記載の方法。
- 12前記コンピューティングシステムを用いて、前記複数のソースおよび前記複数の宛先を含む前記ライブ情報フローを前記ユーザインターフェイスに表示するステップと、前記複数のソースから前記複数の宛先に流れるデータ量に基づいて、一組の上位ソースを示すインジケータを提供するステップとをさらに含む、請求項 8から11のいずれか1項 に記載の方法。
- 13前記コンピューティングシステムを用いて、前記複数のソースおよび前記複数の宛先を含む前記ライブ情報フローを前記ユーザインターフェイスに表示するステップと、前記複数のソースから前記複数の宛先に流れるデータ量に基づいて、一組の上位宛先を示すインジケータを提供するステップとをさらに含む、請求項 8から11のいずれか1項 に記載の方法。
- 14前記コンピューティングシステムを用いて、前記複数のソースおよび前記複数の宛先を含む前記ライブ情報フローを前記ユーザインターフェイスに表示するステップと、前記複数のソースから前記複数の宛先に流れるデータ量およびポリシーバス上に公開された一組のアクティブな実行ポリシーに基づいて、一組の上位実行ポリシーを示すインジケータを提供するステップとをさらに含む、請求項 8から11のいずれか1項 に記載の方法。
- 15請求項8から14のいずれか1項に記載の方法をコンピュータに実行させるためのプログラム。
Independent claims15
155 paragraphs, as filed
Cross-reference to related applications This application is filed on January 18, 2017 and entitled "Visualizing Access to Detect Threats," U.S. Provisional Application No. 62/447759 and filed on September 16, 2016. claims priority to and benefits from U.S. Provisional Application No. 62/396016, entitled "Access Visibility to Detect Threats," and the entire contents of these applications are incorporated by reference for all purposes. Incorporated herein.
Background This disclosure relates generally to threat detection, and more particularly to analyzing security events using dynamic policies, identifying active threats, user activities, and dynamic policies triggered by active threats and user activities. (e.g., systems, methods, computer program products for storing code or instructions executable by one or more processors).
Computer networks have become important tools for modern business. Large amounts of information are now stored on such networks and utilized by users all over the world. Information protection is necessary because most information is secret or sensitive to some degree. Not surprisingly, various network security monitoring devices have been developed to detect attempts by unauthorized persons and/or devices to access computer networks and information stored on computer networks.
Network security products mainly include intrusion detection systems (IDS), such intrusion detection systems may be network-based intrusion detection systems (NIDS), host-based intrusion detection systems (HIDS), etc. It's okay. Other network security products include firewalls, router logs, and various other event reporting devices. Depending on the size of the network, many companies have hundreds or thousands of these products deployed in their networks. Accordingly, network security personnel are burdened with responding to alarms representing possible security threats. Most companies do not have the resources or qualified personnel to individually respond to every alarm they receive.
Therefore, techniques are desired to provide threat visualization to analyze security events and present real-time data analysis in a manner that is easily understandable to end users.
<p>Overview When user activity is extremely high (billions of events per day), static security rules cannot address the threats emanating from vulnerable users, applications, and hosts, and a threat intelligence platform must be provided. . Some embodiments may provide real-time threat detection and analysis. Certain embodiments may provide visualization of user, application usage and performance. Some embodiments may utilize existing access controls to provide real-time execution. Certain embodiments may enforce compliance, block user access to unauthorized applications, perform adaptive authorization and user authentication based on policy, and perform content inspection for privacy and leakage prevention. I can do it. Certain embodiments may use rules and analytics to perform real-time implementation. Some embodiments can collect, monitor, and visualize large amounts of security data in real time (i.e., billions of events per day) and can take corresponding actions.</p><p>In particular, systems, methods, and computer-readable memories for controlling access to accessible resources in a distributed environment are disclosed. Access management and threat detection systems and information management configured to dynamically analyze security events, control access to accessible resources in a distributed environment, and display a unified view of active threats and user activity Certain techniques are disclosed for providing an identity management solution using the system. In various embodiments, systems and methods utilize the ability to create dynamic policies (including inspection policies and execution policies), the concept and potential of a policy bus for deploying and communicating dynamic policies to multiple execution entities. It relates to network architectures, including the ability of entities to dynamically respond to policies in different ways. For example, in various embodiments, dynamic access policies are prepared and enforced based on threat detection, real-time anomaly detection is based on real-time threat models, and dynamic event and data collection is based on inspection policy distribution. A method and system for dynamic access policy classification based on threat level is provided.</p><p>In various embodiments, a distributed environment includes a target system having one or more processors and a non-transitory machine-readable storage medium, a user device, a plurality of agents, a collection bus, a policy bus, and resources and data about a security event. A system is provided that includes program instructions for collecting. 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 transmitted from at least one agent of the plurality of agents by a collection bus. collected. The system further includes program instructions for creating a dynamic execution policy based on the data. A dynamic execution policy includes a specification of the source, destination, execution action, and period during which the dynamic execution policy is active. The system further includes program instructions for publishing the dynamic execution policy on the policy bus so that the dynamic execution policy can be accessed by multiple agents. During the period that the dynamic execution policy is active, the dynamic execution policy overrides the static execution policy, including source and destination specifications. Program instructions are stored on non-transitory machine-readable storage media and executed by one or more processors.</p><p>In some embodiments, the system further includes program instructions for performing enforcement actions on security events based on the dynamic enforcement policy. At least one agent of the plurality of agents performs the execution action.</p><p>In some embodiments, the time period is a predetermined period of at least 5 minutes, the dynamic execution policy becomes inactive and removed from the policy bus after the predetermined period ends, and the static execution policy A static execution policy that is inactive during a period of time becomes active after a predetermined period of time.</p><p>In some embodiments, the collection of data is triggered by an inspection policy published on a policy bus, where the inspection policy determines when a set of criteria for a security event matches a defined pattern. Contains rules for collecting data in real time that is a set of predefined attributes.</p><p>In some embodiments, the distributed environment further includes an analysis server and a machine learning component, and the inspection policy and the dynamic execution policy are created by the analysis server and the machine learning component.</p><p>In some embodiments, the system includes program instructions for creating an inspection policy based on historical data or specifications of a target system or resource, and a policy bus that allows multiple agents to access the inspection policy. and program instructions for publishing on.</p><p>In some embodiments, creating a dynamic execution policy includes classifying real-time collected data and historical data into one or more data clusters, and using the one or more data clusters to create a set of It includes analyzing the defined attributes and creating sources, destinations, execution actions, and periods during which the dynamic execution policy is active based on the analysis.</p><p>In some embodiments, the one or more data clusters are generated using supervised or unsupervised machine learning or clustering techniques, and the analysis includes centroids of the one or more data clusters down to a set of predefined attributes. and the action taken is determined based on the distance.</p><p>In various embodiments, a non-transitory machine-readable storage medium is provided that stores instructions. These instructions, when executed by the one or more processors, cause the one or more processors to perform a method that includes collecting data about a security event. The data includes (i) a source for identifying a user or user device, and (ii) a destination for identifying a target system or resource, and the data is collected by a collection bus from at least one agent of the plurality of agents. collected. The method further includes creating a dynamic execution policy based on the data. A dynamic execution policy includes a specification of the source, destination, execution action, and period during which the dynamic execution policy is active. The method further includes publishing the dynamic execution policy on a policy bus so that the dynamic execution policy can be accessed by multiple agents. The method further includes performing an enforcement action on the security event based on the dynamic enforcement policy, wherein at least one agent of the plurality of agents performs the enforcement action. During the period that the dynamic execution policy is active, the dynamic execution policy overrides the static execution policy, including source and destination specifications.</p><p>In some embodiments, the time period is a predetermined period of at least 5 minutes, the dynamic execution policy becomes inactive and removed from the policy bus after the predetermined period ends, and the static execution policy A static execution policy that is inactive during a period of time becomes active after a predetermined period of time.</p><p>In some embodiments, the collection of data is triggered by an inspection policy published on a policy bus, where the inspection policy determines when a set of criteria for a security event matches a defined pattern. Contains rules for collecting data in real time that is a set of predefined attributes.</p><p>In some embodiments, inspection policies and dynamic execution policies are created by an analysis server and a machine learning component.</p><p>In some embodiments, the method includes the steps of creating an inspection policy based on historical data or specifications of a target system or resource, and placing the inspection policy on a policy bus so that multiple agents can access the inspection policy. and publishing.</p><p>In some embodiments, creating a dynamic execution policy includes classifying real-time collected data and historical data into one or more data clusters, and using one or more data clusters to analyzing the set of defined attributes and creating a source, destination, execution action, and period during which the dynamic execution policy is active based on the analysis.</p><p>In some embodiments, the one or more data clusters are generated using supervised or unsupervised machine learning or clustering techniques, and the analysis includes centroids of the one or more data clusters down to a set of predefined attributes. and the action taken is determined based on the distance.</p><p>In various embodiments, a method is provided that includes collecting data regarding a security event 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 agent of the plurality of agents. be done. 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 the computer system. A dynamic execution policy includes a specification of the source, destination, execution action, and period during which the dynamic execution policy is active. The method further includes using the computing system to publish the dynamic execution policy on a policy bus so that the dynamic execution policy can be accessed by multiple agents. The method further includes using the computing system to perform an enforcement action on the security event based on the dynamic enforcement policy, wherein at least one agent of the plurality of agents performs the enforcement action. During the period that the dynamic execution policy is active, the dynamic execution policy overrides the static execution policy, including source and destination specifications.</p><p>In some embodiments, the time period is a predetermined period of at least 5 minutes, the dynamic execution policy becomes inactive and removed from the policy bus after the predetermined period ends, and the static execution policy A static execution policy that is inactive during a period of time becomes active after a predetermined period of time.</p><p>In some embodiments, the collection of data is triggered by an inspection policy published on a policy bus, where the inspection policy determines when a set of criteria for a security event matches a defined pattern. Contains rules for collecting data in real time that is a set of predefined attributes.</p><p>In some embodiments, a method includes using a computing system to create an inspection policy based on historical data or specifications of a target system or resource; and publishing the policy on a policy bus.</p><p>In some embodiments, creating a dynamic execution policy includes classifying real-time collected data and historical data into one or more data clusters, and using one or more data clusters to analyzing the set of defined attributes and creating a source, destination, execution action, and period during which the dynamic execution policy is active based on the analysis.</p><p>In various embodiments, systems and methods relate to providing a consolidated view of active threat categories, the number of policies triggered for each threat category, and associated trends. In certain embodiments, a system is provided that includes one or more processors, a non-transitory machine-readable storage medium, and program instructions for monitoring one or more live information flows. Live information flows include data flows from multiple sources to multiple destinations. The system further includes program instructions for providing a user interface that includes a plurality of buckets. Each bucket is associated with a different enforcement action, and each bucket is triggered in real time and displays the total number of current enforcement policies that include the associated enforcement action. The system further includes program instructions for determining the occurrence of a security event within the one or more live information flows based on the trigger of the execution policy. An execution policy includes the specification of a source, a destination, and an enforcement action, such that if the data in one or more live information flows matches at least the source and destination of the execution policy, the execution policy is triggered and the enforcement action is applied. Ru. The system reflects the occurrence of a security event by (i) identifying from multiple buckets the bucket associated with the enforcement action applied by the enforcement policy and (ii) triggering and identifying the enforcement action in real time by the enforcement action. The method further includes program instructions for updating the user interface by increasing the total number of current execution policies displayed in the displayed bucket. Program instructions are stored on non-transitory machine-readable storage media and executed by one or more processors.</p><p>In some embodiments, the system further includes program instructions for updating a trend indicator for the identified bucket based on the occurrence of a security event, wherein updating the trend indicator includes an upward trend indicator for the identified bucket. Including displaying arrows.</p><p>In some embodiments, increasing the total number of execution policies includes incrementing a count n of the total number of execution policies to a count n+1.</p><p>In some embodiments, a system includes program instructions for receiving user input corresponding to a bucket selection from a plurality of buckets and a live information flow including a plurality of sources and a plurality of destinations corresponding to the selected bucket. and program instructions for displaying on a user interface.</p><p>In some embodiments, the system further includes program instructions for displaying the plurality of sources as a tag cloud on a user interface. The tag cloud shows multiple sources corresponding to the selected bucket, proportional to each source's usage.</p><p>In some embodiments, the system further includes program instructions for receiving a request to create a dynamic execution policy based on the data. A dynamic execution policy includes a specification of the source, destination, execution action, and period during which the dynamic execution policy is active.</p><p>In some embodiments, the system further includes program instructions for publishing the dynamic execution policy on a policy bus so that the dynamic execution policy can be accessed by multiple agents. The system further includes program instructions for performing an enforcement action on another security event within the one or more live information flows based on the dynamic execution policy, wherein at least one agent of the plurality of agents , carry out enforcement actions. The system includes (i) identifying a bucket from the plurality of buckets that is associated with the enforcement action applied by the dynamic execution policy, and (ii) the enforcement action to reflect the execution of the enforcement action for another security event. further includes program instructions for updating the user interface by increasing the total number of current execution policies displayed in the identified bucket in real time.</p><p>In some embodiments, during the period that the dynamic execution policy is active, the dynamic execution policy overrides the static execution policy that contains the same source and destination specifications included in the dynamic execution policy.</p><p>In various embodiments, a non-transitory machine-readable storage medium is provided that stores instructions. These instructions, when executed by the one or more processors, cause the one or more processors to perform a method that includes monitoring one or more live information flows. Live information flows include data flows from multiple sources to multiple destinations. The method further includes providing a user interface that includes a plurality of buckets. Each bucket is associated with a different enforcement action, and each bucket is triggered in real time and displays the total number of current enforcement policies that include the associated enforcement action. The method further includes providing a user interface that includes a plurality of buckets. Each bucket is associated with a different enforcement action, and each bucket is triggered in real time and displays the total number of current enforcement policies that include the associated enforcement action. The method further includes determining an occurrence of a security event within the one or more live information flows based on the trigger of the execution policy. An execution policy includes the specification of a source, a destination, and an enforcement action, such that if the data in one or more live information flows matches at least the source and destination of the execution policy, the execution policy is triggered and the enforcement action is applied. Ru. The method includes (i) identifying, from a plurality of buckets, a bucket associated with an enforcement action applied by an enforcement policy and (ii) triggering and identifying a security event in real time to reflect the occurrence of a security event. The method further includes updating the user interface by increasing the total number of current execution policies displayed in the specified bucket.</p><p>In some embodiments, a method includes receiving user input corresponding to a bucket selection from a plurality of buckets, and providing a user interface with a live information flow including a plurality of sources and a plurality of destinations corresponding to the selected bucket. and displaying.</p><p>In some embodiments, the method further includes displaying the plurality of sources as a tag cloud on the user interface, the tag cloud including a plurality of sources corresponding to the selected bucket in proportion to the usage of each source. Indicate source.</p><p>In some embodiments, the method further includes receiving a request to create a dynamic execution policy based on the data. A dynamic execution policy includes a specification of the source, destination, execution action, and period during which the dynamic execution policy is active. The method further includes publishing the dynamic execution policy on a policy bus so that the dynamic execution policy can be accessed by multiple agents. The method further includes performing an enforcement action on another security event in the one or more live information flows based on the dynamic execution policy, wherein at least one agent of the plurality of agents performs an enforcement action on another security event in the one or more live information flows. Execute. The method includes (i) identifying a bucket from a plurality of buckets that is associated with an enforcement action applied by an enforcement policy, and (ii) executing a real-time action by the enforcement action to reflect the execution of the enforcement action for another security event. and updating the user interface by increasing the total number of current execution policies displayed in the identified bucket.</p><p>In some embodiments, during the period that the dynamic execution policy is active, the dynamic execution policy overrides the static execution policy that contains the same source and destination specifications included in the dynamic execution policy.</p><p>In some embodiments, the time period is a predetermined period of at least 5 minutes, the dynamic execution policy becomes inactive and removed from the policy bus after the predetermined period ends, and the static execution policy A static execution policy that is inactive during a period of time becomes active after a predetermined period of time.</p><p>In various embodiments, a method is provided that includes monitoring one or more live information flows using a computing system. Live information flows include data flows from multiple sources to multiple destinations. The method further includes using the computing system to provide a user interface that includes a plurality of buckets. Each bucket is associated with a different enforcement action, and each bucket is triggered in real time and displays the total number of current enforcement policies that include the associated enforcement action. The method further includes using the computing system to determine the occurrence of a security event within the one or more live information flows based on the trigger of the execution policy. An execution policy includes the specification of a source, a destination, and an enforcement action, such that if the data in one or more live information flows matches at least the source and destination of the execution policy, the execution policy is triggered and the enforcement action is applied. Ru. The method uses a computing system to (i) identify a bucket from a plurality of buckets that is associated with an enforcement action applied by an enforcement policy and (ii) determine the enforcement action to reflect the occurrence of a security event. and updating the user interface by increasing the total number of current execution policies displayed in the identified bucket in real time.</p><p>In some embodiments, the method includes, using a computing system, receiving user input corresponding to a selection of a bucket from a plurality of buckets, and a plurality of sources and a plurality of destinations corresponding to the selected bucket. displaying the live information flow on a user interface.</p><p>In some embodiments, a method includes, using a computing system, receiving user input corresponding to a selection of a particular source from a plurality of sources; and using the computing system to receive live information originating from the particular source. and displaying the flow.</p><p>In some embodiments, a method includes, using a computing system, receiving user input corresponding to a selection of a particular destination from a plurality of destinations; and using the computing system to receive live information terminating in the particular destination. and displaying the flow.</p><p>In some embodiments, a method includes using a computing system to display a live information flow including multiple sources and multiple destinations in a user interface; and providing an indicator of a set of top sources based on the set of top sources.</p><p>In some embodiments, a method includes using a computing system to display a live information flow including multiple sources and multiple destinations in a user interface; and providing an indicator of a set of top destinations based on the set of top destinations.</p><p>In some embodiments, a method includes using a computing system to display a live information flow including multiple sources and multiple destinations in a user interface; and providing an indicator of a set of higher-level execution policies based on the set of active execution policies published on the policy bus.</p><p>In various embodiments, systems and methods relate to providing a unified view of users, the applications being accessed by the users, and possible access policies associated with the access. In certain embodiments, a system is provided that includes one or more processors, a non-transitory machine-readable storage medium, and program instructions for monitoring live information flow. Live information flow includes data flow from a source to a destination. The system includes program instructions for providing a user interface that includes sources and destinations connected via a line, and program instructions for determining the occurrence of security events within a live information flow based on the triggering of an execution policy. further including. An execution policy includes the specification of a source, a destination, and an enforcement action, such that if the data in one or more live information flows matches at least the source and destination of the execution policy, the execution policy is triggered and the enforcement action is applied. Ru. The system allows the user to reflect the occurrence of a security event by (i) identifying an execution policy indicator, and (ii) displaying the circuits connecting sources and destinations that pass through the execution policy indicator. Further including program instructions for updating the interface. Program instructions are stored on non-transitory machine-readable storage media and executed by one or more processors.</p><p>In some embodiments, the source is displayed on one side of the window of the user interface, 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.</p><p>In some embodiments, the system further includes program instructions for monitoring one or more live information flows. A live information flow includes (i) a flow of data from multiple sources to multiple destinations, and (ii) one or more execution policies triggered by the data, and a user interface provides information for each of the multiple sources. one or more circuits for connecting the source to each destination of the plurality of corresponding destinations, and (ii) an indicator on each circuit indicating an enforcement policy triggered by data flowing between each source and each destination; include.</p><p>In some embodiments, the system includes program instructions for receiving user input corresponding to a selection of a particular source from a plurality of sources and one or more execution policies triggered by data in the live information flow. and program instructions for displaying live information flow originating from a particular source.</p><p>In some embodiments, the system includes program instructions for receiving user input corresponding to selection of a particular destination from a plurality of destinations and one or more execution policies triggered by data in the live information flow. and program instructions for displaying live information flows terminating at a particular destination.</p><p>In some embodiments, the system further includes program instructions for receiving a request to create a dynamic execution policy based on the data. A dynamic execution policy includes a specification of the source, destination, execution action, and period during which the dynamic execution policy is active. The system further includes program instructions for publishing the dynamic execution policy on the policy bus so that the dynamic execution policy can be accessed by multiple agents. The system further includes program instructions for performing an enforcement action on another security event within the one or more live information flows based on the dynamic execution policy, wherein at least one agent of the plurality of agents , carry out enforcement actions. The system (i) identifies an enforcement policy indicator and (ii) displays a circuit connecting a source and a destination that passes through the enforcement policy indicator to reflect the execution of an enforcement action in response to another security event. The method further includes program instructions for updating the user interface by updating the user interface.</p><p>In some embodiments, during the period that the dynamic execution policy is active, the dynamic execution policy overrides the static execution policy that contains the same source and destination specifications included in the dynamic execution policy.</p><p>In various embodiments, a non-transitory machine-readable storage medium is provided that stores instructions. These instructions, when executed by one or more processors, cause the one or more processors to perform a method that includes monitoring a live information flow. Live information flow includes data flow from a source to a destination. The method further includes providing a user interface that includes the source and destination connected via the line, and determining the occurrence of a security event within the live information flow based on the triggering of the execution policy. An execution policy includes the specification of a source, a destination, and an enforcement action, such that if the data in one or more live information flows matches at least the source and destination of the execution policy, the execution policy is triggered and the enforcement action is applied. Ru. The method allows users to reflect the occurrence of a security event by (i) identifying an execution policy indicator, and (ii) displaying circuits connecting sources and destinations that pass through the execution policy indicator. The method further includes updating the interface.</p><p>In some embodiments, the source is displayed on one side of the window of the user interface, 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.</p><p>In some embodiments, the method further includes monitoring one or more live information flows. A live information flow includes (i) a flow of data from multiple sources to multiple destinations, and (ii) one or more execution policies triggered by the data, and a user interface provides information for each of the multiple sources. one or more circuits for connecting the source to each destination of the plurality of corresponding destinations, and (ii) an indicator on each circuit indicating an enforcement policy triggered by data flowing between each source and each destination; include.</p><p>In some embodiments, the method includes receiving user input corresponding to a selection of a particular source from a plurality of sources and one or more execution policies triggered by data in the live information flow. displaying a live information flow starting at .</p><p>In some embodiments, the method includes receiving user input corresponding to a selection of a particular destination from a plurality of destinations, and selecting the particular destination including one or more execution policies triggered by data in the live information flow. and displaying a live information flow ending with.</p><p>In some embodiments, the method further includes receiving a request to create a dynamic execution policy based on the data. A dynamic execution policy includes a specification of the source, destination, execution action, and period during which the dynamic execution policy is active. The method further includes publishing the dynamic execution policy on a policy bus so that the dynamic execution policy can be accessed by multiple agents. The method further includes performing an enforcement action on another security event in the one or more live information flows based on the dynamic execution policy, wherein at least one agent of the plurality of agents performs an enforcement action on another security event in the one or more live information flows. Execute. The method includes (i) identifying an enforcement policy indicator and (ii) displaying a circuit connecting a source and a destination that passes through the enforcement policy indicator to reflect the execution of an enforcement action in response to another security event. The method further includes updating the user interface by updating the user interface.</p><p>In some embodiments, during the period that the dynamic execution policy is active, the dynamic execution policy overrides the static execution policy that contains the same source and destination specifications included in the dynamic execution policy.</p><p>In various embodiments, a method is provided that includes monitoring live information flow using a computing system. Live information flow includes data flow from a source to a destination. The method includes the steps of: using a computing system to provide a user interface including a source and a destination connected via a line; and determining whether a security event has occurred. An execution policy includes the specification of a source, a destination, and an enforcement action, such that if the data in one or more live information flows matches at least the source and destination of the execution policy, the execution policy is triggered and the enforcement action is applied. Ru. The method uses a computing system to (i) identify an execution policy indicator to reflect the occurrence of a security event; and (ii) identify a line connecting a source and a destination that passes through the execution policy indicator. The method further includes updating the user interface by displaying the user interface.</p><p>In some embodiments, the source is displayed on one side of the window of the user interface, 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.</p><p>In some embodiments, the method further includes monitoring one or more live information flows using the computing system. 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 is triggered by (i) one or more lines for connecting each source of the plurality of sources to each corresponding destination of the plurality of destinations, and (ii) data flowing between each source and each destination. further including an indicator on each line indicating the enforcement policy to be implemented.</p><p>In some embodiments, a method includes, using a computing system, receiving user input corresponding to a selection of a particular source from a plurality of sources; displaying a live information flow originating from a particular source including one or more triggered execution policies.</p><p>In some embodiments, a method includes, using a computing system, receiving user input corresponding to a selection of a particular destination from a plurality of destinations; displaying live information flows terminating in a particular destination including one or more triggered execution policies.</p><p>In some embodiments, the method further includes receiving, using the computing system, a request to create a dynamic execution policy based on the data. A dynamic execution policy includes a specification of the source, destination, execution action, and period during which the dynamic execution policy is active. The method further includes using the computing system to publish the dynamic execution policy on a policy bus so that the dynamic execution policy can be accessed by multiple agents. The method further includes using the computing system to perform an enforcement action on another security event within the one or more live information flows based on the dynamic execution policy, the method further comprising: using the computing system to perform an enforcement action on another security event within the one or more live information flows, One agent performs the execution action. The method uses a computing system to (i) identify an execution policy indicator and (ii) identify sources and destinations passing through the execution policy indicator to reflect the execution of an enforcement action in response to another security event. and updating the user interface by displaying the line connecting the.</p>
<figref num="1">1 is a simplified block diagram illustrating a high-level threat intelligence platform, according to some embodiments. FIG.</figref><figref num="2">1 is a simplified block diagram illustrating the detailed architecture of an information management system, according to some embodiments. FIG.</figref><figref num="3">1 is a simplified block diagram illustrating some functional elements of a threat visualization system, according to some embodiments. FIG.</figref><figref num="4A">FIG. 3 illustrates a user interface (UI) for displaying active threat categories, according to some embodiments.</figref><figref num="4B">FIG. 3 illustrates a user interface (UI) for displaying active threat categories, according to some embodiments.</figref><figref num="5">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="6">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="7">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="8">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="9">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="10">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="11">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="12A">FIG. 3 illustrates a UI for allowing an administrator to create one or more policies, according to some embodiments.</figref><figref num="12B">FIG. 3 illustrates a UI for allowing an administrator to create one or more policies, according to some embodiments.</figref><figref num="13">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="14">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="15">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="16">FIG. 4 illustrates additional UI for displaying active threat categories, according to some embodiments.</figref><figref num="17">FIG. 3 illustrates a UI for displaying active threats based on triggered policies, according to some embodiments.</figref><figref num="18">FIG. 3 illustrates a UI for displaying tracking activity of various sources, according to some embodiments.</figref><figref num="19">2 is a flowchart illustrating a process for publishing dynamic execution policies on a policy bus in a distributed environment, according to some embodiments.</figref><figref num="20">2 is a flowchart illustrating a process for providing a consolidated view of active threat categories, number of policies triggered for each threat category, and associated trends, according to some embodiments.</figref><figref num="21">2 is a flowchart illustrating a process for providing an integrated view of users, applications accessed by the users, and possible access policies associated with the access.</figref><figref num="22">1 is a simplified block diagram illustrating a distributed system that may be used to implement some embodiments of the present disclosure. FIG.</figref><figref num="23">1 is a simplified block diagram illustrating one or more components of a system environment in which services may be provided as cloud services, according to some embodiments. FIG.</figref><figref num="24">1 illustrates an example computer system that may be used to implement some embodiments of the present disclosure. FIG.</figref>
DETAILED DESCRIPTION I. Introduction The following disclosure describes a threat intelligence platform that can provide real-time threat detection and analysis. In various embodiments, a provided system includes a processor and memory that stores instructions. These instructions, when executed by the processor, cause the processor to receive a security event from the agent that includes at least a destination and a source, and to trigger the policy when the security event matches the policy. The policy includes the specification of sources, destinations, and enforcement actions, and the ability to perform enforcement actions on security events based on the policy and to link the sources and destinations of security events via triggered policies. and updating a user interface to link the link. However, in an entity (e.g., company, country), thousands or hundreds of thousands of employees and other individuals (e.g., users, advisors, guests) access various services (e.g., sources) through a network at any given time. This causes a security event. Monitoring is necessary because various access violations and password errors occur when people try to access a wide variety of services. Currently, static security rules within security policies cannot keep up with the ever-evolving threats to vulnerable users, vulnerable applications, and vulnerable hosts. When user activity is extremely high (eg, billions of events per day), manual or home-grown analysis using a user interface becomes prohibitively expensive. Also, with such a large number of users, it would be difficult to perform highly accurate automatic pattern detection and prevent unauthorized users from accessing the service.
To address these issues, various embodiments analyze security events using dynamic policies to identify active threats, user activities, and dynamic policies triggered by active threats and user activities. Provided are techniques (e.g., systems, methods, computer program products storing code or instructions executable by one or more processors) for displaying an integrated view that includes a computer program. By tracking user access and collecting information in real time, some embodiments can identify patterns, generate analysis, and take corresponding corrective actions. By collecting data in real time or near real time, corrective actions determined based on these data can be immediately applied. For example, when authenticating a user to an application, there may be a short amount of time (eg, milliseconds) to take steps to prevent unauthorized users from accessing the content. In additional or alternative embodiments, by collecting data in real-time or near real-time, storing a history of these data, and applying corrective actions determined based on real-time data and historical data, Even after authentication, unauthorized users can be prevented from gaining access and can be kicked out of the network.
Some embodiments may provide visibility into user identities, resource usage patterns, and performance characteristics. Certain embodiments may utilize certain access controls to provide real-time enforcement. For example, certain embodiments may be used to enforce compliance or block user access to unauthorized applications, perform adaptive authorization, authenticate users based on policy, and prevent privacy and leakage. content inspection can be performed. Certain embodiments may use dynamic rules and analysis to provide real-time execution. Some embodiments may provide threat visualization to present real-time data analysis in a manner that is easily understandable to end users. By summarizing large amounts of data and presenting analytical data in real time and in a meaningful way, end users can identify actionable items, ensure appropriate policy updates, and It can be executed reliably.
In one example, when a user enters a username and password into a login page and submits their user credentials, these user credentials are transmitted to the data collection bus in real time or near real time. In some examples, data can be collected, sent and received in less than 1 second or 30 milliseconds, depending on tuning parameters (eg, whether the collection bus is located in the cloud). Except for network delays (e.g., if the agent is located on the host machine collecting the information and the data collection bus is located on another machine, e.g. in the cloud), the transfer of data occurs with little delay (i.e., near real-time). ) is carried out. However, when a user enters credentials, the system must determine whether these credentials come from a particular server and present additional authentication to the user in case of suspicious activity. It is possible to determine whether it is present or not. If a user is accessing a page and the system determines that the user should not be authorized, even if the credentials are valid, the system can kick the user from accessing the page.
In some embodiments, after a user logs into an account, the web proxy can constantly monitor and learn about the user's activities and behaviors and can trigger an anomaly (thereby requiring the user to perform additional authentication). present). For example, a user attempts to transfer a large amount of funds. This action triggers the system to present additional authentication to the user. In certain embodiments, the proxy may provide another source of information (eg, traffic flows), and the collected data is provided and analyzed in real time. When a user accesses a protected application or a cloud application that is not protected by an agent, the proxy server can determine the user's activities, such as whether the user visits certain websites and downloads information. . The proxy server can monitor the user's activities and provide information that the user is blacklisted based on the collected data. Additionally, proxies can provide historical information. This allows historical information about a user to be taken into account when granting access to a user when the user accesses a new site.
Some embodiments can feed available real-time data to a real-time visualization server and present analysis results to customers in real-time. When providing data to customers in real time, actions can be quickly determined based on real-time analysis results. Some embodiments may store data and use stored or historical data to create 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 may use both historical data and analysis results obtained in real time to trigger anomalies. Advantageously, these techniques can collect, monitor, and visualize very large amounts of security data (i.e., billions of streaming events) in real time, and corresponding actions can be taken.
II. System Architecture for Detecting Threats FIG. 1 illustrates aspects of a system 100 for detecting threats in real-time by detecting anomalous access requests from users, in accordance with at least one embodiment of the present disclosure. ing. In some embodiments, system 100 includes an access management and threat detection system 105 and an information management system 110 communicatively coupled to user devices 115 via a network 120 in a distributed environment. Access management and threat detection system 105 and information management system 110 are part of the identity access manager. Various types of agents exist as part of an identity access manager, and these agents protect access to a web server or application. For example, when a user tries to access a mail server or document server, the server (for example, OAM (Oracle Access There is a protection agent that communicates with the Manager). This agent verifies whether the user can access this server, for example by verifying credentials associated with the ID. Particular embodiments may have an extension agent and an access manager server. Thus, when a user is requesting data, information about who is accessing something is sent in real time to the data collection engine of information management system 110.
Network 120 may facilitate communication and data exchange between user device 115, access management and threat detection system 105, and information management system 110. Network 120 may support data communications using any of a variety of commercially available protocols, including but not limited to TCP/IP, SNA, IPX, AppleTalk, etc., and any type known to those skilled in the art. network. By way of example only, network 115 may include an Ethernet network, a local area network (LAN) such as a token ring network, a wide area network, a virtual network including, but not limited to, a virtual private network (VPN), the Internet, an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., under the IEEE802.1X protocol suite, the Bluetooth® protocol known in the art, and/or any other wireless protocol) network) and/or a combination of these and other networks.
User equipment 110 may include a general purpose personal computer (e.g., including a personal computer and/or laptop computer running various versions of Microsoft Windows® and/or Apple Macintosh® operating systems), (e.g., Microsoft Windows A mobile phone or PDA (running software such as Mobile(R) and enabled for Internet, email, SMS, BlackBerry(R) or other communication protocols), (with various GNU/Linux(R) It may be a workstation computer, or other computing device, running a variety of commercially available UNIX or UNIX-like operating systems, including but not limited to ) operating systems. For example, user device 110 may be a thin client computer, an Internet-enabled gaming system, and/or other electronic device capable of communicating via a network (eg, network 115), such as a personal messaging device. Although the example system environment 100 is shown as comprising one user device, in other embodiments it may support any number of user devices and/or client computing devices.
Access management and threat detection system 105 may include one or more computers and/or servers. These computers and/or servers may include general purpose computers, dedicated server computers (including, by way of example, PC servers, UNIX servers, midrange servers, mainframe computers, rack mount servers), server farms, server clusters, or any other suitable configuration and/or combination. The computing devices that make up the access management and threat detection system 105 can run any operating system or various additional server applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, etc. Can run middle-tier applications. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®.
In various embodiments, access management and threat detection system 105 may include one or more elements operable to protect resources 125 provided by one or more target systems 130 of an organization. In some embodiments, "target system" may refer to any system that provides or includes one or more resources. Locally or remotely accessible resources 125 provided by target system 130 may include software products, applications (e.g., cloud applications, enterprise applications, or other applications), cloud services, various types of data (e.g., network files, may be of various types, including directory information, databases, etc.) and other resources. Target system 130 may include one or more databases, a Lightweight Directory Access Protocol (LDAP) server, an active directory (AD) system, an email system, a UNIX system, etc. For example, 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, target system 130 may be a computing system that provides access to a conference room, such as a computing system that provides access to a conference room using a badge. In some embodiments, target system 130 may be referred to as an application instance.
In certain embodiments, access to resources 125 provided by target system 130 may be managed using various types of accounts within target system 130. An account may be created on target system 130 based on resources 125 provided by target system 130. Accounts may include various types of accounts such as user accounts, administrative accounts, application accounts, etc. Each type of account grants a particular level of access to one or more resources 125 provided by target system 130. To enable users to access or log into target system 130, target system 130 may include respective accounts (eg, user accounts, administrative accounts, and/or application accounts). Accounts can be created or provisioned for a user or user group based on the user's or user group's (eg, organization's) identity. Users or user groups can be given specific types of accounts to access specific types of resources. For example, an email account on an Exchange server given to a user is an account for Exchange resources. A user can be given multiple accounts, each type of account corresponding to a different type of resource. For example, a user may have two different accounts to log into target system 130 and perform different types of operations. For example, target system 130 may host an email exchange server and provide email accounts. The same target system 130 may also host a human resources (HR) system and provide an HR administrative account for performing administrative functions related to the HR system. The particular user has an email account on the target system 130 and , may have an HR management account on the target system 130. If a user logs in with an email account, they can access their email. When logged in with an HR administrative account, the user can perform administrative tasks related to the management of organizational resources.
According to at least some embodiments, a user of user device 115 communicates with target system 130 by accessing a web-based request user interface (UI) on user device 115 to communicate with resource 125 (e.g., e-mail application). For example, the request UI may include a graphical user interface viewable via a client application (eg, a browser) on user device 115. When a user wants to access a resource on target system 130 or performs an operation on a resource on target system 130, access management and threat detection system 105 intercepts the access request from the user and Attempt to authenticate/authorize. For example, the access management and threat detection system 105 can obtain the user's credentials (eg, login ID and password) by providing the user with a login page. The access management and threat detection system 105 can then determine whether the user is an authorized user based on the user's login credentials. The access management and threat detection system 105 receives various events/actions (e.g., authentication (authN), authorization (authZ), policy validation, step-up authentication, SSO, may be configured to receive various types of access requests, such as web requests, SDK requests, and program requests, for performing token issuance (token issuance).
In various embodiments, the access management and threat detection system 105 includes one or more agents 135, one or more proxies 140 (e.g., forward or reverse proxies), one or more access managers 145, and/or one Includes one or more web gates 150. Access management and threat detection system 105 employs an agent-server model to enable communication between user device 115 and target system 130 (e.g., a distributed environment server) to provide access control functions for resource 125. The system 100 may be implemented according to the following. The agent-server model includes agent elements (e.g., one or more agents 135, also known as single sign-on agents or policy enforcement agents, one or more proxies 140, and/or one or more webgates 150). and server elements (eg, 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 act as a decision element for controlling access to resources 125, one or more agents 135, one or more proxies 140, and/or one or more Webgate 150 may be implemented or operated as an executive element for controlling access to resources 125. In some embodiments, one or more agents 135, one or more proxies 140, and/or one or more webgates 150 may be co-located with resource 125, as a plug-in to or part of resource 125. Often, one or more agents 135, one or more proxies 140, or one or more webgates 150 may be located independently of resource 125, such as running on a web server in front of resource 125. good. One or more access managers 145 may be deployed as part of the identity access manager
Access management and threat detection system 105 may provide SSO functionality within a distributed environment and may 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 web gates 150 may perform authentication of users operating user devices 115. I can do it. Authentication is the process by which a user determines that he or she is who he or she claims to be. To authenticate a user, the access management and threat detection system 105 may present a request to the user (eg, via the user's web browser) for authentication information in the form of a challenge. An execution policy (eg, an authentication policy) may specify the authentication method used to authenticate a user to be granted access to a given resource. These policies define how access to resources should be protected (eg, type of encryption, etc.). One or more access managers 145 may determine authorization of users to access resources 125. Authorization is the process of determining whether a user has access to a requested resource. An enforcement policy (eg, an authorization policy) may be defined to specify the conditions under which a user or group of users has access to a certain resource. For example, an administrator may authorize specific users within a group to have access to specific resources.
One or more agents 135 may be policy enforcement agents that act as filters for resource requests. One or more agents 135 intercept the resource request and determine whether the requested resource is protected by the access management and threat detection system 105 by applying static execution policies and dynamic execution policies. can do. If protected, the resource request may be forwarded to one or more access managers 145 to determine whether the user requesting the protected resource can access the protected resource. In certain embodiments, one or more WebGates 150, an innovative solution developed by Oracle, may be used as agents to filter resource requests. According to some embodiments, one or more agents 135 and one or more web gates 150 may be a hardware structure or a combination of hardware and software implementations.
One or more proxies 140 may be policy enforcement agents that act as filters for resource requests. For example, one or more proxies 140 may be authentication proxies for handling user authentication for resources. An authentication proxy can be called (eg, instantiated) by a web application or resource to provide authentication functionality. In some embodiments, an authentication proxy integrates one or more low-level authentication methods to allow programs that rely on authentication to be designed and written independently of the underlying authentication method. Can contain high-level APIs. One or more proxies 140 intercept the resource request and determine whether the requested resource is protected by the access management and threat detection system 105 by applying static execution policies and dynamic execution policies. can do. If protected, the resource request may be forwarded to one or more access managers 145 to determine whether the client requesting the protected resource can access the protected resource. An example of an authentication proxy is the Pluggable Authentication Module (PAM) used in Linux systems. According to some embodiments, one or more proxies 140 may be a hardware structure or a combination of hardware and software implementations.
One or more access managers 145 may have multiple elements for performing the authentication and/or authorization process. Additionally, one or more access managers 145 may include one or more authentication schemes. The authentication scheme may be configured to protect resources with one or more access policies (eg, static execution policies and dynamic execution policies as described herein). The authentication scheme may include details regarding the credential collection mechanism and the type of credential collection device used to collect the credential. For example, the collection of authentication information may be performed using an HTTP(S) transport channel for processing HTTP(S) requests from remote users. In certain embodiments, the authentication method includes a redirect URL (Uniform Resource URL) that is used to notify user device 115 of the success or failure of the authentication and/or authorization process. Locator: Uniform resource locator). Additionally, the authentication method can specify an authentication level representing a trust level for protecting the transfer of authentication information from the user device 115. For example, LDAP (Lightweight Directory Access Protocol) method is a second level authentication using LDAP authentication module to protect manager related resources such as URLs based on form authentication method. Good too. In forms authentication methods, an HTML form with one or more text input fields can be used to collect authentication information. In some embodiments, forms authentication may collect authentication information such as a username, password, social security number, date of birth, one-time password, or other common parameter combinations.
FIG. 1 illustrates a distributed environment implementing an access management and threat detection system 105 that includes one or more agents 135, one or more proxies 140, one or more access managers 145, and/or one or more webgates 150. Figure 3 further illustrates an example of a managed SSO session. For example, a user may operate user device 115 to request access to resources 125 controlled by target system 130. This request is routed or intercepted to one or more agents 135, one or more proxies 140, and/or one or more webgates 150 that control access to resources 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 be unprotected. In this case, one or more agents 135, one or more proxies 140, and/or one or more webgates 150 determine whether the requested resource is protected by querying one or more access managers 145. You can judge whether or not. One or more access managers 145 determine whether authentication is required to access resource 125 by checking execution policies associated with resource 125. If the requested resource is protected and requires authentication upon use, one or more access managers 145 may determine whether a session exists for the user. If it is determined that a session does not exist for the user, one or more access managers 145 forwards the user to the identity access manager's login service (eg, authentication service). The authentication service may request authentication information (eg, username/password, etc.) from the user. When the authentication service receives suitable credentials, it stores the received credentials in the user directory or
Based on the received user's proper credentials, one or more access managers 145 transfer the user back to one or more agents 135, one or more proxies 140, and/or one or more web gates 150. One or more agents 135, one or more proxies 140, and/or one or more web gates 150 can verify the authentication and establish a first session for the authenticated user. As a result, the user logs into the session on the target system 130 (eg, a distributed environment server). Once logged in, users can run different applications, use cloud storage, and use the resources you have granted them access to. When a user logs into target system 130, one or more access managers 145 may create a cookie to track the user's session activity. This cookie may include the time the user was active on the session. This cookie may be stored in information management system 110 as session activity data.
If the user is determined to be authenticated to the SSO session, one or more agents 135, one or more proxies 140, and/or one or more webgates 150 send an authorization query to one or more access managers 145. Process the original request for resource 125 by forwarding it. One or more access managers 145 determine whether the user's access to the resource 125 is authorized by checking the enforcement policy associated with the resource 125. One or more access managers 145 send permit or deny messages to one or more agents 135, one or more proxies 140, and/or one or more webgates 150 based on enforcement policies. If the one or more agents 135, the one or more proxies 140, and/or the one or more webgates 150 determine that the user is authorized to access the resource 125, the one or more agents 135, the one or more proxies 140, and/or the one or more webgates 150 access the resource 125 from the user device 115. Grant the request. This allows the user to access resources 125 on target system 130 from user device 115. If the one or more agents 135, the one or more proxies 140, and/or the one or more webgates 150 determine that the user is denied access to the resource 125, the one or more agents 135, the one or more proxies 140, and/or the one or more webgates 150 may deny the user access to the resource 125. The user device 115 is notified that the information is not present.
Information management system 110 may include one or more computers and/or servers. These computers and/or servers may include general purpose computers, dedicated server computers (including, by way of example, PC servers, UNIX servers, midrange servers, mainframe computers, rack mount servers), server farms, server clusters, or any other suitable configuration and/or combination. The computing devices comprising information management system 110 may run any operating system or various additional server and/or middle-tier applications, including HTTP servers, FTP servers, CGI servers, Java, database servers, etc. can be executed. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®. In various embodiments, information management system 110 supports access management and threat detection system 105 to protect and authorize user access to resources 125. Information management system 110 may be configured to obtain additional information related to the user's access request in order to authenticate/authorize the user's 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 that the request was sent. Information management system 110 is also configured to analyze this information and create and publish new policies (e.g., dynamic inspection and enforcement policies) to override static policies over a predetermined period of time. may be done. In some embodiments, available real-time data is visually presented to the customer as part of the system threat analysis results. When data is provided to customers in real-time, actions can be quickly determined based on real-time threat analysis results. Various embodiments can store data and use the stored data (ie, 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. In other embodiments, both historical data and analysis of information obtained in real time can be used to create dynamic inspection and enforcement policies.
Figure 2 shows an information management system 200 (see e.g., Figure 1) for collecting information of users accessing resources, publishing policies based on the results of analyzing the information, and visualizing the results of analyzing the information. This figure shows an aspect of the information management system 110) described above. In some embodiments, the information management system 200 connects the access management and threat detection system 215 (e.g., as described with reference to FIG. 2) via a network (i.e., the network 120 described with reference to FIG. includes a collection bus 205 and a policy bus 210 communicatively connected to an access management and threat detection system 105). Information management system 200 also includes an analysis server 220, machine learning component 225, visualization server 230, one or more agents 235, one or more proxies 240, communicatively connected to collection bus 205 and policy bus 210, One or more access managers 245, one or more webgates 250, and system memory 255 may further be included.
Collection bus 205 and policy bus 210 contain the network topology. In this network topology, 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, and/or one or more webgates 250. are connected to a common linear (or branch) link called a bus or enterprise service bus. Collection bus 205 and policy bus 210 implement a software architecture for performing distributed computing. Distributed computing can be used to route messages and data between various nodes, manage the placement of various policies (inspection and execution policies), provide services to facilitate the collection of data based on inspection policies, and listeners. (i.e. agents), including the publication of various policies (inspection policies and execution policies).
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 include general purpose computers, dedicated server computers (including, by way of example, PC servers, UNIX servers, midrange servers, mainframe computers, rack mount servers), server farms, server clusters, or any other suitable configuration and/or combination. The computing devices that make up analysis server 220, machine learning component 225, and visualization server 230 may be equipped with any operating system or various additional devices, including HTTP servers, FTP servers, CGI servers, Java, database servers, etc. May run server applications and/or middle tier applications. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®.
System memory 255 may include, for example, non-transitory machine-readable storage media such as flash memory, permanent memory such as read-only memory (ROM), semi-permanent memory such as random access memory (RAM), or other suitable types of non-transitory memory. It may be one or more storage media including a storage device, or any combination thereof. According to different aspects, memory 255 stores computer readable program instructions, data structures, program modules and other data related to the operation of system 200. According to certain aspects, memory 255 may store operating systems, application programs, policies, data information related to user activities and access requests, and program data in embodiments.
Once the system of Figure 2 is in place, one or more agents 235, one or more proxies 240, one or more access managers 245, and/or one or more The access management and threat detection system 105 (configured by WebGate 250) authenticates and/or authorizes end users' access to resources on target systems based on the rules in static execution policies and dynamic execution policies. It is possible to determine whether or not Rules can include destination (e.g., URL, host name, destination IP address or port of a target system or resource such as an application or service), source (e.g., user ID, user group designation, IP address of a client device), duration ( For example, the policy may include specifying a predetermined amount of time that the policy is in effect), and enforcement actions (eg, blocking access by a user, requiring authentication/authorization factors, monitoring activity). If network traffic or user activity patterns match the rules in the policy, the policy is triggered and enforcement actions are applied. Static execution policies and dynamic execution policies may be stored in memory 255 as static policy cache 265 and dynamic policy cache 270, respectively.
In certain embodiments, the general method is performed as follows. End users enter 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 has not yet been authenticated, one or more agents 235, one or more proxies 240, and/or one or more web gates 250 may cause the web server to issue a challenge to the browser for login information. request. The received login information is then returned to the web server and passed to one or more agents 235, one or more proxies 240, and/or one or more web gates 250. One or more agents 235, one or more proxies 240, and/or one or more webgates 250 send the authentication request to one or more access managers 245, and the one or more access managers 245 Determine whether the login information provided is genuine. One or more access managers 245 perform authentication using attributes of the user's ID information and resource authentication criteria stored in memory 255. If the login information provided by the user meets the authentication criteria, the process proceeds as follows; otherwise, the end user is notified that access to the requested resource is denied and the process ends. .
After authenticating the user, one or more agents 235, one or more proxies 240, and/or one or more webgates 250 determine whether the user is authorized to access the requested resource. access manager 245. Accordingly, one or more access managers 245 query information management system 200 for 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 identity information, the one or more agents 235, the one or more proxies 240, and/or the one or more Respond to WebGate 250 authorization queries. If the user is authorized, the user's access to the resource is allowed. Otherwise, the user's request is denied. Various alternatives to the flows described above are also within the spirit and scope of the invention.
Authentication and authorization decisions may be made based on policy domains and policies (eg, static and dynamic execution policies). A policy domain is a logical grouping that includes a web server's host ID, host name, URL prefix, and rules. Hostnames and URL prefixes are part of the course-grain portion of the web namespace protected by a particular policy domain. portion). Rules in a policy domain specify the conditions that allow or deny access to the requested resource, and the end users to whom these conditions apply. A policy domain consists of two levels of rules: a first level default rule and a second level rule included in the policy. A first-level default rule can be applied to any resource in a policy domain that is not associated with a policy, and a second-level rule can be applied to any resource in a policy domain that is associated with a policy. can do. Policies include URL patterns, resource types, operation types (such as request methods), and rules for restricting access to specific resources by user, static or dynamic group membership, time of day or day of the week, IP ( This group includes Internet Protocol (Internet Protocol) addresses. A policy can be a static or dynamic policy associated with a policy domain, and can be used to define the fine-grained portions of the web namespace that the policy protects. portion). In fact, the policy domain hostname and URL prefix are logically related to the policy URL pattern. The entire resulting pattern is compared with the received URL. If there is a match, it decides whether to grant or deny the request by evaluating various rules of the policy. If there is no match, the default policy domain rule is used.
Static and dynamic execution policies are statements that summarize attributes to express what is and is not allowed. Execution policies can use any type of attributes (user attributes, resource attributes, objects, actions, environment attributes, etc.) and include logic such as Boolean logic. In this case, the rules evaluate attributes and determine what is and is not allowed (e.g., whether the user making the request was authenticated or not, whether the user making the request was authorized to access the requested resource, etc.) includes a statement (for example, "IF, THEN") for determining whether the requesting user is authorized to make a request for the requested resource. For example, if the requestor is a manager, read/write access to sensitive data is granted. Static execution policies include default rules or rules that are written/rewritten (eg, created by an administrator of the system) over the life of the system to evaluate evolving system dynamics or attributes. However, rules contained within static policies are not written/rewritten in real time. This allows policies to evaluate evolving system dynamics or attributes in real time. Dynamic execution policies, on the other hand, include rules that are written/rewritten (e.g., created by machine learning techniques or administrators of the system) to evaluate evolving system dynamics or attributes in real time.
In various embodiments, systems and methods are provided for creating and executing static and dynamic policies based on threat detection. Static execution policies and dynamic execution policies may be executed by various agents (e.g., one or more agents 235, one or more proxies 240, and/or one or more webgates 250) along the execution path. It's okay. These policies may be understood as applying to each location of the agent in the execution path. In some embodiments, dynamic policies may be created manually by an administrator or automatically introduced into the system by machine learning component 225. Also, in certain embodiments, a period of execution (eg, a predetermined period) for the dynamic policy may be specified. For example, by setting a policy for a predetermined period of time (e.g., 5 minutes, 10 minutes, 4 hours, 1 day, 2 weeks, etc.), the analysis server 220 and/or administrator can , can monitor and trigger anomalies. After a predetermined period of time, the policy becomes invalid. Accordingly, some embodiments can monitor the behavior of a newly added system with dynamic policies and can ensure system stability. A monitored dynamic policy may be modified to be a solid or permanent (ie, not limited by a predetermined period of time) policy. Some embodiments use machine learning capabilities to create a dynamic policy during a predetermined period of time (e.g., the next 30 minutes) and ultimately configure the system with this dynamic policy. Permanently override static policies that have been created. Note that it is inefficient for a security administrator looking at a visualization application to quickly generate and deploy these policies into the system, regardless of whether a full approval process is required. , wasting resources.
In some embodiments, a sticky policy (ie, a static policy that cannot be overridden) may be created if the machine learning component 225 does not influence the policy. In other embodiments, machine learning component 225 can learn default policies or policies created by an administrator (e.g., static policies that can be overridden) and change these policies or create dynamic policies. You can override these policies using In certain embodiments, machine learning can modify default or static policies previously created by a system administrator based on additional data, and can override default or static policies. can. For example, anomalies can be classified into specific categories that correspond to blocking policies. This block 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 when the user takes some action, even if the user is in a valid session. In other embodiments, it may be specified not to create blocking policies (eg, policies that have logic configured to block a user or group of users from operations such as reading/writing to a resource). This allows administrators to monitor the types of policies triggered by machine learning. For example, during the first few months, an administrator might want to watch machine learning create multiple high alerts under certain circumstances or when there are certain patterns, validate these alerts, and monitor machine learning as a high-volume alert. Determine that you are not creating false positive alerts. Administrators can then adjust the policy and create a second factor authentication policy for a pattern rather than creating a high alert for that pattern.
In one example, a user accesses a server (e.g., a target system) from home or another location from 7:00 a.m. to 9:00 a.m. every day, and from a workplace or headquarters from 10:00 a.m. to 4:00 p.m. every day. Sometimes. If a user moves to another location and attempts to access the server, the system is configured with an abnormal default policy or a static policy that triggers second-factor authentication when location data does not match historical data. Therefore, the analysis server 220 determines that the access is abnormal and triggers second factor authentication. After a certain amount of time, the system learns and adapts from the default or static policy and decides based on the user's behavioral patterns not to trigger an anomaly when the user is moving from one location to another. can do. The system can also identify behavioral patterns of users. The system can intelligently determine whether an anomaly should be triggered based on historical data and updated real-time data. Machine learning component 225 can create and modify policies for managing end user identity information or behavioral models and behaviors by constantly learning from historical and real-time data. These identity information and policies are updated in real time rather than weekly or biweekly. This allows all historical and real-time data of user activity to be taken into account for subsequent anomaly detection. Therefore, what can be identified as an abnormality can be quickly taken into consideration in the next judgment. Thus, in this example, the next time a user logs in while in this geographic location, the activity on the system will not trigger an anomaly detection because the new location has been updated in memory 255. In effect, a new dynamic policy has been created that overwrites the previous policy.
Figure 2 further illustrates the mechanisms for performing event/data collection. In some embodiments, when machine learning has more processing data, machine learning component 225 can generate more execution policies and can find more and more complex patterns. In certain embodiments, event/data collection is dynamic and an inspection policy mechanism can facilitate data collection. The collected data can be fed to machine learning. This allows more execution policies to be created and anomalies triggered by the execution policies to be triggered. For example, when installing a new application, the system (either automatically via collection bus 205 and analysis server 220 or manually via an administrator) launches an inspection policy to determine how the application functions. be able to understand. The inspection policy can generate data by examining user activity on the application, taking into account the rules of the inspection policy. The collection bus 205, analytics server 220 and machine learning component 225 automatically classify the activity based on the collected data and classify the activity as low alert activity, medium alert activity or high alert activity based on patterns identified from the data. It is possible to judge whether it is an activity. Analysis server 220 and machine learning component 225 can then automatically generate dynamic inspection and execution policies based on the data collected by collection bus 205, and the generated policies are posted on policy bus 210. and can be used by agents for a given period of time to override static policies.
In certain embodiments, all data published within an enterprise (e.g., on the enterprise's network) can be collected in real time via collection bus 205 and may be used and analyzed by analysis server 220. . In some embodiments, analysis server 220 can perform event correlation, generate reports, and publish reports on report bus 275. Machine learning component 225 continuously receives information in real time from report bus 275 and provides information to the user interface via visualization server 230. Machine learning component 225 also uses real-time events and historical data from collection bus 205, memory 255, and report bus 275. Accordingly, machine learning component 225 can discover anomalies and publish policies (inspection policies or execution policies) to policy bus 210.
In conventional technology, an agent collects data, logs the data as log key data name/value pairs, and sends the log to a server periodically (e.g., every 5 or 10 minutes). It is composed of Transferring these logs can be expensive because agents are located in the cloud and servers may be located within or outside the enterprise. Furthermore, it takes time to accumulate logs and send them all at once. Instead of collecting and transmitting log key data name and value pairs, various embodiments transfer data from various agents to the collection bus 205 in real time using binary data so that the data is highly compressed. Forward. Certain embodiments transfer values and mechanisms to map data. For example, an agent can send a value to collection bus 205, and collection bus 205 can determine the format (eg, schema 1) sent by the agent. Once the format is specified, the value is translated. This is a method of compressing and efficiently transferring data.
In various embodiments, the system is based on data captured and transmitted by agents including one or more agents 235, one or more proxies 240, one or more access managers 245, and one or more web gates 250. can detect and trigger threats. A set of predefined attributes (e.g., user attributes, resource attributes, objects, actions, environment attributes, etc.) is not sufficient when agents need to support newer target systems, applications, and changes to existing application interfaces. There may be no. Therefore, with a dynamic inspection policy, the system requests the agent to collect/inspect additional information or attributes such as data in various payloads (e.g., HTTP) by sending dynamic rules to the agent. can do. This information is reported as part of a normal access request event. Machine learning component 225 can then detect anomalies in this new data or information and trigger more anomalies by inserting dynamic execution policies. As more anomalies are triggered, additional execution policies can be created to prevent specific types of traffic. This completes the collection, detection and execution cycle.
Collection bus 205 may be configured to obtain information related to security events, such as access requests from end users, and report that information or data to report bus 275. Collection bus 205 includes a default inspection policy or It may be configured based on a static inspection policy. In certain embodiments, inspection policies monitor data and notify administrators when certain criteria match predefined patterns. The inspection policy does not trigger an alert when the pattern is present, but it collects a set of predefined attributes when the pattern is present. For example, the system provides an inspection policy user interface that allows an administrator to specify a particular inspection policy that is triggered when a set of criteria is met (e.g., header data matches a threshold time period). (UI) can be provided. According to other aspects, collection may be configured based on a dynamic inspection policy that includes rules for collecting data or attributes. For example, collection bus 205 and analysis server 220 may work together to collect a set of predefined attributes and based on previously configured rules (default policy, static policy, or dynamic inspection and execution policy). Anomalies can be triggered. An inspection policy can specify a set of defined attributes to be collected and criteria for patterns in the data to be identified. After collecting attributes and patterns via collection bus 205, analysis server 220 examines the attributes and patterns in the data and determines whether these attributes and patterns match the rules defined in the execution policy. can be judged. Once the data enters collection bus 205, it is stored in memory 255 and becomes part of the historical data. The machine learning component 225 improves the performance of users on the system by constantly learning from historical and real-time data.
Information related to the event may include one or more agents 235 (described with reference to FIG. 1), one or more proxies 240, one or more access managers 245, and/or one or more webgates 250. It is collected from one or more agents and can include, for example, the IP address of the client that sent the request, device information, user information, the requested resource, and the time that the request was sent. In certain embodiments, information is further collected from third party agents, including GPS applications within the client device, weather applications, monitoring software, hardware sensors, load balancing software, and the like. Information may be collected asynchronously by collection bus 205. For example, collection bus 205 can include queues configured to process information, index information in real time, and perform data aggregation and query operations on information.
In some examples, collection bus 205 collects information about access requests received from users, such as client context, resource context, user context, server context, timestamp, session information, and a server instance for processing the request. May be configured to be organized into various categories. In various embodiments, collection bus 205 is configured to store information or data obtained and organized from user activities in information database 260 within memory 255.
FIG. 2 creates dynamic execution policies based on collected events/data and communicates them to agents (e.g., one or more agents 235, one or more proxies 240, one or more access 2 illustrates a mechanism for exposing dynamic execution policies to be executed by one or more agents (including a manager 245 and one or more webgates 250). In some embodiments, analysis server 220 and machine learning component 225 analyze real-time incoming data and historical data regarding access requests received from users or groups of users (e.g., stored in memory 255) over a period of time. is configured to create dynamic execution policies for users or user groups. In one embodiment, the analytics server 220 and the machine learning component 225 implement a dynamic execution policy for the user or user group by identifying parameter subsets associated with real-time incoming data and historical data of access requests by the user or user group. and analyzing real-time incoming data and historical data of access requests against the parameter subset to create a dynamic execution policy. For example, the analytics server 220 and machine learning component 225 may determine which users or groups of users typically access one or more applications stored on the target system based on temporal parameters (e.g., time of day) over a period of time. The implementation policy may be configured to create enforcement policies by analyzing group access requests and monitoring user access times. If a user or group of users attempts to access one or more applications at times outside of normal time parameters, the execution policy may include rules that require second-factor authentication or that block the user or group of users. can.
In some embodiments, the subset of monitored parameters may be identified/defined by the resources on the target system that the user accesses (e.g., the target application), and the target application provides this information to the analysis server. You may. For example, a target application (eg, 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 set using the analytics server 220, and the machine learning component 225 identifies the user or user group by analyzing real-time incoming and historical data of access requests over a period of time against these parameters. Execution policies can be created for In certain embodiments, if no data has been collected that satisfies the monitored parameter subset, the analytics server 220 and machine learning component 225 may perform a may be configured to create a dynamic inspection policy that is triggered to obtain data that satisfies a parameter subset when
In certain embodiments, analysis server 220 and machine learning component 225 may be configured to generate multiple policies for a user or group of users. These policies may be generated by analyzing real-time incoming and historical data of access requests by users or groups of users against different sets of parameters associated with the access requests. For example, as described above, the analysis server 220 and the machine learning component 225 analyze the access requests of users or groups of users based on the times the users or groups of users typically access various applications stored on the target system. may be configured to generate time-dependent policies for a user or group of users by doing so. In another example, the analysis server 220 and the machine learning component 225 are configured to generate application access pattern policies for the user by analyzing the patterns in which the user accesses various applications stored on the target system. may be configured. The analysis server 220 and machine learning component 225 may be configured to generate policies for the user by obtaining characteristics of security threats, intrusions, and denial of service (DOS) attacks from the access requests.
In some embodiments, the analytics server 220 and machine learning component 225 generate policies by classifying real-time incoming data and historical data of access requests associated with a user or group of users into one or more data clusters. It may be configured as follows. In certain embodiments, analysis server 220 and machine learning component 225 are configured to generate one or more data clusters using supervised or unsupervised machine learning or other clustering (e.g., K-means) techniques. may be done. In various embodiments, machine learning component 225 may be configured to calculate the distance of the access request from the centroid of the cluster using a density-based clustering algorithm and unsupervised learning using Euclidean distance. In a particular example, the radius of a cluster is calculated based on the average distance from the centroid of each point in the cluster. Based on the standard deviation, points located outside the radius have a higher risk. The closer user activity on a corporate network is to the center of gravity, the lower the risk of access.
In certain examples, real-time incoming data and historical data of parameters configured by the analytics server 220, the machine learning component 225, and/or the integrated application (e.g., the application that the user attempts to access) is used to construct the cluster. It becomes a point. After building the clusters, analysis server 220 and machine learning component 225 may be configured to generate a policy that includes rules for one or more data clusters. For example, if certain parameters (x, y and z) of a request by a user or group of users do not match the parameters (x, y and z) of the cluster, perform an action, e.g. perform second factor authentication or Or you can build rules to block groups of users. As a result, when a new request is received from a user or user group, it is It can be determined whether the access request is abnormal or not.
In some embodiments, analysis server 220 and machine learning component 225 may be further configured to classify policies based on threat level after establishing clusters. The threat level may be determined based on the distance from the center of the cluster. As an example, a traffic pattern on a corporate network may have rules set to criteria, such as attributes that are used to generate policies according to the traffic pattern's distance from one or more clusters. If the distance is 1x (eg, 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 twice (eg, 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 three times (eg, more than three standard deviations from the mean), the policy is classified as blocking and the associated traffic pattern triggers blocking of the activity. Therefore, the customer does not have to worry about whether the traffic pattern is an unusual pattern. Instead, customers can focus on whether their traffic patterns created a low alert, medium alert, high alert, second factor authentication, or block.
As described herein, the policy may be generated by the analysis server 220 and the machine learning component 225 or by an administrator (who sees the anomaly occur). Some embodiments use STIX (Structured Threat Information eXpression). In various embodiments, once a policy (e.g., a new dynamic execution policy) is established or generated, it is published to the policy bus 210 and sent to the agents (e.g., one or more agents 235, one or more proxies 240, one or more access managers 245 and/or one or more web gates 250). When a policy is being executed by an agent, the agent becomes part of the execution ecosystem. For example, upon receiving a new access request from a user or group of users, one or more agents 235, one or more proxies 240, one or more access managers 245, and/or one or more webgates 250 execute configured to determine whether a user or user group's access request is abnormal by analyzing information related to the access request against a policy (default, static or dynamic policy); There is.
In some embodiments, one or more agents 235, one or more proxies 240, one or more access managers 245, and/or one or more web gates 250 are first exposed on policy bus 210. It may be configured to select a policy for a user or user group from a plurality of execution policies. In certain embodiments, policies may be specifically associated with users or user groups. The selection may be made, for example, based on the type of application to which the user or group of users is requesting access. For example, if a user or group of users 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 Webgate 250 may be configured to select from a plurality of policies a policy for analyzing a subset of parameters defined by the financial application. For example, as mentioned above, a financial application may want to analyze access requests from users or groups of users 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 have multiple executions exposed on policy bus 210 . It may be configured to obtain all of the policies and analyze access requests from users or user groups based on parameters from all or some of the policies.
After selecting or obtaining a particular policy, one or more agents 235, one or more proxies 240, one or more access managers 245, and/or one or more web gates 250 may perform the following operations against the particular policy: It may be configured to determine whether the user's access request is abnormal by analyzing information related to the access request. 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 are generated by analytics server 220 and machine learning component 225. The abnormal request may be determined by determining a deviation of the access request from one or more data clusters that have been accessed. 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 (eg, an administrator) or automatically by analysis server 220 and machine learning component 225. In certain embodiments, the threshold may be a Mahalanobis distance that takes into account the correlation of the data sets of the clusters.
Each agent can react uniquely to published policies to achieve the same end goal (e.g., not granting access to protected resources to unauthorized/unauthenticated users). In certain embodiments, once an anomaly is detected and a policy to block the user is created (e.g., in STIX format) and published to policy bus 210, one or more agents 235, one or more proxies 240, one or more access managers 245 and/or one or more web gates 250 can select or obtain such policies and determine their role in blocking users or user groups. For example, when a user or group of users is accessing an application, one or more access managers 245 send an entity to the entity for validating the user's credentials and authenticating the user to be part of an authentication session. The one or more agents 235, the one or more proxies 240, and/or the one or more webgates 250 may challenge and challenge the user at any time while the user is accessing resources in any part of the execution ecosystem. Sessions can be initiated, maintained, or terminated so that they can be authenticated. One or more proxies 240 can constantly monitor and learn about user or user group activities taking place and take action to trigger anomalies and block activities based on policy. For example, one or more proxies 240 may obtain information about a user who is blocked from a policy, and if one or more proxies 240 receives a session request from an IP address that corresponds to that user, one or more proxies 240 may obtain information about a blocked user from a policy. Creation can be blocked. Thus, even if the resource is not protected by other agents, one or more proxies 240 can take unique actions on user activity because they have the same policy as policy bus 210.
Additionally or alternatively, the one or more agents 235, the one or more access managers 245, and/or the one or more web gates 250 are activated by a user or group of users (e.g., when a user accesses a login page). Users are attempting to enter a username or password, a user is attempting to access a protected application, or they are attempting to access another website from an authorized session. Based on this, actions can be taken to trigger an anomaly and block the activity. For example, one or more agents 235 and/or one or more web gates 250 may check whether the session is still valid based on whether a period has expired. In some examples, a time session is valid for a predetermined period of time, eg, 1 hour or 8 hours. The user is asked to log in again when the session is invalidated. One or more agents 235 and/or one or more web gates 250 can use the policy to validate sessions and disconnect sessions when they become invalid. Also, more than one access manager 245 can obtain the same policy. Thus, the next time the same user attempts to log in using the correct username and password, one or more access managers 245 may deny the user access. Thus, even if a resource is not protected by one or more agents, e.g., one or more proxies 240, one or more agents 235, one or more access managers 245, and/or one or more webgates 250 , has the same policy as the policy bus 210, so it can take unique actions in response to user activities. Therefore, unlike traditional systems where agents react similarly as a group once rules are determined, each agent is
FIG. 2 further illustrates a mechanism for providing a user interface based on event/data collection and enforcement of static and dynamic policies for user activities. In various embodiments, a unified user interface 280 is provided from visualization server 230. In some embodiments, unified user interface 280 includes active threat categories, the number of policies triggered for each threat category, and associated trends. In other embodiments, unified user interface 280 includes the user, the source being accessed by the user, and possible policies related to such activity. In yet other embodiments, real-time statistics are displayed on the integrated user interface 280 at predetermined time intervals (e.g., 2 seconds, 4 seconds, 5 seconds, 30 seconds) and in different time frames, such as 5 minutes or 15 minutes. Published and displayed. This allows security administrators to take appropriate action against "real-time trends."
The unified user interface 280 may be presented to the security administrator when the security administrator logs into the system. Unified user interface 280 may present the top users generating network traffic and the sources these users are accessing. Real-time data collected from collection bus 205 may be provided to the system. The unified user interface 280 can present the frequency with which a user accessed different sources on the network over a certain period of time (eg, 5 minutes or 30 minutes). The unified user interface 280 may be constantly updated as new data comes in, to show, for example, "Current Time - 5 Minutes." It can also indicate the top active IP addresses. Some embodiments may show a correlation between highly active IP addresses and popular and high traffic sources (eg, URLs). Also, certain embodiments may mark the IP addresses of unidentified users (eg, using an asterisk).
Some embodiments may present client IP address-to-application mapping in addition to user-to-application mapping. Particular embodiments may indicate that many different sources can be accessed from a particular IP address, or vice versa, that all different users can access a particular URL. The unified user interface 280 presents end users (or client IP addresses) on one side and end sources on the other side. Also, some embodiments may use color to distinguish groups. Certain embodiments may also present information such as the number of times each application has been accessed. By selecting a particular user or client's IP address, some embodiments may present the number of times an application has been accessed from a particular user or client's IP address.
In some embodiments, an administrator can specify one or more comparison criteria and reference values via the unified user interface 280. In certain embodiments, an administrator can also, via the unified user interface 280, set desired alerts and alerts when one or more criteria and criteria values for an event match criteria and criteria values specified by the administrator. A warning period can be specified. For example, in some embodiments, management can provide corresponding alerts specified by the user.
III. Unified User Interface FIG. 3 is a block diagram illustrating some functional elements of a threat visualization system 300, in accordance with various embodiments. The illustrated system includes three tiers: presentation tier 305, application tier 310, and database tier 315. Presentation layer 305 includes multiple user interfaces (eg, graphical user interfaces (GUI)). Users (eg, customers or administrators) can monitor user activity on a company's network through multiple user interfaces to detect threats in real time. The multiple user interfaces include multiple UIs 320, 325, 330, and 335 (eg, unified user interface 280 described with reference to FIG. 2). In some embodiments, UIs 320, 325, 330, and 335 reside on one or more workstations. In other embodiments, UIs 320, 325, 330, and 335 reside on one or more personal computers. Typically, UIs 320, 325, 330 and 335 can exist on any computing system. Although four UIs are shown in FIG. 3, any number of UIs can be developed and provided according to the embodiments described in this specification.
UIs 320, 325, 330, and 335 connect to one or more application servers 340 and 345 in application layer 310 (e.g., analytics server 220, machine learning component 225, and visualization server 230 described with reference to FIG. 2). has been done. Application servers 340 and 345 perform operations that facilitate real-time assessment of security and threats on corporate infrastructure networks by exchanging and processing information between UIs 320, 325, 330, and 335 and the corporate 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 the distributed computing system, including compute servers or database servers, and can communicate with any UI in the presentation tier.
Application servers 340 and 345 are connected to a database management system 350 (eg, memory 255 described with reference to FIG. 2) within database tier 315. Database management system 350 may be any type of custom or commercially available database system that can manage data storage and retrieval. In some embodiments, database management system 350 includes a database server or the like. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®. Database management system 350 is connected to caches and databases 355 (eg, caches 265, 270 and database 260 described with reference to FIG. 2). Cache and database 355 may be any type of cache or database that can store and retrieve data. Examples of databases include, but are not limited to, hierarchical databases and relational databases.
In various embodiments, the presentation layer 305, application layer 310, and database layer 315 provide UIs 320, 325, 330, and 335 that include active threat categories, the number of policies triggered for each threat category, and associated trends. Work to provide. As shown in FIGS. 4A and 4B, some embodiments may provide an active threat integration UI 400 based on a threat level classification scheme. As described herein, execution policies (e.g., static policies and dynamic policies) are classified into block policies, step-up or second factor policies, high alert policies, medium alert policies, and low alert policies, respectively. can do. For example, the analysis server 220 and machine learning component 225 may dynamically create an "abnormal application access" policy, with a low warning, for example, if only one access is observed. However, based on other factors, the same policy can be implemented as a second factor policy to prevent access by unauthorized users. Application layer 310 uses such a policy enforcement action classification scheme to integrate various buckets corresponding to block 405, step-up or second factor 410, high alert 415, medium alert 420 and low alert 425. Dashboard 402 of UI 400 can be displayed. The threat level classification scheme for policy enforcement actions allows administrators to evaluate and promote policies from low to high levels and vice versa. Also, some embodiments may include a machine learning component 225 when evaluating a policy or determining whether the threat level of a policy is elevated or lowered. Additionally, by providing an active threat integration UI 400 based on threat level rather than policy name, security management groups can classify different types of threats and
Buckets 405, 410, 415, 420, and 425 may contain a total number "n" 430 of policies with corresponding classifications that are triggered by user activity on the corporate network at any given time. Buckets 405, 410, 415, 420, and 425 may further include trends associated with number "n" 430 of triggered policies for each classification. For example, markers 435 and graphics such as graphs 440 may be used to illustrate historical trends corresponding to a number "n" 430 of triggered policies. In some embodiments, if the number "n" 430 of triggered policies is increasing (e.g., n+1, 5, 10, 15, etc.), an upward arrow can be used to facilitate such trends. can be shown. In contrast, if the number 'n' 430 of triggered policies is decreasing (e.g. n-1, 5, 10, 15, etc.), such a trend can be easily indicated using a downward arrow. I can do it. If the number 'n' 430 of triggered policies is substantially similar (e.g. +/-5%, 10%, or 15%), it is easy to use circles to indicate such trends. can. In certain embodiments, buckets 405, 410, 415, 420, and 425 further include drop-down boxes 445 that allow an administrator to view triggered policies and users on the corporate network. You can further investigate the details regarding the activities being performed by (sources being accessed). In certain embodiments, the unified UI 400 further includes an additional bucket 450 to indicate the total number of policies "m" (all classification groups) being executed at any given time.
In accordance with various aspects described herein, user behavior on a corporate network can be monitored and one or more dynamic policies can be created for the users. In some embodiments, an administrator or machine learning component 225 can set execution policies for certain actions to trigger blocks, second factor authentication, low alerts, medium alerts, or high alerts. For example, the machine learning component 225 can determine from historical data, fluctuations or deviations in real-time data (e.g., a user typically accesses from home around 7:00 p.m. or 8:00 p.m., but today a user accesses from a different location). access) and create policies against this anomalous access. The policy can specify a warning level (eg, low, medium, or high warning), second factor authentication, or block for the access. Based on whether the user authenticates with the challenge presented via second factor authentication, the system can utilize historical data to modify the policy. If the user's further actions increase the warning level and the new policy designates the user's actions as high warning actions, unified user interface 400 may begin presenting the high warning actions via dashboard 402. If there were multiple high alerts (e.g. 10 or 20) for this user in a short period of time (e.g. last 10 seconds or last 20 seconds), there may be a problem, so the machine learning component 225 may alert the administrator via the unified user interface 400.
In some embodiments, the dashboard 402 displays information including top access activity, top users accessing sources, top IP addresses being used to access sources, and top sources being accessed. Various windows 455 may be included for display. Top or bottom may be defined as, for example, a threshold number of 5, 10, 15, 35, or 50 top or bottom. Alternatively, top or bottom may be defined as a threshold percentage, eg, top or bottom 5%, 10%, 15%, 35%, or 50%. Window 455 may display information using any graphical means. For example, top access activity may be displayed using a pictogram or diagram 460 showing lines connecting each user ID or IP address to the resource or target system being accessed. Additionally or alternatively, top users can be displayed using a proportional area chart, bubble chart or tag cloud 465 with printing changes such as font size or color. Additionally or alternatively, top IP addresses may be displayed using a proportional area chart, bubble chart or tag cloud 470 with printing changes such as font size or color. Additionally or alternatively, the application may be displayed using a proportional area chart, bubble chart or tag cloud 475 with printing changes such as font size or color.
In some embodiments, presentation layer 305, application layer 310, and database layer 315 may further operate to provide additional functionality or information to the administrator. For example, as shown in Figure 5, by positioning an input device, such as a mouse pointer, over a particular user 505 in a dashboard window 510, an administrator can view a single resource 515 accessed by that particular user. can do. Additionally, as shown in Figure 6, by placing an input device, such as a mouse pointer, over a particular URL 605 in a window 610 of the dashboard, an administrator can determine a specific count or number of accesses to a resource by a user or IP address. You can see 615 times. As shown in Figure 7, by placing an input device such as a mouse pointer over a particular URL 705 in a dashboard window 710, an administrator can see the various users 715 accessing that URL. . As shown in FIG. 8, an administrator can selectively monitor a particular user 805 by selecting the particular user 805 from a dashboard window 810 using an input device such as a mouse pointer. As shown in FIG. 9, an administrator can monitor the activities 905 of a particular user 910 using a proportional area chart 915 or a bubble chart. As shown in Figure 10, an administrator can see 1005 the number of times a particular user 1010 has accessed a URL 1015 in a proportional area chart 1020 or a bubble chart by placing an input device such as a mouse pointer over the URL. . As shown in FIG. 11, an administrator can monitor the activities of multiple users 1105 using multiple proportional area charts 1110 or bubble charts.
In some embodiments, the presentation layer 305, application layer 310, and database layer 315 are configured to provide an administrator with additional functionality for creating one or more policies (e.g., inspection policies or execution policies). Can operate further. 12A and 12B illustrate an example UI 1205 for allowing an administrator to create one or more policies, according to certain embodiments. In some embodiments, an administrator may create one or more policies using any of the UIs described herein after observing anomalous activity. The administrator can specify the source 1210 of the policy by specifying a user ID, IP address, or group, etc., or can specify any source by leaving source 1210 blank. The administrator can specify the policy destination 1215 using a host name, target system name or ID, IP address, resource name, etc., or specify any destination by leaving destination 1215 blank. be able to. The administrator can specify enforcement actions 1220 for the policy. Actions 1220 may include low alert, medium alert, high alert, second factor authentication, or block. Note that the threat level detected from anomalous activity can also be used to classify policies as low risk, medium risk, high risk, second factor authentication risk, or block risk. The administrator can specify a period or predetermined period of time 1225 for which the policy will be active. In some embodiments, time period 1225 can be 5, 15, 30, or 60 minutes. This allows an administrator to see the impact of a policy on network traffic during a predetermined period of time via any of the UIs described herein. Administrators can then revoke the policy if it does not have the intended effect or if the policy is no longer applicable to anomalous activity. or the active state of the policy can be extended by changing the period 1225. In certain embodiments, time period 1225 can be permanent. This allows administrators to permanently override static policies or change security strategies on corporate networks in real time.
In some embodiments, presentation layer 305, application layer 310, and database layer 315 may further operate to provide additional functionality or information to the administrator. Some embodiments may indicate to an administrator the number of a particular type of policy (eg, block policy) in a particular time interval. In certain embodiments, an administrator can view (eg, by selecting a UI element) the policy that caused a particular action or alert (eg, block). For example, as shown in FIG. 13, in accordance with certain embodiments, an administrator can name the top policies 1305 for each classification in window 1310 by selecting the corresponding mode 1315 (e.g., top block policy mode). You can see it. Also, in some embodiments, the administrator can view in window 1325 the top users 1320 who are associated with top policy 1305 and who have violated the policy multiple times. Top or bottom may be defined as, for example, a threshold number of 5, 10, 15, 35, or 50 top or bottom. Alternatively, top or bottom may be defined as a threshold percentage, eg, top or bottom 5%, 10%, 15%, 35%, or 50%. As shown in FIG. 14, according to some embodiments, an administrator can view enforcement actions (eg, blocks) taken based on resources 1405 and top policies 1305 in window 1410. These displays allow administrators to see the users, resources, IP addresses, and policies associated with the top policies that are triggered for each classification or detected threat level. In some embodiments, an administrator selects a particular user and displays the number of alerts caused by that particular user (e.g., 15 blocks caused by that user and 2 second factors) can be seen.
By presenting various types of information to the administrator, the administrator can take appropriate actions (eg, in response to different trends). The UI described herein shows an upward trend for a specific alert, so that when an administrator sees an upward trend in alerts, he or she can take appropriate action only in response to the upward trend. In some embodiments, administrators can see users/client IP addresses/sources accessing specific applications that are blocked by high alerts according to specific policies. When viewing policies, some attributes allow administrators to distinguish between manually deployed policies and machine learning policies. In some embodiments, an administrator can only edit manually created policies, not machine learning policies.
In various embodiments, administrators monitor low, medium, and high alerts and make recommendations that require remediation of the specific policy that caused the alert, e.g., high alerts need to be remediated for block policies. Provide recommendations. Other system administrators are notified of the recommended policy to change and can decide whether to upgrade the policy to a block policy. As shown in FIG. 15, in accordance with certain embodiments, an administrator may select the top policy for each classification (e.g., high alert) in window 1510 by selecting the corresponding mode 1515 (e.g., high alert policy mode). You can see 1505 names. As shown in FIG. 16, in accordance with some embodiments, an administrator can view actions taken (e.g., high alerts) based on resources 1605 and top policies 1505 in window 1610, and in window 1620. IP address 1615 and the action taken based on the top policy 1505 (e.g., high alert) can be seen.
In various embodiments, the presentation layer 305, application layer 310, and database layer 315 provide UIs 320, 325, 330, and 335 that include the user, the resource being accessed by the user, and possible policies related to the access activity. It works like this. As shown in FIG. 17, some embodiments may provide an integrated UI 1700 that indicates active threats based on triggered policies. For example, in certain embodiments, an administrator can view the policy that caused a particular action or alert (eg, block). As shown in Figure 17, the administrator identifies the source 1705 of the activity on the corporate network that is triggering the policy (e.g., user ID, group designation, IP address, client device ID, etc.), the triggered policy 1710 (e.g. , a static execution policy, and a dynamic execution policy), and a window 1705 showing the destination 1715 of the activity from the source 1705 (eg, the resource or service being accessed). These displays allow administrators to see the policies and resources triggered by each user. In some embodiments, an administrator can select a particular user and focus on policies triggered by that particular user (e.g., this user has 15 block policies and 2 (triggered a two-factor policy). As shown in Figure 18, the administrator has identified the various sources 1805, client IP address 1810, destination IP port 1815, destination hostname 1820, request URL 1825, each triggered policy 1830, and the policy taken for each policy 1830. You can see the tracking activity regarding policy classification 1840 which shows the action. In some embodiments, a search bar 1845 can be used to search for tracking activity.
IV. Processes and Operations for Utilizing Threat Intelligence Platforms Figures 19-21 illustrate how dynamic policies can be used to analyze security events and detect active threats, user activities and active threats in a distributed environment, according to some embodiments. presents a technique for providing a unified view that includes dynamic policies triggered by physical threats and user activities. Each embodiment may be described as a process illustrated as a flowchart, flowchart, data flow diagram, structural diagram, or block diagram. Although a flowchart describes the operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Also, the order of operations may be changed. A process ends when its operations are complete, but may include additional steps not included in the drawings. A process may correspond to a method, function, procedure, subroutine, subprogram, etc. If the process corresponds to a function, termination of the process may correspond to returning to the calling function or the main function.
The processes and/or operations illustrated in Figures 19-21 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processor cores) hardware, or a combination thereof. can do. The software may be stored in memory (eg, a memory device, non-transitory computer readable storage medium). The specific sequence of processing steps shown in FIGS. 19-21 is not intended to be limiting. Other sequences of steps may be performed according to alternative embodiments. For example, in alternative embodiments, the steps described above may be performed in a different order. Additionally, each step illustrated in FIGS. 19-21 may include multiple substeps that may be performed in various orders as appropriate for each step. Additionally, additional steps may be added or removed depending on the particular application. Those skilled in the art will recognize many variations, modifications and alternatives.
FIG. 19 is a flowchart 1900 illustrating a process for creating and publishing a dynamic policy, according to various embodiments. In some embodiments, the process depicted in flowchart 1900 may be implemented by access management and threat detection system 105 and information management system 110 shown in FIG. 1 and described with reference to FIG. 2. At step 1905, a distributed environment is provided or instantiated that includes a target system having a user device, multiple agents, a collection bus, a policy bus, and resources. In some embodiments, the distributed environment further includes an analysis server and a machine learning component, and the inspection policy and the dynamic execution policy are created by the analysis server and the machine learning component. In certain embodiments, the distributed environment further includes memory for storing inspection policies, dynamic execution policies, and historical data received from one or more information flows.
At optional step 1910, an inspection policy can be created based on historical data or target system or resource specifications. In some embodiments, data collection is triggered by inspection policies published on the policy bus. For example, the collection bus may be configured to obtain information related to security events, such as end user access requests, and report that information or data to the report bus. A collection bus is a default or static inspection policy that contains rules for collecting a set of predefined attributes (e.g., user attributes, resource attributes, objects, actions, environment attributes, etc.) when certain criteria are met. may be configured based on. In certain embodiments, the system can provide an inspection policy UI that allows an administrator to determine whether header data You can create an inspection policy by specifying a particular inspection policy that is triggered when 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, a collection bus and an 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). I can do it. The inspection policy includes rules for collecting data in real time that is a set of predetermined attributes about the security event when a set of criteria about the security event matches a predetermined pattern. After the data is collected by the collection bus, it is stored in memory and becomes part of the historical data. By constantly learning from historical and real-time data, the machine learning component creates and modifies inspection and execution policies to efficiently gather information needed for threat assessment of user activity on the system.
At optional step 1915, the inspection policy may be published on or introduced to the policy bus so that multiple agents can access the inspection policy. Publishing an inspection policy on the policy bus allows listeners (i.e. agents) to access the policy and execute it to collect a set of defined attributes based on previously configured rules. Facilitate data collection by enabling At step 1920, data regarding security events may be collected. In various embodiments, the data includes (i) a source to identify a user or user device, and (ii) a destination to identify a target system or resource. Data may be collected from at least one agent of the plurality of agents by the collection bus. In some embodiments, data is collected according to a default, static or dynamic inspection policy. For example, if the criteria for a live information flow, including a data flow from a source to a destination, matches a predefined pattern in a default, static, or dynamic inspection policy, the inspection policy is triggered and one or more agents Attributes of the flow (eg, source and destination) or security events that occur within the information flow can be collected. The collected attributes may then be sent to a collection bus in accordance with various aspects described herein for further processing.
At step 1925, a dynamic execution policy may be created based on the data. A dynamic execution policy includes at least a specification of a source, a destination, an execution action, and a period of time during which the dynamic execution policy is active. The time period may be a predetermined period of at least 5 minutes, at least 10 minutes, at least 30 minutes, or at least 1 hour, such as 10 minutes, 30 minutes, 1 hour, 5 hours, 1 day, or 3 days. During the period that the dynamic execution policy is active, the dynamic execution policy overrides the static execution policy that includes at least the same source and the same destination specifications. For example, a static execution policy specifies that whenever a user attempts to access a resource on a specified target system from an IP address that requires first-level authentication, a user or group of users from that IP address Default or active. A dynamic execution policy is published to a user or user group from the same IP address that requires second-factor authentication whenever that user attempts to access a resource on the same specified target system. may be done. A dynamic execution policy may have a duration of 5 hours. Therefore, if the static execution policy is inactive during a predetermined period (e.g., 5 hours), then during the predetermined period (e.g., 5 hours), the dynamic execution policy is active (e.g., second-factor authentication is performed for requests to access the target system). After a predetermined period of time (e.g., 5 hours), dynamic execution policies become inactive and removed from the policy bus, and static execution policies become active (e.g., from an IP address to a specific target system). (first-level authentication is performed for access requests).
In certain embodiments, the system can provide an execution policy UI that an administrator uses to determine when a set of attributes are met (e.g., a live information flow is the source of the policy). Dynamic execution policies can be created by specifying specific execution actions that are triggered when the In other embodiments, the analysis server and machine learning component create dynamic execution policies. Creating a dynamic execution policy consists of classifying real-time and historical data collected into one or more data clusters and using one or more data clusters to analyze a set of predefined attributes. and creating sources, destinations, execution actions, and periods during which the dynamic execution policy is active based on the analysis. One or more data clusters can be generated using supervised or unsupervised machine learning or clustering techniques, and analysis calculates the distance from the centroid of one or more data clusters to a set of predefined attributes. It can include doing. An enforcement action, such as block authentication or second factor authentication, may be determined based on the distance of the centroid of one or more data clusters to a set of defined attributes.
At step 1930, the dynamic execution policy may be published on a policy bus so that multiple agents can access the dynamic execution policy. Publishing dynamic enforcement policies on the policy bus allows listeners (i.e. agents) to access the policy and activate the policy's enforcement actions based on previously configured rules. For example, to facilitate the detection of threats on corporate networks. At step 1935, enforcement actions may be taken on the security event based on the dynamic enforcement policy. In some embodiments, at least one agent of the plurality of agents performs the enforcement action. Enforcement actions can be taken multiple times if it is determined that an attribute of the information flow (e.g., source and destination) or a security event that occurs within the information flow matches the attributes of the specified dynamic execution policy (e.g., source and destination). may be performed by at least one agent of the agents. It may then, for example, (i) block the user's access to the destination before the user's access is granted; (ii) disconnect the user from the destination; (iii) authenticate the user on the system. (iii) requiring second-factor authentication or authorization; and (iv) reporting a low, medium, or high alert. may be done.
FIG. 20 is a flowchart 2000 illustrating a process for providing a consolidated view of active threat categories, the number of policies triggered for each threat category, and associated trends. In some embodiments, the process depicted in flowchart 2000 may be implemented by access management and threat detection system 105 and information management system 110 shown in FIG. 1 and described with reference to FIG. 2. In step 2005, a distributed environment is provided or instantiated including a target system having a user device, a plurality of agents, a collection bus, a policy bus, and resources. In some embodiments, the distributed environment further includes an analysis server and a machine learning component, and the inspection policy and the dynamic execution policy are created by the analysis server and the machine learning component. In certain embodiments, the distributed environment further includes memory for storing inspection policies, dynamic execution policies, and historical data received from one or more information flows.
At step 2010, one or more live information flows may be monitored. Live information flows 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 (eg, inspection policies and enforcement policies). At step 2015, a user interface may be provided that includes multiple buckets. Each bucket may be associated with a different threat level or enforcement action, and each bucket includes an associated threat level or enforcement action and displays the total number of current enforcement policies that are being triggered in real time. As shown in Figure 4A, the buckets are essentially the same classification scheme (e.g., Block, Second Factor Authentication, Low Alert, It is a graphical silo categorized according to (medium warning, high warning, etc.). By providing a unified UI for active threats based on threat level or action bucket rather than policy name, security management groups can interpret threat levels differently based on classification, rather than interpreting threat levels based on policy name. can focus on different types of threats and measures.
At step 2020, determining the occurrence of a security event within the one or more live information flows based on the trigger of the execution policy. An execution policy can include specifying a source, a destination, and an enforcement action, such that if the data in one or more live information flows matches at least the source and destination of the execution policy, the execution policy is triggered and the enforcement action is taken. applies. In step 2025, (i) identifying a bucket from the plurality of buckets that is associated with the enforcement action applied by the enforcement policy, and (ii) determining a bucket that is triggered in real time by the enforcement action to reflect the occurrence of the security event. , the user interface may be updated by increasing the total number of current execution policies displayed in the identified bucket. In some embodiments, increasing the total number of execution policies includes incrementing a count n of the total number of execution policies to a count n+1. At optional step 230, a trend indicator indicating the identified bucket may be updated based on the occurrence of the security event. For example, updating a trend indicator may include displaying an up arrow, a down arrow, or a colorless circle within the identified bucket.
At optional step 2035, user input corresponding to a bucket selection from a plurality of buckets can be received. In some embodiments, in response to a selection, a live information flow including multiple sources and multiple destinations corresponding to the selected bucket may be displayed in the user interface. In other embodiments, upon selection, multiple sources corresponding to the selected bucket may be displayed in the user interface as a tag cloud. The tag cloud can show multiple sources corresponding to the selected bucket, proportional to the usage of each source.
At optional step 2040, user input corresponding to a particular source selection may be received from a plurality of sources. In some embodiments, depending on the selection, live information flows originating from a particular source are displayed. At optional step 2045, user input corresponding to a selection of a particular destination from a plurality of destinations can be received. In some embodiments, depending on the selection, live information flows terminating at a particular destination are displayed. At optional step 2050, a live information flow including multiple sources and multiple destinations may be displayed on a user interface. In some embodiments, an indicator may be provided that indicates a set of top sources based on the amount of data flowing from multiple sources to multiple destinations. At optional step 2055, a live information flow including multiple sources and multiple destinations may be displayed on a user interface. In some embodiments, an indicator may be provided that indicates a set of top destinations based on the amount of data flowing from multiple sources to multiple destinations. At optional step 2060, a live information flow including multiple sources and multiple destinations may be displayed on a user interface. In some embodiments, providing an indicator of a set of top execution policies based on the amount of data flowing from multiple sources to multiple destinations and a set of active execution policies published on a policy bus. I can do it.
At optional step 2065, a request to create a dynamic execution policy based on the data can be received. A dynamic execution policy may include a specification of a source, destination, execution action, and a period of time during which the dynamic execution policy is active. At optional step 2070, the dynamic execution policy can be published on a policy bus so that multiple agents can access the dynamic execution policy. As described herein, a period of time can be a predetermined period of at least 5 minutes, at least 10 minutes, at least 30 minutes, or at least 1 hour, such as 10 minutes, 30 minutes, 1 hour, 5 hours, 1 day, or 3 days. It may be a period. During the period that the dynamic execution policy is active, the dynamic execution policy overrides the static execution policy that includes at least the same source and the same destination specifications. At optional step 2075, enforcement action may be performed on another security event within the one or more live information flows based on the dynamic enforcement policy. At least one agent of the plurality of agents is capable of performing an execution action. In an optional step 2080, (i) identifying from the plurality of buckets a bucket associated with the enforcement action applied by the enforcement policy to reflect execution of the enforcement action for another security event; and (ii) The user interface can be updated by increasing the total number of current execution policies displayed in the identified bucket, triggered in real time by the execution action.
FIG. 21 is a flowchart 2100 illustrating a process for providing an integrated view of users, applications accessed by the users, and possible access policies associated with the access. In some embodiments, the process depicted in flowchart 2100 may be implemented by access management and threat detection system 105 and information management system 110 shown in FIG. 1 and described with reference to FIG. 2. In step 2105, a distributed environment is provided or instantiated that includes a target system having a user device, multiple agents, a collection bus, a policy bus, and resources. In some embodiments, the distributed environment further includes an analysis server and a machine learning component. 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.
At step 2110, live information flow may be monitored. Live information flow may include 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 (eg, inspection policies and enforcement policies). At optional step 2115, one or more live information flows may be monitored. For example, one or more additional live information flows can be monitored. Additional live information flows may include (i) data flows from multiple sources to multiple destinations, and (ii) one or more execution policies triggered by the data. At step 2120, a user interface may be provided that includes sources and destinations connected via the line. For example, as shown in FIG. 17, each source included in a live information flow may be connected via graphical lines to one or more destinations being accessed. Optionally, if additional live information flows are to be monitored, the user interface may include (i) one or more lines for connecting each source of the plurality of sources to each destination of the plurality of corresponding destinations, and (ii ) may further include an indicator on each line indicating an enforcement policy triggered by data flowing between each source and each destination.
At step 2125, the occurrence of a security event within the live information flow may be determined based on the execution policy trigger. An execution policy can include specifying a source, a destination, and an enforcement action, such that if the data in one or more live information flows matches at least the source and destination of the execution policy, the execution policy is triggered and the enforcement action is taken. applies. In step 2130, by (i) identifying an execution policy indicator and (ii) displaying circuits connecting the source and destination that pass through the execution policy indicator to reflect the occurrence of a security event; The user interface can be updated. In some embodiments, the source is displayed on one side of the window of the user interface, 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.
At optional step 2135, user input corresponding to a particular source selection may be received from a plurality of sources. In some embodiments, depending on the selection, a live information flow is displayed that originates from a particular source that includes one or more execution policies triggered by data in the live information flow. At optional step 2140, user input may be received corresponding to a selection of a particular destination from a plurality of destinations. In some embodiments, depending on the selection, live information flows terminating in a particular destination that include one or more execution policies triggered by data in the live information flow are displayed. At optional step 2145, a live information flow including multiple sources and multiple destinations may be displayed on the user interface. In some embodiments, an indicator may be provided that indicates a set of top sources based on the amount of data flowing from multiple sources to multiple destinations. At optional step 2150, a live information flow including multiple sources and multiple destinations may be displayed on a user interface. In some embodiments, an indicator may be provided that indicates a set of top destinations based on the amount of data flowing from multiple sources to multiple destinations. At optional step 2155, a live information flow including multiple sources and multiple destinations may be displayed on the user interface. In some embodiments, providing an indicator of a set of top execution policies based on the amount of data flowing from multiple sources to multiple destinations and a set of active execution policies published on a policy bus. I can do it.
At optional step 2160, a request to create a dynamic execution policy based on the data can be received. A dynamic execution policy may include a specification of a source, destination, execution action, and a period of time during which the dynamic execution policy is active. At optional step 2165, the dynamic execution policy may be published on the policy bus so that multiple agents can access the dynamic execution policy. As described herein, a period of time can be a predetermined period of at least 5 minutes, at least 10 minutes, at least 30 minutes, or at least 1 hour, such as 10 minutes, 30 minutes, 1 hour, 5 hours, 1 day, or 3 days. It may be a period. During the period in which the dynamic execution policy is active, the dynamic execution policy overrides the static execution policy, which includes at least the like source and like destination specifications. At an optional step 2170, enforcement action may be performed on another security event within the one or more live information flows based on the dynamic enforcement policy. At least one agent of the plurality of agents is capable of performing an execution action. In an optional step 2175, (i) identifying an indicator of the enforcement policy and (ii) connecting the source and destination passing through the indicator of the enforcement policy to reflect the execution of an enforcement action for another security event. The user interface can be updated by displaying the lines that are connected.
V. Computing Environment FIG. 22 is a simplified diagram illustrating a distributed system 2200 for implementing one embodiment of the present disclosure. In the illustrated embodiment, distributed system 2200 is configured to run and operate a client application, such as a web browser or a dedicated client (e.g., Oracle® Forms), over one or more networks 2210. one or more client computing devices 2202, 2204, 2206, and 2208. Server 2212 may be communicatively coupled to remote client computing devices 2202, 2204, 2206, and 2208 via network 2210.
In various embodiments, server 2212 may be configured to execute one or more services or software applications, such as applications for providing services and identity management services. In certain embodiments, server 2212 may provide other services and software applications may include non-virtual and virtual environments. In some embodiments, these services are provided to users of client computing devices 2202, 2204, 2206, and/or 2208 as web services or cloud services, or under a Software as a Service (SaaS) model. It's okay. Users operating client computing devices 2202, 2204, 2206, and/or 2208 utilize the services provided by these components by exchanging information with server 2212 using one or more client applications. be able to.
In the configuration shown in FIG. 22, 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. . A user operating a client computing device can use one or more client applications to take advantage of the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that a variety of different system configurations for distributed system 2200 are possible. Therefore, the embodiment shown in FIG. 22 is an example of a distributed system for implementing the system of the embodiment, and is not intended to be limiting.
Client computing devices 2202, 2204, 2206 and/or 2208 may include various types of computing systems. For example, the client device may run software such as Microsoft Windows Mobile(R), and/or iOS, Windows(R) Phone, Android(R), BlackBerry(R) 10 and Palm OS, etc.). Hand-held mobile devices (e.g., iPhone®, cell phone, iPad®, tablet, personal digital assistant (PDA) or wearable device (Google Glass®) that can run a variety of mobile operating systems) Trademark Head Mounted Display).The device may support a variety of applications, such as various Internet-related applications, email applications, Short Message Service (SMS) applications, and various other communication protocols. The client computing device may also include, by way of example, a Microsoft including general purpose personal computers, including personal computers and/or laptop computers running various versions of the Windows(R) operating system, the Apple Macintosh(R) operating system, and/or the Linux(R) operating system; good. The client computing device may be, for example, a workstation computer running a variety of commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU/Linux operating systems, such as Google Chrome OS. It may be. Client computing devices include thin client computers capable of communicating over network 2210, Internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without a Kinect® gesture input device), and/or personal messaging devices. It may also include other electronic equipment such as devices.
Although the distributed system 2200 of FIG. 22 is shown as having four client computing devices, it can support any number of client computing devices. Other devices, such as devices with sensors, can exchange information with server 2212.
Network 2210 of distributed system 2200 may be any of a variety of commercially available protocols including, but not limited to, TCP/IP (Transmission Control Protocol/Internet Protocol), SNA (System Network Architecture), IPX (Internet Packet Exchange), Apple Talk, etc. A network can be used to support data communications and can be any type of network familiar to those skilled in the art. By way of example only, network 2210 may include a local area network (LAN), an Ethernet-based network, a token ring, a wide area network, the Internet, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network ( PSTN), infrared networks, wireless networks (e.g. networks operating under the IEEE1002.11 protocol suite, Bluetooth® and/or any other wireless protocols) and/or combinations of these networks with other networks. can include.
Server 2212 may include one or more general purpose computers, dedicated server computers (including, by way of example, PC servers, UNIX servers, midrange servers, mainframe computers, rack mount servers), server farms, It may be comprised of a server cluster, or any other suitable configuration and/or combination. Server 2212 may include one or more virtual machines running a virtual operating system or other computing architecture including virtualization. One or more flexible pools of logical storage devices can be virtualized to maintain virtual storage for a server. The virtual network may be controlled by server 2212 using software defined networking. In various embodiments, server 2212 may be configured to execute one or more services or software applications described in the above disclosures. For example, server 2212 may correspond to a server for performing the processing described above in accordance with embodiments of the present disclosure.
Server 2212 can run an operating system, including any of those mentioned above, and any commercially available server operating system. The server 109 also supports various additional server applications and/or applications, including an HTTP (Hypertext Transfer Protocol) server, an FTP (File Transfer Protocol) server, a CGI (Common Gateway Interface) server, a Java server, a database server, etc. or run any of your middle-tier applications. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®.
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. By way of example, data feeds and/or event updates include, but are not limited to, Twitter feeds, Facebook updates, or real-time updates received from one or more third-party sources and continuous data streams. . Real-time updates may include real-time events related to sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), page transition (Clickstream) analysis tools, vehicle traffic monitoring equipment, etc. can. 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. .
Distributed system 2200 may also include one or more databases 2214 and 2216. These databases may provide a mechanism for storing information used by various embodiments, such as user ID information and other information. Databases 2214 and 2216 can reside in various locations. Illustratively, one or more databases 2214 and 2216 may reside on non-transitory storage near (and/or within) server 2212. Alternatively, databases 2214 and 2216 are remote from remote server 2212 and communicate with server 2212 via a network-based or dedicated connection. In one set of embodiments, databases 2214 and 2216 may reside on a storage area network (SAN). Similarly, any necessary files for performing the functions contributing to server 2212 may be stored on server 2212 and/or remote from server 2212, as desired. In one set of embodiments, databases 2214 and 2216 can include relational databases, such as those provided by Oracle, for example. These relational databases are configured to retrieve, store, and update data according to SQL format instructions.
In some embodiments, the identity management service described above may be provided as a service via a cloud environment. FIG. 23 is a simplified block diagram illustrating one or more components of a system environment 2300 that can provide services as a cloud service, according to one embodiment of the present disclosure. In the embodiment shown in FIG. 23, the system environment 2300 includes one or more client computing devices 2304, 2306, and 2308, with which users can perform Information can be exchanged with a cloud infrastructure system 2302 that provides cloud services including services for managing credentials. Cloud infrastructure system 2302 can include one or more computers and/or servers, which can include those described above with respect to server 2212.
It should be understood that the cloud infrastructure system 2302 illustrated in FIG. 8 may include components other than those illustrated. Furthermore, the embodiment illustrated in FIG. 8 is only one example of a cloud infrastructure system that may incorporate embodiments of the present invention. In some other embodiments, cloud infrastructure system 2302 may have more or fewer components than shown, may combine two or more components, or have components in a different configuration or arrangement. You may.
Client computing devices 2304, 2306 and 2308 are similar to devices 2202, 2204, 2206 and 2208 described above. Client computing devices 2304, 2306, and 2308 can be configured to run a client application, such as a web browser, a dedicated client application (eg, Oracle® Forms), or other applications. Users can utilize the services provided by cloud infrastructure system 2302 by exchanging information with cloud infrastructure system 2302 using these client applications. Although the example system environment 2300 is shown as having three client computing devices, it may support any number of client computing devices. Other devices, such as devices with sensors, can exchange information with cloud infrastructure system 2302.
Network 2310 can facilitate communication and exchange of data between clients 2304, 2306, and 2308 and cloud infrastructure system 2302. Each network can support data communications using any of a variety of commercially available protocols, including those described above with respect to network 710, and may be any type of network familiar to those skilled in the art.
In certain embodiments, the services provided by cloud infrastructure system 2302 may include many services that may be provided to users of the cloud infrastructure system, depending on demand. In addition to services related to identity management, these include, but are not limited to, online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, and managed technical support services. Various other services may also be provided. Services provided by cloud infrastructure systems can be dynamically expanded to meet user needs.
In certain embodiments, a particular instantiation of a service provided by 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, a cloud service provider's system can provide applications, and users can order and use the applications, if desired, over a communication network, such as the Internet.
In some examples, services within a computer network cloud infrastructure include protected computer network storage access, hosted databases, hosted web servers, software applications, or other services provided to users by cloud vendors. service, or other services known in the art. For example, the service may include password-protected access to remote storage on the cloud over the Internet. As another example, a service may include a relational database hosted on a web service and a scripting language middleware engine for private use by developers on the network. As another example, a service may include access to an email software application hosted on a cloud vendor's website.
In certain embodiments, cloud infrastructure system 2302 provides a set of application, middleware, and database services that can be provided to customers in a flexible, scalable, reliable, highly available, and secure manner based on self-service subscriptions. can include. An example of such a cloud infrastructure system is the Oracle Public Cloud provided by the Assignee.
Cloud infrastructure system 2302 can also provide "big data" related computation and analysis services. The term "big data" generally refers to extremely large data sets. Analysts and researchers can utilize stored big data to visualize large amounts of data, detect trends in the data, and/or interact with the data. Big data and related applications may be hosted and/or utilized by infrastructure systems at various levels and at various scales. Tens, hundreds or thousands of processors linked in parallel can present data or simulate external forces acting on the data or representations of the data by computing such data. I can do it. These datasets can be structured data, such as data organized in databases or data organized according to other structured models, and/or unstructured data (e.g., emails, images, data blobs (binary large objects), web pages, and complex event processing). In accordance with one embodiment, a cloud infrastructure system provides a cloud infrastructure system for businesses, government agencies, research institutions, individuals, individuals, or groups of organizations by focusing more (or fewer) computing resources on a purpose relatively quickly. , or other parties' demands, to better perform tasks on large datasets.
In various embodiments, cloud infrastructure system 2302 can be configured to automatically provide, manage, and track cloud infrastructure system 2302 services subscribed by customers. Cloud infrastructure system 2302 can provide cloud services through various deployment models. For example, the service may be provided in a public cloud model with a cloud infrastructure system 2302 owned by an organization selling cloud services (e.g., owned by Oracle) and available to the general public or businesses in different industries. I can do it. As another example, services may be provided in a private cloud model with a cloud infrastructure system 2302 dedicated to a single organization and available to one or more entities within the organization. Cloud services may also be provided in a collective cloud model. Thus, cloud infrastructure system 2302 and the services provided by cloud infrastructure system 2302 are shared by multiple organizations within a related collective. Further, cloud services may be provided in a hybrid cloud model consisting of a combination of two or more different models.
In some embodiments, the services provided by cloud infrastructure system 2302 include a Software as a Service (SaaS) category, a Platform as a Service (PaaS) category, an Infrastructure as a Service (IaaS) category, or a hybrid service. May include one or more services provided in accordance with other categories of services. A customer may order one or more services provided by cloud infrastructure system 2302 through a subscription application. In response, cloud infrastructure system 2302 takes steps to provide the services included in the customer's subscription application.
In some embodiments, services provided by 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 a cloud infrastructure system via a SaaS platform. A SaaS platform may be configured to provide cloud services that comply with the SaaS category. For example, a SaaS platform can function to build and deliver a suite of on-demand applications on an integrated development and deployment platform. A SaaS platform can manage and control the underlying software and infrastructure to provide SaaS services. By utilizing services provided by SaaS platforms, customers can utilize applications that run on cloud infrastructure systems. Customers can obtain application services without the need to purchase separate licenses and support. It can offer a variety of different SaaS services. Examples include, but are not limited to, sales performance management, enterprise integration, and services that provide solutions for business flexibility for large organizations.
In some embodiments, platform services may be provided by cloud infrastructure system 2302 via a PaaS platform. A PaaS platform may be configured to provide cloud services that comply with the PaaS category. Examples of platform services include providing organizations (e.g., Oracle) with the ability to integrate existing applications on a shared common architecture and the ability to build new applications that take advantage of the shared services provided by the platform. including but not limited to services. A PaaS platform can manage and control the underlying software and infrastructure to provide PaaS services. Customers can utilize Paas services provided by cloud infrastructure system 2302 without the need to purchase separate licenses and support. Examples of platform services are oracle including but not limited to Java Cloud Services (JCS), Oracle Database Cloud Services (DBCS), and others.
By utilizing the services provided by the PaaS platform, customers can take advantage of the programming languages and tools supported by the cloud infrastructure system and can control the services deployed. In some embodiments, platform services provided by a cloud infrastructure system may include database cloud services, middleware cloud services (eg, Oracle Fusion middleware services), and Java cloud services. In one embodiment, a database cloud service can support a shared services deployment model that can give organizations the ability to accumulate database resources, and can support a DBaaS (Database as a Service) can be provided to customers as a cloud database. Middleware cloud services can provide customers with a platform for developing and deploying various business applications on cloud infrastructure systems, and Java cloud services can provide customers with a platform for developing and deploying various business applications on cloud infrastructure systems. The platform can be provided to customers.
A variety of different infrastructure services may be provided to a 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 fundamental computing resources for customers utilizing services provided by SaaS and PaaS platforms. do.
In certain embodiments, 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, infrastructure resources 1430 include server resources, storage resources, and network resources that are pre-integrated and optimized to run services provided by PaaS and SaaS platforms and other resources. It may also include a combination of hardware.
In some embodiments, resources within cloud infrastructure system 2302 can be shared among multiple users and can be dynamically reallocated according to the demands of each. Also, resources can be allocated to users in different time zones. For example, the cloud infrastructure system 2302 may make resources of the cloud infrastructure system available to a first group of users in a first time period within a specified time period, and then make similar resources available to another group of users in a different time period. It can be redistributed to make maximum use of resources.
In certain embodiments, the provided multiple internal shared services 2332 may be shared by different components or modules of the cloud infrastructure system 2302 to allow the cloud infrastructure system 2302 to provide the services. These internally shared services include safety and identity services, integration services, enterprise repository services, enterprise management services, virus scanning and whitelisting services, high availability backup and recovery services, services that enable cloud support, email services, including, but not limited to, notification services, file transfer services, etc.
In certain embodiments, cloud infrastructure system 2302 can provide functionality to comprehensively manage cloud services (eg, SaaS services, PaaS services, and IaaS services) within the cloud infrastructure system. In one embodiment, cloud management functionality may include functionality to provide, manage, and track customer subscriptions received, such as by cloud infrastructure system 2302.
In one embodiment, as shown in FIG. 23, the cloud management functionality includes one or more modules, such as an order management module 2320, an order orchestration module 2322, and an order fulfillment module. provisioning module 2324, order management and monitoring module 2326, and identity management module 2328. These modules may include or be formed using one or more 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.
In example operation 2334, a customer uses a client device, e.g., client device 2304, 2306, or 2308, to request one or more services provided by cloud infrastructure system 2302, and Information can be exchanged with cloud infrastructure system 2302 by ordering a subscription to one or more of the provided services. In certain embodiments, a customer can access and subscribe to a cloud user interface (UI), e.g., cloud UI 2312, cloud UI 2323, and/or cloud UI 2316, through these UIs. Order information received by cloud infrastructure system 2302 in response to a customer's order includes information that identifies the customer and the one or more services provided by cloud infrastructure system 2302 that the customer seeks to purchase. I can do it.
At 2336, order information received from the customer may be stored in an order database 2318. If this order is a new order, you can create a new record for this order. In one embodiment, order database 2318 may be one of several databases operated by cloud infrastructure system 2318 or in conjunction with other system elements.
At 2338, the order information is transferred to order management module 2320. Order management module 2320 may be configured to perform billing and accounting functions related to orders, such as order confirmation and, after confirmation, order filling.
At 2340, information regarding the order may be communicated to an order reconciliation module 2322 configured to prepare the provision of the services and resources ordered by the customer. In some examples, order coordination module 2322 can use the services of order fulfillment module 1424 to arrange the provision of services and resources. In certain embodiments, the order adjustment module 2322 can manage business processes associated with each order and can apply business logic to determine whether to pay for the order. .
As shown in the embodiment shown in FIG. 23, at 2342, upon receiving an order for a new subscription, the order adjustment module 2322 allocates resources and configures the resources needed to fill the order for the subscription. , sends the request to order fulfillment module 2324 . Order fulfillment module 2324 can allocate resources for the services ordered by the customer. Order fulfillment module 2324 provides a level of abstraction between cloud services provided by cloud infrastructure system 2300 and the physical implementation layer used to supply the resources to provide the requested service. Form. In this way, the order coordination module 2322 can be isolated from implementation details such as, for example, whether services and resources are provisioned on the fly or in advance, allocated/provided on request, and the like.
At 2344, after provisioning the services and resources, a notification may be sent to the subscribed customer indicating that the requested services are available. In some examples, information (eg, a link) may be sent to the customer to enable the customer to use the requested service.
At 2346, order management and monitoring module 2326 can manage and track the customer's subscription orders. In some examples, the order management and monitoring module 2326 can be configured to collect service usage statistical data regarding the customer's use of purchased services. As statistical data, for example, storage usage, data transfer amount, number of users, system startup time, and system downtime may be collected.
In certain embodiments, cloud infrastructure system 2300 can include an identity management module 2328. Identity management module 2328 can be configured to provide identity services, such as access management and authorization services, to cloud infrastructure system 2300. In some embodiments, identity management module 2328 can control information about customers who wish to utilize services provided by cloud infrastructure system 2302. Such information includes information that authorizes the customer's identity and describes the customer's granted execution privileges for various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). can be included. The identity management module 2328 may include descriptive information about each customer, methods for accessing and modifying the descriptive information, and management over the customers who accessed and modified the descriptive information.
FIG. 24 depicts an example computing system 2400 that may be used to implement 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 FIG. 24, computing system 2400 includes various subsystems, including a processing subsystem 2404 that communicates with multiple peripheral subsystems via a bus subsystem 2402. Peripheral subsystems may include processing acceleration unit 2406, I/O subsystem 2408, storage subsystem 2418, and communications subsystem 2424. Storage subsystem 2418 may include tangible computer readable storage media 2422 and system memory 2410.
Bus subsystem 2402 provides a mechanism for allowing the various components and subsystems of computer system 2400 to communicate with each other as necessary. Although the bus subsystem 2402 is illustrated schematically as a single bus, in alternative embodiments the bus subsystem may utilize multiple buses. Bus subsystem 2402 may have any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus. May include buses. These buses can be implemented as mezzanine buses manufactured according to the IEEE P1386.1 standard.
Processing subsystem 2404 controls the operation of computing system 2400 and can 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, processing subsystem 2404 can include one or more special purpose coprocessors, such as a graphics processor, digital signal processor (DSP), etc. In some embodiments, some or all of the processing units of processing subsystem 2404 may be implemented using custom circuits such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs).
In some embodiments, processing units of processing subsystem 2404 can execute instructions stored in system memory 2410 or computer-readable storage medium 2422. In various embodiments, a processing unit may execute various program or code instructions and may maintain concurrently executing programs or processes. Some or all of the program code being executed at any time may reside in system memory 2410 and/or computer readable storage medium 2410, which may include one or more storage devices. With appropriate programming, processing subsystem 2404 can provide various functions for dynamically modifying documents (eg, web pages) in response to usage patterns, as described above.
In certain embodiments, processing is performed by computing system 2400 by providing processing acceleration unit 2406 to perform certain processing or offload a portion of the processing performed by processing subsystem 2404. All processes can be accelerated.
I/O subsystem 2408 may include devices and mechanisms for inputting information into computing system 2400 and/or outputting information from or through computing system 2400. I can do it. Generally, the term "input device" includes all possible devices and mechanisms for inputting information into computing system 2400. User interface input devices include, for example, keyboards, pointing devices such as mice or trackballs, touch pads or touch screens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, and voice command recognition systems. Audio input devices, microphones, and other types of input devices may also be included. The user interface input device may also include, for example, a motion sensing and/or gesture recognition device such as a Microsoft Kinect® motion sensor that allows a user to control and interact with the input device; An Xbox 360 game controller, an apparatus for providing an interface for receiving input using gestures and voice commands may be included. The user interface input device may also include an eye gesture recognition device, such as a Google Glass® blink detector. The Google Glass blink detector detects a user's eye activity (e.g., "blinks" when taking a photo and/or selecting a menu) and inputs the eye activity into an input device (e.g., Google Glass). Convert to Additionally, the user interface input device may include a voice recognition detection device that allows the user to interact with the voice recognition system (eg, Siri® Navigator) via voice commands.
Other examples of user interface input devices include three-dimensional (3D) mice, joysticks or pointing sticks, game pads, graphics tablets, audio/visual devices such as speakers, digital cameras, digital video cameras, portable media players, and web cameras. , image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser range finders, and eye tracking devices. Furthermore, the user interface input devices may include medical image input devices such as, for example, computed tomography devices, magnetic resonance imaging devices, ultrasound emission tomography devices, medical ultrasound devices, and the like. User interface input devices may also include, for example, audio input devices such as MIDI keyboards and electronic musical instruments.
User interface output devices 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 device, a projection device, or a touch screen using a cathode ray tube (CRT), liquid crystal display (LCD), or plasma display. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 2400 to a user or other computer. For example, user interface output devices include a variety of 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. including but not limited to.
Storage subsystem 2418 provides a repository or data store for storing information used by computing system 2400. Storage subsystem 2418 provides tangible computer-readable storage media for storing the basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by processing subsystem 2404, provide the functions described above may be stored in storage subsystem 2418. These software may be executed by one or more processing units of processing subsystem 2404. Storage subsystem 2418 can also provide a repository for storing data used in accordance with various aspects.
Storage subsystem 2418 may include one or more non-transitory memory devices, including volatile memory devices and non-volatile memory devices. As shown in FIG. 24, storage subsystem 2418 includes system memory 2410 and computer readable storage media 2422. System memory 2410 may include volatile main random access memory (RAM) for storing instructions and data during program execution, and nonvolatile read-only memory (ROM) or flash memory for storing fixed instructions. It can contain some memory. In some implementations, a basic input/output system (BIOS), containing the basic routines that help to transfer information between elements of computing system 2400, such as during start-up, may be typically stored in ROM. RAM typically contains data and/or program modules that are currently being manipulated and executed by processing subsystem 2404. In some implementations, system memory 2410 may include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM).
By way of example and not limitation, as shown in FIG. 24, system memory 2410 stores application programs 2412, program data 2414, and operating systems, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), and the like. System 2416 can be stored. By way of example, operating system 2416 may include various versions of the Microsoft Windows(R), Apple Macintosh(R) and/or Linux(R) operating systems, various commercially available UNIX(R) or UNIX-like operating systems. (including, but not limited to, various GNU/Linux operating systems, Google Chrome OS, etc.), and/or iOS, Windows Phones, Android OS, etc. , the BlackBerry® 10 OS and the Palm® OS operating systems.
Computer readable storage medium 2422 can store programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by processing subsystem 2404, provide the functions described above may be stored in storage subsystem 2418. As an example, computer readable storage medium 2422 can 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. . 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, etc. . The computer-readable storage medium 2422 also includes flash memory-based SSDs, enterprise flash drives, non-volatile memory-based solid-state drives (SSDs) such as solid-state ROM, volatile memory such as solid-state RAM, dynamic RAM, static RAM, etc. memory-based SSDs, 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 non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 2400.
In certain embodiments, storage subsystem 2400 can include a computer readable storage medium reader 2420 further connectable to computer readable storage medium 2422. Computer-readable storage medium 2422, along with or optionally in combination with system memory 2410, includes storage media for storing computer-readable information, as well as remote storage, local storage, and non-permanent storage. and/or removable storage devices.
In certain embodiments, computing system 2400 can support execution of one or more virtual machines. Computing system 2400 may execute programs, such as a hypervisor, to facilitate configuration and management of virtual machines. Each virtual machine can be assigned memory, compute (eg, 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 operating systems executed by other virtual machines executed by computing system 2400. Accordingly, computing system 2400 is capable of running multiple operating systems simultaneously. Each virtual machine typically operates independently of other virtual machines.
Communications subsystem 2424 forms an interface to other computing systems and networks. Communications subsystem 2424 serves as an interface for receiving data from and transmitting data from computer system 2400 to other systems. Communications subsystem 2424 allows computing system 2400 to establish communications channels for transmitting and receiving information to and from one or more client devices, eg, over the Internet. For example, the account management system 112 shown in FIG. 1 may use the communications subsystem 2424 to receive user login information from a client device that includes input related to training words. Additionally, communications subsystem 2424 may be used to send notifications regarding successful logins or password re-entering requests from the account management system to the user.
Communication subsystem 2424 may support both wired and/or wireless communication protocols. For example, in some embodiments, the communications subsystem 2424 provides wireless voice and/or data communication (e.g., using cellular technology, advanced data network technology, such as 3G, 4G, or EDGE (enhanced data rates for global evolution)). Radio Frequency (RF) transceiver elements, WiFi (IEEE 802.11 family of standards or other mobile communication technologies or any combination thereof), Global Positioning System (GPS) receiver elements, and/or others for accessing the network. It can contain elements of In some embodiments, communications subsystem 2424 can provide a wired network connection (eg, Ethernet) in addition to or instead of a wireless interface.
Communications subsystem 2424 can send and receive data in various formats. For example, in some embodiments, communications subsystem 2424 can receive input communications in the form of structured and/or unstructured data feeds 2426, event streams 2428, event updates 2430, and the like. For example, communications subsystem 2424 may receive data from users of social networks and/or other communications services, including web feeds, such as Twitter feeds, Facebook updates, and Rich Site Summary (RSS) feeds. It may be configured to receive (or send) feed 2426 in real-time and/or to receive (or send) real-time updates from one or more third party sources.
In certain embodiments, the communications subsystem 2424 provides data in the form of a continuous data stream that may include an event stream 2428 of real-time events and/or continuous or essentially unbounded event updates 2430 without a clear ending. may be configured to receive. 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, vehicle traffic monitoring, etc. can.
Communications subsystem 2424 may also communicate structured and/or unstructured data feeds 2426, event streams 2428, event updates 2430, etc. with one or more streaming data source computers coupled to computer system 2400. It may be configured to output to one or more databases.
Computer system 1500 may include a hand-held mobile device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a personal computer, It may be one of a variety of types including workstations, mainframes, kiosks, server racks or other data processing systems.
Because computers and networks continue to evolve, the description of computer system 2400 shown in FIG. 24 is intended as a specific example only. Many other configurations having more or fewer components than the system shown in FIG. 24 are possible. Customized hardware may also be used and/or specific elements may be implemented, for example in hardware, firmware, software (including applets), or a combination. Additionally, connections to other computing devices such as network input/output devices may be utilized. Based on the disclosure and teachings provided herein, those skilled in the art will recognize other means and/or methods for implementing the various embodiments.
Although the embodiments have 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. Aspects of the various embodiments, parts of the various aspects and various features recited above and/or in the appended claims may be combined or exchanged, in whole or in part. can. As those skilled in the art will understand, in the description of the various embodiments above, embodiments that refer to other embodiments can be combined with other embodiments as appropriate. Furthermore, those skilled in the art will appreciate that the above description is illustrative only and is not intended to limit the invention.
26 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2015216549A | Cites | Japan |
| CN104065622A | Cites | China |
| US20050108568A1 | Cites | United States of America |
20 members in 5 offices
Members20
| Document | Office | Kind | |
|---|---|---|---|
| US2018084010A1 | United States of America | A1 | |
| US2018084011A1 | United States of America | A1 | |
| US2018084012A1 | United States of America | A1 | |
| WO2018053337A1 | World Intellectual Property Organization (WIPO) | A1 | |
| CN109792439A | China | A | |
| EP3513543A1 | European Patent Office (EPO) | A1 | |
| US10432671B2 | United States of America | B2 | |
| US10447738B2 | United States of America | B2 | |
| JP2019535068A | Japan | A | |
| US10547646B2 | United States of America | B2 | |
| US2020120141A1 | United States of America | A1 | |
| EP3513543B1 | European Patent Office (EPO) | B1 | |
| CN109792439B | China | B | |
| JP7088913B2 | Japan | B2 | |
| JP2022126712A | Japan | A | |
| US11516255B2 | United States of America | B2 | |
| JP7358564B2This record | Japan | B2 | |
| JP2023175878A | Japan | A | |
| JP7595723B2 | Japan | B2 | |
| JP2025024129A | Japan | A |
6 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 7358564
- Application
- 93754
Titles2
- Japanese
- 脅威を検出するための動的ポリシーの導入およびアクセスの可視化
- English
- Deploy dynamic policies and access visibility to detect threats
Classification
- CPC, 4
- H04L63/20
- H04L63/108
- H04L63/1416
- H04L63/1425
- IPC, 1
- G06F21 55
