Centralized identity redistribution
By receiving and applying user context information from cloud security services at the security platform, centralized identity redistribution of user context is achieved, and the problem of difficult user context redistribution in the existing security architecture is solved, timely and effective execution of security policies is achieved, and resource use is reduced.
Patent Information
- Application Number
- CN202380044468.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-11-14
- Filing Date
- 2023-11-10
- Publication Date
- 2025-03-04
AI Technical Summary
The existing security architecture is difficult to achieve real-time user context redistribution, resulting in timely and effective execution of security policies, especially in distributed and hybrid cloud environments.
By receiving user context information from cloud security services at a security platform and using this information to apply security policies, centralized identity redistribution of user context is achieved. The system includes processors and memory that can process and store user context information and redistribute it to other security platforms.
It realizes timely and efficient execution of security policies, simplifies the redistribution of user context, provides centralized user context data consumption, reduces the use of CPU and storage resources for each security platform, and does not require significant changes to existing customer deployments.
Smart Images

Figure CN119563303A_ABST
Abstract
Description
[0001] The present disclosure relates to a system and method for synchronizing honeynet configuration to reflect a target network environment. Background Art
[0002] Firewalls usually protect networks from unauthorized access while allowing authorized communications to pass through the firewall. A firewall is usually a device or a group of devices that provide firewall functions for network access, or software executed on a device such as a computer. For example, a firewall can be integrated into the operating system of a device (e.g., a computer, a smart phone, or other type of device with network communication capabilities). A firewall can also be integrated into a computer server, a gateway, a network / routing device (e.g., a network router), or a data application device (appliance) (e.g., a security application device or other type of dedicated device), or executed as software on the computer server, gateway, network / routing device (e.g., a network router), or a data application device (e.g., a security application device or other type of dedicated device).
[0003] Firewalls typically deny or allow network traffic based on a set of rules. These rule groups are often called policies. For example, a firewall can filter inbound traffic by applying a set of rules or policies. A firewall can also filter outbound traffic by applying a set of rules or policies. Firewalls can also be able to perform basic routing functions.
[0004] US2022 / 070223A1 states, according to its abstract, technology for a security platform having external inline processing of combined selected traffic. In some embodiments, a system / method / computer program product for providing external inline processing of combined selected traffic to a security platform includes: monitoring network traffic of a session at the security platform; selecting a subset of the monitored network traffic associated with the session to send to a cloud-based security service for security policy-based analysis, wherein the selected subset of the monitored network traffic is proxied to the cloud-based security service; and receiving the results of the security policy-based analysis from the cloud-based security service, and performing a response action based on the results of the security policy-based analysis.
[0005] EP3993331A1 states a technique for providing a flow metadata exchange between a network and a security function for a security service according to its abstract. In some embodiments, a system / process / computer program product for providing a flow metadata exchange between a network and a security function for a security service includes: receiving a flow from a software defined wide area network (SD-WAN) device at a network gateway of the security service; inspecting the flow to determine meta information associated with the flow; and communicating the meta information associated with the flow to the SD-WAN device.
[0006] US2019 / 0089678A1 states a technique for outbound / inbound lateral traffic punting based on process risk according to its abstract. In some embodiments, a system / process / computer program product for outbound / inbound lateral traffic punting based on process risk includes: receiving process identification (ID) information from an endpoint (EP) agent executed on an EP device at a network device on an enterprise network, wherein the process ID information identifies a process associated with an outbound or inbound network session on the EP device on the enterprise network, and the EP agent selects the network session to punt to the network device for inspection; monitoring network communications associated with the network session at the network device to identify an application identification (APP ID) of the network session; and performing actions based on security policies using the process ID information and the APP ID. Summary of the invention
[0007] According to one aspect, a system is provided, comprising: a processor configured to: receive user context information from a cloud security service at a security platform; apply a security policy at the security platform using the user context information; and a memory coupled to the processor and configured to provide instructions to the processor.
[0008] In one embodiment, the security platform includes a physical firewall, a virtual machine firewall, or a container-based firewall.
[0009] In an optional embodiment, the user context information includes at least one of IP-user mapping, user-label mapping, IP-label mapping, IP-port-user mapping and IP-device ID mapping.
[0010] In one embodiment, the security platform subscribes to a segment for centralized identity redistribution.
[0011] According to another aspect, there is provided a method comprising:
[0012] receiving, at the security platform, user context information from the cloud security service; and
[0013] A security policy is applied at the security platform using the user context information.
[0014] In one embodiment, the security platform includes a physical firewall, a virtual machine firewall, or a container-based firewall.
[0015] In an optional embodiment, the user context information includes at least one of IP-user mapping, user-label mapping, IP-label mapping, IP-port-user mapping and IP-device ID mapping.
[0016] In one embodiment, the security platform subscribes to a segment for centralized identity redistribution.
[0017] According to another aspect, there is provided a computer program product embodied in a tangible computer-readable storage medium and comprising computer instructions for performing a method as defined herein.
[0018] According to another aspect, a processor-implemented method is provided, comprising: generating user context information at an authenticated security platform and / or obtaining user context information at the security platform from one or more sources; and sending the user context information to a cloud security service. It will be appreciated that this method can be implemented in the same system as described above.
[0019] In one embodiment, the security platform is an edge device in a SD-WAN network, wherein the edge device is configured to act as a connection and / or termination point for the SD-WAN network, wherein the edge device is further configured to connect to the security service via an IPsec tunnel.
[0020] In one embodiment, the security platform includes a physical firewall, a virtual machine firewall, or a container-based firewall.
[0021] In one embodiment, the security platform publishes segments for centralized identity redistribution, wherein, preferably, the segments are groups of security platforms or firewalls.
[0022] According to another aspect, a system is provided, wherein the system includes: a processor configured to: receive user context information from a security platform at a cloud security service; store the user context information in a data storage of the cloud security service for redistributing the user context information to another security platform; and a memory coupled to the processor and configured to provide instructions to the processor.
[0023] In one embodiment, the user context information includes at least one of IP-user mapping, user-label mapping, IP-label mapping, IP-port-user mapping, and IP-device ID mapping.
[0024] In one embodiment, the another security platform subscribes to a segment for centralized identity redistribution to receive the user context information from the cloud security service, and wherein the cloud security service publishes the user context information to the another security platform.
[0025] According to another aspect, there is provided an assembly comprising a system as defined herein.
[0026] According to another aspect, a method is provided, comprising: receiving user context information from a cloud security service at a security platform; and storing the user context information in a data store of the cloud security service for redistributing the user context information to another security platform.
[0027] According to another aspect, there is provided a computer program product embodied in a tangible computer-readable storage medium and comprising computer instructions for performing a method as defined herein. BRIEF DESCRIPTION OF THE DRAWINGS
[0028] Various embodiments of the invention are disclosed in the following detailed description and accompanying drawings.
[0029] Figure 1A-1B is a system environment diagram including an example SD-WAN architecture and security services according to some embodiments.
[0030] Figure 2 A cloud user context architecture for centralized identity redistribution for security services according to some embodiments.
[0031] Figure 3A Illustrate an architectural overview of segmenting and sharing user context information for providing centralized identity redistribution for security services in accordance with some embodiments.
[0032] Figure 3B Illustrated is another architectural overview of segmenting and sharing user context information for providing centralized identity redistribution for security services in accordance with some embodiments.
[0033] Figure 3C Illustrated is the architecture of a firewall daemon for providing centralized identity redistribution for security services in accordance with some embodiments.
[0034] Figure 3D Illustrate an architecture for IP user mappings that can be uploaded and downloaded to the cloud for providing centralized identity redistribution for security services in accordance with some embodiments.
[0035] Figure 3E Illustrate an IP user mapping workflow for providing centralized identity redistribution for security services according to some embodiments.
[0036] Figure 3F Illustrated is an architecture for IP label mapping that can be uploaded and downloaded to the cloud for providing centralized identity redistribution for security services in accordance with some embodiments.
[0037] Figure 3G Illustrated is an architecture for providing centralized identity redistribution for security services using segments in accordance with some embodiments.
[0038] Figure 3H Illustrated is a cloud-based User-ID component architecture for providing centralized identity redistribution for security services in accordance with some embodiments.
[0039] Figure 4A An embodiment of a network gateway in accordance with some embodiments is illustrated.
[0040] Figure 4B is a functional diagram of the logical components of an embodiment of a data application device.
[0041] Figure 5 is a flow diagram illustrating a process for providing centralized identity redistribution for security services in accordance with some embodiments.
[0042] Figure 6 is another flow diagram illustrating a process for providing centralized identity redistribution for security services in accordance with some embodiments.
[0043] Figure 7 is another flow diagram illustrating a process for providing centralized identity redistribution for security services in accordance with some embodiments. DETAILED DESCRIPTION
[0044] The present invention may be implemented in many ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor (such as a processor configured to execute instructions stored on and / or provided by a memory coupled to the processor). In this specification, these embodiments or any other form that the present invention may take may be referred to as techniques. In general, within the scope of the present invention, the order of the steps of the disclosed processes may be changed. Unless otherwise stated, a component such as a processor or memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform a task at a given time, or as a specific component manufactured to perform the task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data such as computer program instructions.
[0045] A detailed description of one or more embodiments of the present invention is provided below together with the accompanying drawings that illustrate the principles of the present invention. The present invention is described in conjunction with such embodiments, but the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention encompasses many alternatives, modifications and equivalents. In order to provide a comprehensive understanding of the present invention, many specific details are set forth in the following description. These details are provided for illustrative purposes, and the present invention can be implemented according to the claims without some or all of these specific details. For the purpose of clarity, technical materials known in the technical field related to the present invention are not described in detail so that the present invention is not unnecessarily obscured.
[0046] Advanced or Next-Generation Firewall
[0047] Malware is a general term that is often used to refer to malicious software (e.g., including a variety of hostile, invasive and / or otherwise unwanted software). Malware can be in the form of code, scripts, active content and / or other software. Example uses of malware include disrupting computer and / or network operations, stealing proprietary information (e.g., confidential information, such as identity, financial and / or intellectual property related information), and / or gaining access to private / proprietary computer systems and / or computer networks. Unfortunately, as technologies have developed to help detect and mitigate malware, nefarious authors have found ways to circumvent such efforts. Therefore, there is a continuing need to improve technologies for identifying and mitigating malware.
[0048] Firewalls usually protect networks from unauthorized access while allowing authorized communications to pass through the firewall. A firewall is usually a device or a group of devices that provide firewall functions for network access, or software executed on the device. For example, a firewall can be integrated into the operating system of a device (e.g., a computer, a smart phone, or other types of devices with network communication capabilities). Firewalls can also be integrated into various types of devices or security devices or data application devices (e.g., security application devices or other types of dedicated devices, and in some embodiments, certain operations can be implemented in dedicated hardware such as ASIC or FPGA), or as software applications on various types of devices or security devices or data application devices (e.g., security application devices or other types of dedicated devices, and in some embodiments, certain operations can be implemented in dedicated hardware such as ASIC or FPGA) Executed on, the various types of devices or security devices such as computer servers, gateways, network / routing devices (e.g., network routers).
[0049] Firewalls typically deny or allow network transmissions based on a set of rules. These rule groups are often referred to as policies (e.g., network policies or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted external traffic from reaching the protected device. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allowing, blocking, monitoring, notifying or recording, and / or other actions can be specified in firewall rules or firewall policies, which can be triggered based on various criteria such as described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.
[0050] Security devices (e.g., security appliances, security gateways, security services, and / or other security devices) can perform various security operations (e.g., firewalls, anti-malware, intrusion prevention / detection, proxies, and / or other security functions), networking functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, and / or other networking functions), and / or other security and / or networking related operations. For example, routing can be performed based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information (e.g., layer-3 IP based routing).
[0051] Basic packet filtering firewalls filter network traffic by inspecting individual packets transmitted on the network (e.g., packet filtering firewalls or first generation firewalls, which are stateless packet filtering firewalls). Stateless packet filtering firewalls typically inspect individual packets themselves and apply rules based on the inspected packets (e.g., using a combination of the packet's source and destination address information, protocol information, and port numbers).
[0052] Application firewalls can also perform application layer filtering (e.g., using an application layer filtering firewall or a second generation firewall, which works at the application layer of the TCP / IP stack). Application layer filtering firewalls or application firewalls can generally identify certain applications and protocols (e.g., web browsing using Hypertext Transfer Protocol (HTTP), Domain Name System (DNS) requests, file transfers using File Transfer Protocol (FTP), and various other types of applications and other protocols, such as Telnet, DHCP, TCP, UDP, and TFTP (GSS)). For example, an application firewall can block unauthorized protocols that attempt to communicate over standard ports (e.g., unauthorized / non-compliant protocols that attempt to sneak through using a non-standard port for that protocol can generally be identified using an application firewall).
[0053] A stateful firewall may also perform stateful packet inspection, where each packet is inspected within the context of a series of packets associated with a flow / stream of packets transmitted over that network (e.g., a stateful firewall or third generation firewall). This firewall technology is often referred to as stateful packet inspection because it maintains a record of all connections passing through the firewall and is able to determine whether a packet is the start of a new connection, part of an existing connection, or an invalid packet. For example, the state of a connection itself can be one of the criteria for triggering a rule within a policy.
[0054] As discussed above, advanced or next-generation firewalls can perform stateless and stateful packet filtering and application layer filtering. Next-generation firewalls can also perform additional firewall technologies. For example, some newer firewalls (sometimes referred to as advanced or next-generation firewalls) can also identify users and content. In particular, some next-generation firewalls are expanding the list of applications that these firewalls can automatically identify to thousands of applications. Examples of such next-generation firewalls are commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks' PA Series Next-Generation Firewalls, Palo Alto Networks' VM Series Virtualized Next-Generation Firewalls, and CN Series Container Next-Generation Firewalls).
[0055] As an example, an advanced or next generation firewall may also be implemented using a virtualized firewall. Examples of such next generation firewalls are commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks' firewalls, which support a variety of commercial virtualization environments, including, for example, ESXi TM and NSX TM , NetScaler SDX TM , KVM / OpenStack (Centos / RHEL, ) and Amazon Web Services (AWS). For example, virtualized firewalls can support similar or identical advanced threat blocking features available in next-generation firewalls and physical form factor appliances, allowing enterprises to safely enable applications flowing into and through their private, public, and hybrid cloud computing environments. Automation features such as VM monitoring, dynamic address groups, and REST-based APIs allow enterprises to proactively monitor VM changes, dynamically feed that context into security policies, thereby eliminating policy lags that can occur when VMs change.
[0056] For example, Palo Alto Networks' next-generation firewalls enable enterprises and service providers to identify and control applications, users and content (not just ports, IP addresses and packets) using a variety of identification technologies such as: App-ID for accurate application identification TM (e.g., application ID), user-ID for user identification (e.g., by user or user group) TM (e.g., user ID), and Content-ID for real-time content scanning TM (e.g., content ID) (e.g., controlling web surfing and limiting data and file transfers). These identification technologies allow enterprises to use business-relevant concepts to securely enable application usage, rather than following the traditional approach provided by traditional port blocking firewalls. In addition, dedicated hardware for next-generation firewalls implemented as, for example, dedicated appliance devices generally provide higher performance levels for application inspection than software executed on general-purpose hardware (e.g., such as the security appliance provided by Palo Alto Networks, Inc., which utilizes dedicated, function-specific processing tightly integrated with a single-channel software engine to maximize network throughput while minimizing latency for Palo Alto Networks' PA Series Next-Generation Firewalls).
[0057] Overview of technologies used to provide centralized identity redistribution
[0058] Existing methods for redistribution of user context typically require separate protocols for each data type. These methods are not easily scalable for more data types. In addition, these methods typically require complex configuration (e.g., proxy-client) deployment and do not provide centralized visibility of such user context data. In addition, such existing methods provide limited scalability (e.g., scalability based on security platform / firewall resource constraints).
[0059] Therefore, there are technical challenges with current security architectures. Specifically, there is a need to have authenticated user identities in any security architecture to ensure secure access to resources and enforce zero trust (e.g., in an enterprise network computing environment).
[0060] For example, for an unconstrained workforce (e.g., geographically distributed users, and / or hybrid / remote users), the security architecture is highly distributed, and distributing locally learned identity context (e.g., IP-user, user-label, IP-label, IP-port-user, IP-device ID, and / or various other identity contexts) throughout the security architecture for secure and consistent application is a significant technical challenge. Furthermore, the problem of deploying and debugging user context redistribution is also a complex technical challenge.
[0061] Therefore, what is needed is a solution that provides real-time user context redistribution for timely and efficient enforcement of security policies.
[0062] It is also desirable to provide user context that can be used for consumption of security entities / devices (e.g., firewalls, gateways, etc.) as well as the SD-WAN environment.
[0063] It is also desirable to provide highly available and robust redistribution point(s) (eg, to avoid creating single points of failure).
[0064] It is also desirable to provide a solution for redistribution of identity context that is extensible for other context types (e.g., 5G data, device-ID, etc.).
[0065] Thus, various techniques for centralized identity redistribution are disclosed.
[0066] In some embodiments, a system / process / computer program product for centralized identity redistribution for security services includes: receiving user context information (e.g., IP-user mapping, user-tag mapping, IP-tag mapping, IP-port-user mapping, IP-device ID mapping, 5G user context information, and / or other user context information / data) from a cloud security service at a security platform; and applying security policies at the security platform using the user context information. In one example, the security system applies user context information in a policy based on the type of user context information. Some user context information (such as user-tag mapping, IP-tag mapping, IP-port mapping, IP-port-user mapping) can be used, for example, to directly apply a policy, while some types (such as 5G data, device-ID) are used to determine membership of an object used in a policy.
[0067] In some embodiments, a system / process / computer program product for centralized identity redistribution for a security service includes: sending user context information (e.g., IP-user mapping, user-label mapping, IP-label mapping, IP-port-user mapping, IP-device ID mapping, 5G user context information, and / or other user context information / data) from a security platform to a cloud security service; and storing the user context information in a data store of the cloud security service for redistribution of the user context information to another security platform. The disclosed techniques for centralized identity redistribution allow user context information to be learned at a security platform and used to apply security policies at a security platform different from the security platform that learned the user context information. It will be clear that a security platform can be configured to both send and receive user context information.
[0068] For example, the disclosed techniques for centralized identity redistribution can be implemented across all security platforms, including physical firewalls as well as virtual machine (VM) and container firewalls.
[0069] As another example, the disclosed techniques for centralized identity redistribution may be implemented to facilitate segment-based flow control for identity information / data.
[0070] In addition, the disclosed techniques for centralized identity redistribution can simplify and unify the redistribution of user context. For example, the disclosed techniques for centralized identity redistribution can simplify and unify the redistribution of user context and can provide a centralized location / source to consume all user context information.
[0071] Furthermore, the disclosed techniques for centralized identity redistribution generally do not require any changes to existing enterprise customer deployments. For example, the disclosed techniques can facilitate cloud-based identity redistribution across regions where adding / removing security platforms (e.g., firewalls, appliances, etc.) is simple and generally does not require any configuration changes.
[0072] Finally, the disclosed techniques for centralized identity redistribution facilitate reducing CPU and memory resource usage on each security platform (e.g., firewalls, gateways / appliances, etc.) since most processing / merging can be implemented to be performed using cloud resources and, for example, only receiving data from a centralized / single source.
[0073] Thus, various techniques for centralized identity redistribution for security services are disclosed as will be further described below.
[0074] System environment including example cloud user context architecture for centralized identity redistribution for security services
[0075] Figure 1A-1B is a system environment diagram including example SD-WAN architectures and security services according to some embodiments. These example system diagrams generally illustrate security services for protecting branch and headquarters sites using SD-WAN connections that communicate with security services (e.g., cloud-based security services).
[0076] As organizations grow across different geographic locations, choosing a network becomes a delicate balancing act of cost, performance, and security. Software-defined WAN (SD-WAN) simplifies the management and operation of WANs by separating the networking hardware (data plane) from its control mechanisms (control plane). SD-WAN technology allows companies to build higher-performance WANs using lower-cost Internet access. With the adoption of SD-WAN, organizations are increasingly connecting directly to the Internet, introducing security challenges for protecting remote networks and mobile users. In addition, the deployment of Software as a Service (SaaS) applications has increased significantly, introducing additional security challenges as many organizations connect directly to such cloud-based SaaS applications. The adoption of SD-WAN technology introduces many benefits in terms of cost savings and enables organizations to be agile and optimized. However, it also makes branch offices and users targets for cyberattacks and other technical security challenges, as similarly described above.
[0077] SD-WAN security is often expected to be as flexible as the network, but it is also technically challenging to adapt traditional security approaches to such evolving SD-WAN networks in various enterprise network environments, such as in the following Figure 1A and Figure 1B In a traditional campus network design, there is a whole stack of network security appliances at the Internet edge that can protect the branch, which is true if all traffic is routed through the core network to pass through such a whole stack of network security appliances at the Internet edge. However, SD-WAN does not always use this network architecture, such as if the SD-WAN is configured to integrate cloud / SaaS applications.
[0078] An alternative to the traditional approach is to deploy network security appliances at the branch offices. However, this traditional approach complicates deployment because it results in the security appliances / elements being moved closer to the branch offices.
[0079] SD-WAN technology generally uses the principles of software-defined networking (SDN) and separates the control plane from the data plane. Based on this principle, SD-WAN deployments generally include the following components: (1) a controller that administrators use to centrally configure the WAN topology and define traffic path rules; and (2) a physical or virtual SD-WAN edge device that resides at each site and acts as a connection point and termination point for the SD-WAN fabric.
[0080] In an example SD-WAN Type 1 deployment (e.g., branch and headquarters deployment), at each branch site, an organization can deploy one or more SD-WAN edge devices and connect them to form an SD-WAN fabric or SD-WAN overlay. Administrators use a cloud-based or organization-based on-premise SD-WAN controller to manage and configure these edge devices and define traffic forwarding policies at each site.
[0081] refer to Figure 1A , for an example deployment (e.g., a branch, headquarters, and regional data center deployment), an IPSec tunnel is set up between each of the SD-WAN edge devices 102A, 102B, and 102C at each data center and a security service 120 (e.g., such as a cloud-based security service provided via Prisma Access (PA), which is a cloud-based security service commercially available from Palo Alto Networks, Inc., headquartered in Santa Clara, California) (e.g., including IPSec tunnels between (multiple) SD-WAN edge devices at each branch and headquarters site). This example system diagram is an example deployment for protecting traffic from each branch site using a WAN link (Type 1) as shown at 110. The SD-WAN fabric 110 and security service 120 each communicate with the Internet 140. The security service 120 communicates with a data store 130 (e.g., a data store for network / security log data, such as Cortex NAS commercially available from Palo Alto Networks, Inc., headquartered in Santa Clara, California). TM Data Lake) communications.
[0082] Specifically, this architecture adds SD-WAN appliances in regional data centers, along with SD-WAN appliances at each branch and headquarters site. These regional data centers can be public or private cloud environments. SD-WAN appliances at regional data centers aggregate network traffic for smaller sites in that region. For example, an organization can use this deployment when there are multiple regional branch sites with lower bandwidth connections to the Internet.
[0083] refer to Figure 1B, for another example deployment (e.g., branch, headquarters, and regional data centers), an IPSec tunnel is set up between the SD-WAN edge devices at each data center (e.g., including at SD-WAN devices 102D and 102E) and the security service 120 (e.g., such as a cloud-based security service provided via Prisma Access (PA), which is a cloud-based security service commercially available from Palo Alto Networks, Inc., headquartered in Santa Clara, California). This example system diagram is an example deployment that utilizes a regional hub / POP architecture to protect an SD-WAN deployment. As shown, an IPSec tunnel is established between each regional data center or hub 106A and 106B and the security service 120.
[0084] Today's common network architecture is to tunnel traffic between the headquarters and branches of an enterprise through MPLS links or dedicated encrypted VPN links. As more and more services are cloud-based (for example, including SaaS solutions such as Microsoft Office), etc.), and more information is available on the Internet, it often doesn't make much sense to tunnel traffic back to the aggregation point before routing it to its final destination. Branching traffic locally (e.g., as opposed to an on-premises application device) typically allows traffic to reach its destination faster and use bandwidth more efficiently. However, allowing traffic directly between devices in the branch and the Internet also introduces new technical security challenges, similar to those described above.
[0085] Specifically, in these and other example SD-WAN architectures and security services, flows may be configured to pass through security service 120, or to bypass security service 120 and be routed to a regional data center or hub or the Internet without passing through security service 120. As a result, these and other example SD-WAN architectures and security services give rise to the technical security issues described above because traffic passing through the security service is inefficiently inspected / monitored (e.g., DPI or other monitoring / inspection activities) at both the egress SD-WAN device / element and the security service. Furthermore, these and other example SD-WAN architectures and security services give rise to the technical security issues described above because traffic bypassing the security service is not consistently inspected / monitored, and analytics that provide security insights into the network and security functions of the security service will not be gathered.
[0086] Thus, the disclosed techniques for centralized identity redistribution can be implemented in these example SD-WAN architectures and security services, as described below with respect to Figure 2 Further described.
[0087] Figure 2The present invention is a cloud user context architecture for centralized identity redistribution for security services according to some embodiments. The user-ID component is often a central component of a security policy (e.g., a firewall policy), and the user-ID component is the backbone of many security design principles. The disclosed technology for centralized identity redistribution provides a global context that can consume user context and provide user context to all downstream consumers, as will now be described with respect to Figure 2 Further described.
[0088] refer to Figure 2 , the user-ID broker service 202 is a cloud component that provides an application programming interface (API) gateway. The user-ID broker service includes one or more broker pods 204. The user-ID broker service can accept data from any authorized entity (e.g., including non-PAN-OS entities / firewalls) via an API (e.g., a REST API), such as a cloud identity engine (CIE) 206 (e.g., a cloud-native single sign-on (SSO) and directory service as described further below, which facilitates centralized visibility and channel / segment configuration). The user-ID broker service can accept data of any data type and is easily extensible for more data types (e.g., user-ID, device-ID, 5G data, etc.). Figure 2 As shown in FIG. 1 , edge user-ID service 210 is another cloud component that interacts with security platforms 214A, 214B, and 214C (eg, Palo Alto Networks firewalls and / or other compatible devices / entities).
[0089] Also like Figure 2 As shown in , the edge user-ID service includes edge pods 212A, 212B, and 212C as shown. The edge user-ID service receives and sends data (e.g., user context / identity information / data) from these devices / entities via a communication protocol (e.g., gRPC). The edge user-ID service and the user-ID broker proxy service share data via a data store, as shown in BigTable 208 (e.g., the edge user-ID service and the user-ID broker proxy service can store data in the BigTable, which can be implemented using the Google Cloud BigTable data storage solution commercially available from Google, or another cloud data store can be similarly implemented). As further described below, a publish and subscribe distribution model can be used (e.g., publish and subscribe segments, such as will be described below with respect to Figure 3A further described) to distribute user context / identity information.
[0090] Figure 3AAn overview of an architecture for segmenting and sharing user context information for providing centralized identity redistribution for security services in accordance with some embodiments is illustrated. In this example, incoming traffic on a firewall (device) is attributed to an identified user based on its IP address. User context information (e.g., IP-tag, IP-user mapping, IP-port-user, IP-isolation, user-tag, etc.) is associated with the IP address available through a cloud-based redistribution service (e.g., periodically (such as every two seconds or some other periodic interval) to provide redistribution of time-sensitive user context data for timely and effective enforcement of security policies) such as described above with respect to Figure 2 Similar to the description. Cloud User ID (CUID) 302 (e.g., in Figure 2 An example implementation of a user-ID broker proxy service in the cloud shown at 202 in FIG. 1 is a multi-tenant redistribution service hosted in multiple cloud regions. Security platforms (e.g., firewalls and / or other security devices / entities) as shown at 304A, 304B, 304C, 304D, 304E, and 304F may be grouped into “segments,” and redistribution of user context / identity information / data may be restricted to stay within a segment, such as for remote networks (RNs) in the United States (US) region, the European (EU) region, and the Asia Pacific (AP) region, such as shown at 306A, 306B, and 306C.
[0091] In this example embodiment, any authenticated security platform (e.g., firewall and / or other security device / entity, such as Figure 3A 304A, 304B, 304C, 304D, 304E, and 304F in ) can be configured to publish to the segments in CUID. In addition, any authenticated security platform (e.g., firewall and / or other security device / entity) can subscribe to the segment(s) (e.g., Figure 3A RN US 306A, RN EU 306B and / or RN AP 306C) shown in the figure to consume user context information for a specific tenant.
[0092] Figure 3B Another architectural overview of user context information for providing centralized identity redistribution to security services to group and share segments in accordance with some embodiments is illustrated. In this example implementation, configuration is centralized and contributing security platforms (e.g., firewalls and / or other security devices / entities) generally do not need to be aware of any configuration related to redistribution. Configuration of CUID 302 can be performed via hub 322 using CIE interface (e.g., GUI) 320. As described above with respect to Figure 3ASimilarly described, the CUID may replicate data to make user context information / data available across segments (eg, a zone and / or another segment may be configured), thereby ensuring secure access regardless of the user's location.
[0093] refer to Figure 3B , CUID 302 includes branch A segment 324A and branch B segment 324B. Branch A firewall 326A performs publish / subscribe communication with branch A segment 324A for different user context data types. Branch B firewall 326B performs publish / subscribe communication with branch B segment 324B for different user context data types. Data center firewall 328 performs publish / subscribe communication with all branches (including Figure 3B The branch A segment 324A and the branch B segment 324B in this example implementation shown in FIG. 1 perform publish / subscribe communication of different user context data types.
[0094] Figure 3C 1 illustrates an architecture of a firewall daemon for providing centralized identity redistribution for security services in accordance with some embodiments. In this example implementation, a cloud service user-ID broker agent (e.g., Figure 2 The user-ID broker service in the cloud shown at 202 in FIG. 1 and the CIE (e.g., such as Figure 2 206) shown in FIG. 200 . Figure 2 The edge user-ID service in the cloud shown at 210 in FIG. 1 collects user context information / data from all security platforms based on a distribution (e.g., publish / subscribe) model (e.g., firewalls and / or other security devices / entities for security services) and distributes user context information / data to all security platforms. Figure 2 Similarly described, user-ID brokers and edge user-IDs use large tables (e.g., Figure 2 208) to store such user context / identity data. Figure 3A and Figure 3B Similarly described, segments can be used to group security platforms (e.g., firewalls and / or other security devices / entities for security services) to constrain data flows for specific tenant(s). The edge user-ID receives a mapping of security platforms to segments from the CIE via the mediation agent. The CIE queries the mediation agent to obtain user context / identity data for visibility requirements.
[0095] refer to Figure 3C, the broker agent / edge-user-ID 330 communicates with the management plane 332 of the security platform (e.g., a firewall and / or other security device / entity). Specifically, the identity cloud daemon (ICD) 334 of the management plane of the security platform communicates with the broker agent / edge-user-ID to communicate IP-user mappings (e.g., PAN-OS user ID) (upload / download) and communicate other data types (upload / download). The ICD 334 communicates with the user-ID component 340 (e.g., the PAN-OS user-ID component in this example embodiment for a PAN-OS firewall, which communicates with the data plane (DP) of the PAN-OS firewall as shown at 342) to upload data to the edge user-ID service. In addition, the ICD 334 extracts data from the edge user-ID service and sends it to the user-ID component 340 or the IoT component 338 based on the data type. The Redis component 336 is an in-memory data store (e.g., the Redis component may be implemented using Hiredis, which is a minimalist C client library for the Redis database, or may similarly use another commercially available or open source redis solution). The host information profile (HIP) information may similarly be redistributed and made available via the cloud using similar techniques.
[0096] Figure 3DThe diagram illustrates an architecture of IP user mappings that can be uploaded and downloaded to the cloud for providing centralized identity redistribution for security services according to some embodiments. As shown, the user-ID component 340 collects IP user mappings from various sources (e.g., Syslog, XML API, Active Directory (AD), proxy, captive portal (CP) (e.g., when a user initiates web traffic (HTTP or HTTPS) that matches an authentication policy rule, the PAN-OS firewall can be configured to prompt the user to authenticate through a captive portal (CP), which ensures that we know exactly who is accessing, for example, sensitive applications and data; then based on the user information collected during authentication, the firewall can create a new IP address to username mapping, or update an existing mapping for that user; for example, this method of user mapping in which the firewall cannot learn through other technologies such as monitoring servers The mapping can be useful in environments where, for example, you may have users who are not logged into the domain server you are monitoring, such as users on a Linux client), a VPN (such as GlobalProtect (GP) commercially available from Palo Alto Networks, Inc. headquartered in Santa Clara, California), etc.) receive IP user mappings 350. As shown, the user-ID component 340 updates the mapping to the LRU cache. The IP address can be used as a key for the LRU cache. The user-ID component 340 publishes an update to a Redis list, which can be used as an upload queue as shown. The key name of the list is "UPLOADQ". "UPLOADQ" is a list of IP addresses. ICD 334 consumes IP user mapping from "UPLOADQ". As shown, ICD 334 uploads IP user mapping to edge (i.e., broker / edge-user-ID) 330. Also as shown, ICD 334 downloads IP user mapping from edge 330. ICD 334 saves IP user mapping to LRU cache (e.g., LRU cache size can be implemented as 500K cache by default, or some other cache size can be similarly implemented in IP user mapping component 350). ICD 334 publishes IP user mapping to Redis list, which is used as download queue. The key name of the list is "DOWNLOADQ" (e.g., "DOWNLOADQ" is a list of IP addresses). User-ID component 340 consumes "DOWNLOADQ". User-ID component 340 pushes IP user mapping to DP 342.
[0097] Figure 3E Illustrate an IP user mapping workflow for providing centralized identity redistribution for security services according to some embodiments. Figure 3E Illustrated is an example implementation of an upload workflow and an unknown query and download workflow for cloud user-ID IP user mapping.
[0098] Figure 3F The diagram illustrates an architecture of IP label mappings that can be uploaded and downloaded to the cloud for providing centralized identity redistribution for security services according to some embodiments. As shown, the disclosed centralized identity redistribution technology can be used to similarly redistribute IP label mappings. For example, the IP label mappings can be maintained in a user-ID memory and saved on disk, as similarly shown at 350. The user-ID component can obtain IP label mappings from various sources (e.g., VM monitoring, XMLAPI, automatic tagging, agents, Panorama (which is a management platform commercially available from Palo Alto Networks, Inc. headquartered in Santa Clara, California) and / or various other sources can be similarly used). The user-ID component publishes the IP label mapping to a Redis "UPLOADQ". The ICD consumes the "UPLOADQ". The ICD uploads the IP label mapping to the edge. The ICD downloads the IP label mapping from the edge. The ICD publishes updates to the "DOWNLOADQ". The user-ID component consumes the "DOWNLOADQ". The User-ID component saves the updates to the XML file on the local disk and then notifies the development server (Devsrvr) as shown at 352.
[0099] In another example implementation, the disclosed centralized identity redistribution techniques may be used to similarly redistribute IP-port user mappings (eg, and / or user context information, such as other user mappings).
[0100] Figure 3G Illustrated is an architecture for providing centralized identity redistribution for security services using segments according to some embodiments. Whenever user context data (e.g., user context information) is published by the security platform to the edge (i.e., broker agent / edge-user-ID), the user context data is associated with the segments configured by the CIE (e.g., segments generally refer to groupings of security platforms / firewalls and are also referred to herein as channels, such as Figure 3F All security platforms belonging to the same segment will receive this published data (e.g., each firewall is publishing data to the segment and subscribing user context data to the segment, and the edge will provide logical separation between different segments in the big table data store).
[0101] In one example implementation, the edge (i.e., broker agent / edge-user-ID) detects any changes to a segment and moves the (multiple) secure platforms to the new segment. After the change, the edge downloads all data from the new segment to the (multiple) secure platforms. The existing old segment data in the cloud is not touched. The existing data from the old segment on the (multiple) secure platforms remains untouched. Data with timeouts will timeout. Data without timeouts (such as IP hosts or IP labels) can remain on the (multiple) secure platforms. Whenever the (multiple) secure platforms lose connection with the edge for a long period of time (e.g., one minute or some other predetermined or configurable time period), the following resynchronization operations can be performed: (1) When the (multiple) secure platforms reconnect, the edge can dump all data for the segment to the (multiple) secure platforms; and (2) the (multiple) secure platforms can publish all new data to the edge.
[0102] Figure 3H The diagram illustrates a cloud-based user-ID component architecture for providing centralized identity redistribution for security services according to some embodiments. In this example implementation, DAS (Device Association Service) provides customers with a solution for associating a group of devices (e.g., security platforms such as network gateway firewalls (NGFWs), Prisma access (PAs), software-defined wide area networks (SD-WANs), etc.) with a single tenant ID (referred to as a TSGID). Therefore, it will associate the serial number of the security platform with the TSGID. The enforcer component queries the instance store (e.g., for the front end of the DAS) to obtain the TSGID for a given serial number. Once the firewall is connected to the edge, the edge queries the enforcer instance to obtain the TSGID. The TSGID provides a global tenant ID to group all devices generated by the DAS together. As used herein, a segment TSGID generally refers to a customer's global tenant ID, which can be used across all security services that the customer can use (e.g., all security platforms / firewalls and services (service tenant ids) can be mapped to this global TSGID, which can be used to provide data separation between customers in the big table backend).
[0103] In one example implementation, the workflow for an NGFW (e.g., security platform / firewall) begins with the customer onboarding the CIE, CDL, and FAWKES to the TSG. The DAS can then be used to associate the firewall device with the TSG. The CIE can then be used to configure segments for each of these associated devices provided by the DAS. This configuration is pushed to the edge and is globally available to all regions, such as Figure 3HFinally, the firewall can be connected to the edge deployed in a specific area based on a geolocation service (for example, using AWS geolocation service or another geolocation service). Once the edge is connected, the edge will upload / download data based on the configuration pushed by the CIE.
[0104] In another example embodiment, the workflow for PA (e.g., Prisma Access Security Solution commercially available from Palo Alto Networks, Inc., headquartered in Santa Clara, California) begins with the customer booting the CIE, CDL, and FAWKES to the TSG for the first time. The DAS can then be used to associate the PA instance with the TSG. The SaaS agent can then push a list of devices to the CIE. The CIE can configure segments on these devices. This configuration is pushed to the edge and is globally available to all regions. The PA firewall can connect to an edge deployed in a specific region based on a geolocation service (e.g., using the AWS geolocation service or another geolocation service). Once the edge is connected, the edge will upload / download data based on the configuration pushed by the CIE.
[0105] In one example embodiment, data replication may be performed to replicate user context information, as will now be described. In some use cases, SD-WAN and PA may require data to be replicated across regions (e.g., US, APAC, EU, etc.). For example, user context information (such as a specific IP user mapping created in the EU region) should be available for use on a security platform in the US region (e.g., such as for a use case where a data center security platform in the US needs to be accessed by users from different regions). Data replication in such use cases can be implemented using the large table replication feature described above. For example, any IP-user mapping created in the EU region can be configured to be automatically synchronized to the US region using Google Cloud Platform (GCP) (e.g., this can be controlled by a global replication configuration on the segment).
[0106] Thus, the disclosed techniques for centralized identity redistribution can be implemented across different security platforms (including physical, VM, and container firewalls) and do not require any changes to existing customer deployments as similarly described above. The disclosed techniques for centralized identity redistribution can also simplify and unify the redistribution of user context by providing a central source for consuming all user context information (e.g., using a publish and subscribe communication model, including for example IP-label and user-label redistribution).
[0107] In addition, the disclosed techniques for centralized identity redistribution facilitate cloud-based identity redistribution across segments and provide a centralized identity redistribution mechanism for identity data (e.g., regions, such as described above with respect to Figure 3A and Figure 3BSimilar to what is described above) provides segment-based flow control.
[0108] Furthermore, segment-based flow control for identity data facilitates reducing CPU and memory resources on each security platform (e.g., firewall or other security device / entity) since most of the processing / merging / storage is performed in the cloud and data is received from only one source. Furthermore, adding / removing security platforms (e.g., firewall or other security device / entity) is simple and does not require any configuration changes.
[0109] Figure 4A An embodiment of a network gateway 214 (eg, such as Figure 2 214A-C in the figure). In various embodiments, if the network gateway is implemented as a data application device, the example shown is a representation of physical components that may be included in the network gateway 214. Specifically, the data application device includes a high-performance multi-core central processing unit (CPU) 402 and a random access memory (RAM) 404. The data application device also includes a storage device 410 (such as one or more hard disks or solid-state storage units). In various embodiments, the data application device stores (whether in RAM 404, storage device 410 and / or other appropriate locations) information used in monitoring the enterprise network and implementing the disclosed technology. Examples of such information include application identifiers, content identifiers, user identifiers (e.g., user identity / context information / data, such as similarly described herein), requested URLs, IP address mappings, policies and other configuration information, signatures, host name / URL classification information, malware profiles, and machine learning models. The data application device may also include one or more optional hardware accelerators. For example, the data application device may include: an encryption engine 406, which is configured to perform encryption and decryption operations; and one or more field programmable gate arrays (FPGAs) 408, which are configured to perform matching, act as a network processor, and / or perform other tasks.
[0110] The functions described herein as being performed by a data application device can be provided / implemented in a variety of ways. For example, a data application device can be a dedicated device or device group. The functions provided by a data application device can also be integrated into a general-purpose computer, a computer server, a gateway and / or a network / routing device or executed as software on a general-purpose computer, a computer server, a gateway and / or a network / routing device. In some embodiments, at least some of the services described as being provided by a data application device are provided to a client device (e.g., an endpoint device such as a laptop, a smart phone, etc.) as a replacement (or additionally) by software executed on the client device.
[0111] Whenever a data application device is described as performing a task, a single component, a subset of components, or all components of the data application device may collaborate to perform the task. Similarly, whenever a component of a data application device is described as performing a task, a subcomponent may perform the task and / or a component may perform the task in conjunction with other components. In various embodiments, portions of the data application device are provided by one or more third parties. Depending on factors such as the amount of computing resources available to the data application device, various logical components and / or features of the data application device may be omitted, and the techniques described herein may be adapted accordingly. Similarly, where applicable, additional logical components / features may be included in the embodiments of the data application device. In various embodiments, an example of a component included in the data application device is an application recognition engine configured to identify applications (e.g., using various application signatures to identify applications based on data packet flow analysis). For example, an application recognition engine may determine what type of traffic a session involves, such as Web browsing—social networking; Web browsing—news; SSH; and the like.
[0112] The disclosed system processing architecture can be used with different types of clouds in different deployment scenarios, such as the following: (1) public cloud; (2) private cloud on-premises; and (3) inside a high-end physical firewall. Some processing power can be allocated to execute a private cloud (e.g., using the management plane (MP) in the Palo Alto Networks PA Series firewall appliance).
[0113] Figure 4B 214. FIG. 215 is a functional diagram of the logical components of an embodiment of a data application device. The example shown is a representation of the logical components that may be included in the network gateway 214 in various embodiments (e.g., such as Figure 2 Unless otherwise noted, the various logical components of the network gateway 214 are generally implementable in a variety of ways, including as a collection of one or more scripts (e.g., written in Java, python, etc., where applicable).
[0114] As shown, the network gateway 214 includes a firewall, and includes a management plane 432 and a data plane 434. The management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session handling.
[0115] The network processor 436 is configured to receive packets from client devices, such as client devices (e.g., endpoint devices, such as a user's laptop, smartphone, tablet, etc.), and provide them to the data plane 434 for processing. Whenever the flow module 438 identifies a packet as part of a new session, it creates a new session flow. Based on the flow lookup, subsequent packets will be identified as belonging to the session. If applicable, SSL decryption is applied by the SSL decryption engine 440. Otherwise, processing by the SSL decryption engine 440 is omitted. The decryption engine 440 can help the network gateway 214 inspect and control SSL / TLS and SSH encrypted traffic, and thus help stop threats that may otherwise remain hidden in the encrypted traffic. The decryption engine 440 can also help prevent sensitive content from leaving the network of the enterprise / security customer. Decryption can be selectively controlled (e.g., enabled or disabled) based on parameters such as URL classification, traffic source, traffic destination, user, user group, and port. In addition to decryption policies (e.g., specifying which sessions to decrypt), decryption profiles can be assigned to control various options for sessions controlled by the policy. For example, the use of specific cipher suites and encryption protocol versions can be required.
[0116] The application identification (APP-ID) engine 442 is configured to determine what type of traffic a session involves. As an example, the application identification engine 442 may identify a GET request in the received data and infer that the session requires an HTTP decoder. In some cases, such as a web browsing session, the identified application may change, and such a change will be noted by the network gateway 214. For example, a user may initially browse to a corporate wiki (classified as "Web Browsing - Productivity" based on the URL visited), and then subsequently browse to a social networking site (classified as "Web Browsing - Social Networking" based on the URL visited). Different types of protocols have corresponding decoders.
[0117] Based on the determination made by the application identification engine 442, the data packet is sent by the threat engine 444 to the appropriate decoder, which is configured to assemble the data packets (which may have been received out of order) into the correct order, perform tokenization, and extract the information. The threat engine 444 also performs signature matching to determine what should be done with the data packet. The SSL encryption engine 446 can re-encrypt the decrypted data as needed. The forwarding module 448 is used to forward the data packet for transmission (e.g., to a destination).
[0118] Also like Figure 4BAs shown in FIG. 4 , policies 452 (e.g., security / firewall policies) are received and stored in the management plane 432. Policies may include one or more rules, which may be specified using domain names and / or host / server names, and the rules may apply one or more signatures or other matching criteria or heuristics such as security policy enforcement for subscribers / IP flows based on various parameters / information extracted from monitored session traffic flows. An interface (I / F) communicator 450 is provided for management communications (e.g., via (REST) APIs, messaging or network protocol communications, or other communication mechanisms).
[0119] Example process for providing centralized identity redistribution for security services
[0120] Figure 5 is a flow chart illustrating a process for providing centralized identity redistribution for security services according to some embodiments. In one embodiment, process 500 is performed using the system architecture described above (eg, such as described above with respect to FIGS. 1-4B ).
[0121] The process begins at 502 when a flow is received at a security platform of a security service. For example, the security service may be a cloud-based security service as similarly described above.
[0122] At 504, using the above-mentioned centralized identity redistribution technology, user context information (e.g., IP-user mapping, user-label mapping, IP-label mapping, IP-port-user mapping, IP-device ID mapping, 5G user context information and / or other user context information / data) is received from the cloud security service at the security platform.
[0123] At 506, the user context information is used to apply security policies at the security platform.
[0124] Figure 6 is another flow chart illustrating a process for providing centralized identity redistribution for security services according to some embodiments. In one embodiment, process 600 is performed using the system architecture described above (eg, such as described above with respect to FIGS. 1-4B ).
[0125] The process begins at 602 when a flow is received at a security platform of a security service. For example, the security service may be a cloud-based security service as similarly described above.
[0126] At 604, user context information (e.g., IP-user mapping, user-label mapping, IP-label mapping, IP-port-user mapping, IP-device ID mapping, 5G user context information and / or other user context information / data) is sent from the security platform to the cloud security service.
[0127] At 606 , the user context information is stored in a data store of the cloud security service for redistribution of the user context information to another security platform using the centralized identity redistribution technique described above.
[0128] Figure 7 is another flow chart illustrating a process for providing centralized identity redistribution for security services according to some embodiments. In one embodiment, process 700 is performed using the system architecture described above (eg, such as described above with respect to FIGS. 1-4B ).
[0129] Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
Claims
1. A processor-implemented method, comprising: Receiving (504) user context information at the security platform from the cloud security service, wherein the user context information includes at least one of an IP-user mapping, a user-label mapping, an IP-label mapping, an IP-port-user mapping, and an IP-device ID mapping; and Security policies are applied (506) at the security platform using the user context information.
2. The method according to claim 1, wherein: The security platform includes a physical firewall, a virtual machine firewall, or a container-based firewall.
3. The method according to claim 1 or 2, wherein: The security platform is an edge device (102A, 102B, 102C) in a SD-WAN network, wherein the edge device is configured to act as a connection and / or termination point for the SD-WAN network, and wherein the edge device (102A, 102B, 102C) is further configured to connect to the cloud security service (120) via an IPsec tunnel.
4. The method according to claim 1, 2 or 3, wherein: The security platform subscribes to a segment for centralized identity redistribution, wherein, preferably, the segment is a grouping of security platforms or firewalls.
5. A method according to any one of the preceding claims, wherein: The security platform is a certified platform for security services, and wherein the method further comprises: prior to receiving the user context information, receiving incoming traffic at the security platform; wherein the user context information is associated with an IP address of the incoming traffic; and Wherein applying the security policy includes attributing the incoming traffic to the identified user by associating the user context information with the IP address.
6. A processor-implemented method comprising: generating user context information at the authenticated secure platform and / or obtaining user context information from one or more sources at the secure platform; as well as The user context information is sent to a cloud security service.
7. The method according to claim 6, wherein: The security platform is an edge device (102A, 102B, 102C) in a SD-WAN network, wherein the edge device is configured to act as a connection and / or termination point for the SD-WAN network, wherein the edge device (102A, 102B, 102C) is further configured to connect to the cloud security service (120) via an IPsec tunnel.
8. A processor-implemented method comprising: Receiving (604) user context information from the security platform at the cloud security service, wherein the user context information includes at least one of an IP-user mapping, a user-label mapping, an IP-label mapping, an IP-port-user mapping, and an IP-device ID mapping; and The user context information is stored (606) in a data store of the cloud security service for use in redistributing the user context information to another security platform.
9. The method according to claim 8, wherein: The other security platform subscribes to the segment for centralized identity redistribution to receive the user context information from the cloud security service, and wherein the method further comprises: publishing the user context information to the other security platform, and wherein, preferably, the segment is a grouping of a security platform or a firewall.
10. A system comprising: processor; as well as A memory storing instructions which, when executed by the processor, cause the processor to perform the method according to any one of claims 1-5.
11. A system comprising: processor; as well as A memory storing instructions which, when executed by the processor, cause the processor to perform the method according to claim 6 or 7.
12. A system comprising: processor; as well as A memory storing instructions which, when executed by the processor, cause the processor to perform the method according to claim 8 or 9.
13. An assembly comprising the system according to claim 10 and the system according to claim 12.
14. The assembly according to claim 13, further comprising the system according to claim 11, and wherein preferably, both security platforms of the systems according to claims 10 and 11 are configured to be connected to the cloud security platform of the system according to claim 12, and wherein, The user context information generated and / or obtained at the security platform of the system according to claim 11 is received and stored at the cloud security system according to claim 12, and is received by the security platform of the system according to claim 10 from the cloud security system.
15. A computer program product embodied in a tangible computer-readable storage medium and comprising computer instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1-9.
Citation Information
Patent Citations
Flow metadata exchanges between network and security functions for a security service
EP3993331A1
Outbound / inbound lateral traffic punting based on process risk
US20190089678A1
Security platform with external inline processing of assembled selected traffic
US20220070223A1
Cited By
Machine learning for prioritizing traffic in multi- purpose inline cloud analysis (MICA) to enhance malware detection
US12531886B2
Data centric approach for supporting multiple inline cloud services
US12652293B2
Multi-process shared-memory message communication
US12652301B2
Data centric approach for supporting multiple inline cloud services
US20250141886A1