Prioritization of individual channels within multiplexed stream of zero trusted network access (ZTNA)

Abstract

Techniques for using a secure access gateway to inform computing and / or network prioritization signaling to various flows within a multiplexing session for zero trusted network access (ZTNA). A secure access gateway may be configured to identify weighted data and / or prioritized data associated with respective flows within a multiplexing session that includes various protocols (e.g., HTTP / 2 and / or HTTP / 3), and determine gateway priority values. That is, the secure access gateway may be configured to prioritize certain types of traffic (user roles, resource types, etc.) higher than other traffic regardless of the protocols employed by the respective streams. The secure access gateway may then prioritize the first flow with a more advantageous gateway priority value than the second flow (e.g., networking and / or computing resources). In addition, the secure access gateway may be configured to transmit an indication of the gateway priority value to the target resource such that the stream may be prioritized in the opposite direction.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Patent Application No. 18 / 122,052, filed on March 15, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure generally relates to prioritizing channels within a multiplexed stream, utilizing authorization chaining to reduce the attack surface of connection(s) between client(s) and network resource(s), and / or deploying deception at scale in a network. Background Art

[0004] Cloud-based service provider networks (often described as "hyperscalers") provide cloud-based services to meet users' computing service needs without requiring users to invest in and maintain the computing infrastructure required to implement the services. For example, a cloud service provider may operate a network of data centers (e.g., public data centers) that house a large number of interconnected computing systems, which are configured by the service provider to provide cloud-based services to users (or "customers"). These service provider networks can provide network-based computing resources as needed. For example, a service provider network may allow users to purchase and utilize computing resources, such as virtual machine ("VM") instances, computing resources, data storage resources, database resources, networking resources, network services, and other types of computing resources. Users can configure the computing resources provided by the service provider network to achieve the desired functionality, such as providing network-based applications or another type of functionality to user enterprises. Although data centers based on hyperscalers are becoming increasingly popular, traditional enterprise-managed data centers are still widely used. The combination of these deployments is often described as a "hybrid" data center. Typically, remote users are able to connect to these network-based applications and / or enterprise functions using a zero-trust network access (ZTNA) solution.

[0005] While ZTNA solutions can provide enterprise users with a way to establish secure remote access to computing resources, ZTNA lacks the ability to prioritize traffic in a way that the ZTNA solution can signal the system to give computing and network prioritization to flows within a multiplexed flow. For example, if a ZTNA session has two types of traffic (e.g., real-time traffic and web traffic) multiplexed together in a single connection, there is no good way to prioritize one type of traffic over the other.

[0006] In addition, ZTNA solutions traditionally rely on a single gateway to enforce access policies defined by the network. If a malicious user (e.g., a network attacker) successfully bypasses or compromises the gateway, the user will be able to access resources served by the gateway. Thus, there is a need to reduce the attack surface of such ZTNA solutions.

[0007] Additionally, deploying deceptions in a network can result in increased network security by diluting the actual hostnames with deceptive hostnames that are announced on the network. However, in practice, it is difficult to deploy such deceptions. For example, it is difficult to scale the number of deceptions in a way that provides adequate security for the network without simultaneously using a large amount of computing resources to host such deceptions. Additionally, when the size of the infrastructure used to manage the honeypots exceeds a relatively small boundary, it becomes difficult to have to manage the honeypots. Furthermore, as the complexity of network topologies continues to increase, the deployment and management of deception solutions becomes increasingly difficult. Furthermore, cloud-delivered security solutions, such as Secure Access Service Edge (SASE) and ZTNA, need to be able to scale the solution across a large number of customers in a way that the actual deceptive nodes are relatively small. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The detailed description is set forth below with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears. The use of the same reference number in different drawings indicates similar or identical items. The systems depicted in the drawings are not drawn to scale, and the components in the drawings may not be drawn to scale with respect to each other.

[0009] Figure 1 A system architecture diagram illustrating an example environment in which a secure access gateway is configured to distribute computation and / or network prioritization to individual flows within a multiplexed session so that ZTNA connects client devices in a remote network with target resources in an enterprise network.

[0010] FIG. 2A to FIG. 2C A system architecture diagram illustrating an example environment in which a client computing device establishes a ZTNA connection with a target resource of a network (eg, an enterprise network, etc.) via one or more authorization nodes (eg, network proxies, network relays, etc.) configured as an authorization chain.

[0011] Figure 3 A system architecture diagram illustrating an example environment for deploying deception at scale in a network with a deception service associated with the network.

[0012] Figure 4 A flow chart illustrating an example method by which a secure access gateway distributes computation and networking prioritization to individual flows within an HTTP / 2 and / or HTTP / 3 multiplexing session of a ZTNA.

[0013] Figure 5A flow chart of an example method for a client computing device to establish a ZTNA connection with a target resource of a network (eg, an enterprise network) via one or more authorization nodes (eg, network proxies, network relays, etc.) configured as an authorization chain is shown.

[0014] Figure 6 A flow chart of an example method for a client computing device to establish a ZTNA connection with a target resource of a network (eg, an enterprise network) via one or more authorization nodes (eg, network proxies, network relays, etc.) configured as an authorization chain is shown.

[0015] Figure 7 A flow chart of an example method for a client computing device to establish a ZTNA connection with a target resource of a network (eg, an enterprise network) via one or more authorization nodes (eg, network proxies, network relays, etc.) configured as an authorization chain is shown.

[0016] Figure 8 A flow chart illustrating an example method for a deception service associated with a network to deploy deception at scale in the network.

[0017] Fig. 9 A flow chart illustrating an example method in which a deception service associated with a network isolates a deception from additional deceptions deployed in the network based on a threshold interaction occurring for the deception.

[0018] Fig.10 is a computer architecture diagram showing an illustrative computer hardware architecture for implementing a server device that can be used to implement aspects of the various techniques presented herein. DETAILED DESCRIPTION

[0019] Overview

[0020] Various aspects of the invention are set out in the independent claims and preferred features are set out in the dependent claims. Features of one aspect may be applicable to each aspect alone or in combination with other features.

[0021] The present disclosure describes a method for prioritizing channels within a multiplexed stream, utilizing authorization chains to reduce the attack surface of (one or more) connections between (one or more) clients and (one or more) network resources, and / or deploying deception at scale in a network. The method includes: establishing a first data stream connection with one or more client devices by a secure access gateway. In some examples, the first data stream connection may include a first hypertext transfer protocol (HTTP) protocol. Additionally or alternatively, the method includes: establishing a second data stream connection with one or more client devices by the secure access gateway. In some examples, the second data stream connection may include a second HTTP protocol different from the first HTTP protocol. Additionally or alternatively, the method includes: determining, by the secure access gateway, first prioritization data associated with the first data stream based at least in part on the one or more client devices. Additionally or alternatively, the method includes: determining, by the secure access gateway, first weighting data associated with the second data stream based at least in part on the second data stream. Additionally or alternatively, the method includes: storing, by the secure access gateway, a first mapping between the first data stream and the first priority value based at least in part on the first prioritization data. Additionally or alternatively, the method includes: storing, by the secure access gateway, a second mapping between the second data stream and the second priority value based at least in part on the first weighted data. Additionally or alternatively, the method includes: determining that the first priority value is more favorable than the second priority value. Additionally or alternatively, the method includes: processing the first data stream before processing the second data stream based at least in part on the first priority value being more favorable than the second priority value.

[0022] Additionally or alternatively, the method includes: establishing, by the secure access gateway, a multiplexed data stream connection with one or more client devices. Additionally or alternatively, the method includes: determining, by the secure access gateway, a first indication of first priority sorting data associated with a first data stream in the multiplexed data stream, the first data stream being associated with a first network protocol. Additionally or alternatively, the method includes: determining, by the secure access gateway, a second indication of first weighted data associated with a second data stream in the multiplexed data stream, the second data stream being associated with a second network protocol different from the first network protocol. Additionally or alternatively, the method includes: storing, by the secure access gateway, a first mapping between the first data stream and the first priority value based at least in part on the first indication. Additionally or alternatively, the method includes: storing, by the secure access gateway, a second mapping between the second data stream and the second priority value based at least in part on the second indication. Additionally or alternatively, the method includes: performing a first operation associated with the first data stream before performing a second operation associated with the second data stream based at least in part on the first priority value being more favorable than the second priority value.

[0023] Additionally or alternatively, the method includes: generating a packet by a first computing device, the packet indicating a request to connect to a target resource. Additionally or alternatively, the method includes: identifying an authorization chain along a network path between the first computing device and the target resource based at least in part on the target resource. In some examples, the authorization chain may include node authorization requirements to be satisfied to connect to the target resource. Additionally or alternatively, the method includes: identifying an authorization credential for satisfying the authorization requirement. Additionally or alternatively, the method includes: generating an encapsulated packet based at least in part on encapsulating the packet with layers corresponding to the authorization credential. Additionally or alternatively, the method includes: sending the encapsulated packet from the first computing device to the target resource via the authorization chain of the node. Additionally or alternatively, the method includes: receiving a first request at the first computing device to authenticate a user with the target resource, the user being associated with the first computing device. Additionally or alternatively, the method includes: sending an authentication credential corresponding to the target resource to the target resource in response to the first request to authenticate the user.

[0024] Additionally or alternatively, the method includes: determining, by the first computing device, a node along a network path between the first computing device and the target resource based at least in part on the target resource, the node including an authorization requirement associated with connecting to the target resource. Additionally or alternatively, the method includes: identifying an authorization credential corresponding to the authorization requirement. Additionally or alternatively, the method includes: generating a packet indicating a request to connect to the target resource, the packet including an encrypted authorization credential corresponding to the authorization requirement. Additionally or alternatively, the method includes: sending the packet from the first computing device to the target resource via the node. Additionally or alternatively, the method includes: receiving a request to authenticate a user with the target resource, the user being associated with the first computing device. Additionally or alternatively, the method includes: sending the authentication credential to the target resource.

[0025] Additionally or alternatively, the method includes: determining, by the first computing device, at least in part based on the target resource, a node along a network path between the first computing device and the target resource, the node including an authorization requirement associated with connecting to the target resource. Additionally or alternatively, the method includes: identifying an authorization credential corresponding to the authorization requirement. Additionally or alternatively, the method includes: storing the authorization credential in a block of a distributed ledger associated with a blockchain network. Additionally or alternatively, the method includes: generating a packet indicating a request to connect to the target resource, the packet including an indication of an address of a block associated with the blockchain network, the blocks including the authorization credential corresponding to the authorization requirement. Additionally or alternatively, the method includes: sending the packet from the first computing device to the target resource via the node. Additionally or alternatively, the method includes: receiving a request to authenticate a user with the target resource, the user being associated with the first computing device. Additionally or alternatively, the method includes: sending the authentication credential to the target resource.

[0026] Additionally or alternatively, the method includes determining, by a deception service associated with the network, a threshold amount of a computing resource type associated with the network. Additionally or alternatively, the method includes performing a dynamic amount of deception of a host computing device to satisfy a threshold amount of a computing resource type associated with the network. Additionally or alternatively, the method includes determining a number of deceptions to be emulated on the network. Additionally or alternatively, the method includes generating a number of deceptions to be emulated on the deception host computing device, the deceptions being associated with a computing resource type. Additionally or alternatively, the method includes storing a first mapping between deceptions and deception host computing devices, the first mapping being based at least in part on a protocol associated with the deception and a computing resource type associated with the deception host computing device. Additionally or alternatively, the method includes deploying the deception to the deception host computing device based at least in part on the first mapping.

[0027] Additionally or alternatively, the method includes: executing, by a deception service associated with a network, a dynamic amount of deception of a host computing device to satisfy a threshold amount of resource type associated with the network, the deception host computing device being configured to emulate a threshold amount of deception on the network. Additionally or alternatively, the method includes: determining that a first device has satisfied a threshold interaction associated with a first deception of deceptions on the network. Additionally or alternatively, the method includes: determining a first Internet Protocol (IP) address associated with the first deception. Additionally or alternatively, the method includes: isolating the first deception from deception based at least in part on the first IP address. Additionally or alternatively, the method includes: determining that an amount of deception on the network is below a deception threshold amount. Additionally or alternatively, the method includes: generating a second deception based at least in part on determining that an amount of deception on the network is below a deception threshold amount, the second deception having the same deception type as the first deception. Additionally or alternatively, the method includes: deploying a second deception to be emulated on the deception host computing device, the second deception being assigned a second IP address different from the first IP address.

[0028] Additionally, the techniques described herein may be performed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the methods described above.

[0029] Example Embodiments

[0030] The present disclosure describes methods for prioritizing individual channels within a multiplexed stream, reducing the attack surface of (one or more) connections between (one or more) clients and (one or more) network resources using authorization chains, and deploying deception at scale in a network. In some examples, a secure access gateway may be configured to establish a multiplexed data stream connection with one or more client devices. In some examples, the secure access gateway may be configured as a VPN, a proxy, an HTTP server, and / or any other system that allows access to resources in a secure manner. Additionally or alternatively, the secure access gateway may employ various protocols, such as Datagram Transport Layer Security (DTLS), Hypertext Transfer Protocol (HTTP) / 2, HTTP / 3, QUIC, and / or any other security protocol. The secure access gateway may be configured to establish a multiplexed connection using ZTNA technology. The secure access gateway may determine an indication of prioritization data and / or weighted data associated with each stream of the multiplexed data stream, wherein the stream may employ different network protocols (e.g., HTTP / 2, HTTP / 3, etc.), and use an indication of the prioritization data and / or weighted data to determine a gateway priority value for the stream. In some examples, the secure access gateway may then store and / or utilize the gateway priority value to process a given flow instead of another flow. Additionally or alternatively, for example, a client computing device may establish a ZTNA connection with a target resource of an enterprise network. In some examples, the ZTNA connection may be established via one or more authorization nodes (e.g., a network agent, a network relay, etc.) configured as an authorization chain, each authorization node being associated with an authorization requirement that requires a specific credential for successfully authorizing a client device at a given authorization node. In some examples, the client device may be configured to generate a packet including one or more authorization credentials, the authorization credentials being configured to satisfy the authorization requirements at the authorization node and authorizing the client device in sequence, and the client device may send a packet through the authorization chain. Once the authorization chain is successfully traversed, the user of the client device may be required to authenticate with the target resource to establish a connection. Additionally or alternatively, a deception service may be used to deploy deception at scale in a network. In some examples, the deception service may communicate with a DNS proxy, a programmable network address translation (NAT) service, and / or a dynamic host configuration protocol (DHCP) agent to deploy deception in a network. The deception service may be configured to determine a threshold amount of a computing resource type associated with a network so that the deception service may perform a dynamic amount of deception of the host computing device to satisfy the threshold amount of the computing resource type. The deception service may determine a number (or percentage) of deceptions to be emulated on the network (e.g., emulation of a protocol utilized by the computing resource type, emulating a virtual machine of the computing resource type, etc.) and generate deceptions. In some examples, the deception service may map deceptions to deception host computing devices based on various protocols associated with the deception host computing devices and deploy the deceptions to the corresponding deception host computing devices.The spoofing service may also assign a large number of IP addresses to a single spoof, making it appear as if many hosts are joining the network when in reality those hosts map back to a small number of actual spoofs.

[0031] As previously described, the secure access gateway can be configured to assign computing and networking priorities to individual flows within an HTTP / 2 and / or HTTP / 3 multiplexing session of the ZTNA. In some examples, the secure access gateway can be configured as a VPN, a proxy, an HTTP server, and / or any other system that allows access to resources in a secure manner. Additionally or alternatively, the secure access gateway can employ various protocols, such as Datagram Transport Layer Security (DTLS), Hypertext Transfer Protocol (HTTP) / 2, HTTP / 3, QUIC, and / or any other secure protocol. Both HTTP / 2 and HTTP / 3 have the ability to perform prioritization of traffic in multiplexed flows. For example, HTTP / 2 includes a built-in relevance weighting value that assigns an integer weight between 1 and 256 to all related flows (e.g., see RFC 7540). Additionally or alternatively, HTTP / 3 includes a priority header field that allows HTTP clients to convey preferences regarding priority (e.g., see RFC 9218). In some examples, these prioritizations can be used to prioritize zero-trust traffic using the multiplexing capabilities of the forward proxy built into both HTTP / 3 (e.g., MASQUE) and HTTP / 3 (e.g., CONNECT method) described herein. In this way, the forward proxy capabilities of HTTP / 3 and HTTP / 2 (e.g., as a fallback when HTTP / 3 is not possible) can be used to deliver ZTNA via a proxy system. In some examples, the HTTP / 2 protocol can be enhanced with the CONNECT-UDP or CONNECT-IP methods found in HTTP / 3 to allow IP, UDP, and TCP to be transported via an HTTP forward proxy as a fallback when UDP:443 cannot traverse the network (e.g., an enterprise that limits outbound traffic to only TCP:443). Using this approach, multiplexed flows can be built on HTTP / 2 or HTTP / 3 via forward proxy technology to achieve ZTNA for the network. Traditionally, the ability to prioritize different traffic in a ZTNA solution has not been possible.

[0032] Using the techniques described herein, forward proxy technology (e.g., implemented via a secure access gateway) may be combined with built-in capabilities to prioritize HTTP / 2 and HTTP / 3 traffic for ZTNA. For example, using built-in relevance weighting and / or priority information provided by HTTP / 2 and / or HTTP / 3, a client may indicate to a ZTNA server what the priority of a given flow is. The ZTNA server may then prioritize computing (e.g., encryption, decryption, proxying, etc.) and / or networking (e.g., routing, forwarding, stream encapsulation, stream decapsulation, etc.) resources to ensure that priority traffic is processed first (by both computing and / or networking resources) before lower priority traffic. That is, these built-in priority and / or weighting information may be mapped back to network prioritization (e.g., quality of service (QoS) bits) or other network prioritization schemes and a CPU, data plane, etc. at a secure access gateway for processing at the secure access gateway.

[0033] There are 1 to 256 possible weighted values ​​in HTTP / 2. Using these built-in weighted values, a gateway priority value (or other form of scoring) can be determined to cover all multiplexed traffic in the forward proxy request for a given ZTNA session. In general, a ZTNA session can handle a subset of access requests compared to a traditional VPN session. In other words, each forward proxy session (or other similar technology) will likely only transmit a small number of access requests for a given proxy session. Therefore, multiple ZTNA proxy NA proxy sessions from a given endpoint will be transmitted in one or more multiplexed sessions. Using the techniques described herein, each proxy session can have a priority independent of the multiplexed stream, so that a given proxy session is given a higher priority than another proxy session using the same weighted concept described for the stream within the multiplexed session. That is, a proxy that is serving many ZTNA sessions from many users can prioritize real-time traffic higher than other traffic types (e.g., web requests) that may not require the same computing and / or network resources, so that all real-time traffic in the entire user session set is given priority over other traffic types (e.g., web requests). In some examples, the endpoint software (e.g., target resource) may also prioritize the reverse network path in the same manner, so that real-time traffic (or other high priority traffic) is processed before lower priority flows in terms of both computing and / or network resources. Additionally or alternatively, because the secure access gateway is handling sessions from many users, the techniques described herein may also allow a given user to have a higher priority than another user if such a system is desired.

[0034] Take a secure access gateway configured to provide secure remote access to target resources to client devices via ZTNA as an example. In some examples, the secure access gateway can establish a multiplexed data stream with one or more client devices. For example, the secure access gateway can establish a first data stream connection with one or more client devices and / or establish a second data stream connection with one or more client devices. In some examples, the first data stream connection may include a first HTTP protocol, such as HTTP / 3. Additionally or alternatively, the second data stream connection may include a second HTTP protocol, such as HTTP / 2. That is, the individual data streams included in the multiplexed data stream may be configured as HTTP / 2 and / or HTTP / 3 connections.

[0035] Once a multiplexing connection is established with one or more client devices, the secure access gateway can be configured to determine an indication of priority sorting data associated with the first data stream of the multiplexed data stream. In some examples, the secure access gateway can determine the priority sorting data based on one or more client devices. That is, one or more client devices can indicate the priority sorting data associated with the first data stream in a priority header field associated with the data packet and / or the connection. Additionally or alternatively, the secure access gateway can be configured to determine an indication of weighted data associated with the second data stream of the multiplexed data stream. In some examples, the secure access gateway can determine the weighted data based on one or more weighted bits associated with the second data stream. That is, the data packet associated with the second data stream connection may include one or more bits indicating the weighted data, as described above. Using the weighted data and / or priority data determined for the data stream, the secure access gateway can map each weighted data and / or priority data to a gateway priority value at the secure access gateway.

[0036] For a given data stream of a multiplexed data stream, the weighted data and / or priority data may indicate the type of network traffic associated with the data stream. In some examples, the secure access gateway may determine a gateway priority value based on the type of network traffic. For example, the priority data associated with the first data stream may indicate that the first data stream is associated with a web request, and the weighted data associated with the second data stream may indicate that the second data stream is associated with real-time traffic. In this scenario, the secure access gateway may be configured to assign a more favorable gateway priority value to the second data stream based on the priority ranking of real-time traffic being higher than web request traffic. In some examples, the secure access gateway may determine a gateway priority value based on a policy enforced at the secure access gateway. In some examples, the policy may indicate a gateway priority value associated with a given network traffic type, wherein the traffic type may be determined based on a data stream, a client device, a target resource, weighted data, and / or priority ranking data. Additionally or alternatively, the policy may indicate which built-in weighted values ​​of HTTP / 2 are more favorable than the priority ranking data associated with HTTP / 3. Additionally or alternatively, the policy may indicate that particular users and / or roles associated with particular users should be prioritized over other users and / or roles.

[0037] For example, the secure access gateway may determine that the prioritization data associated with the first data stream is mapped to the first gateway priority value, and the weighted data associated with the second data stream is mapped to the second gateway priority value. In some examples, the gateway priority value may be configured as an integer, and the secure access gateway may be configured to prioritize one stream higher than another stream based on the associated gateway priority value. Additionally or alternatively, the gateway priority value may be represented by one or more QoS bits. Consider an example in which the prioritization data associated with the first stream is mapped to the first gateway priority value 2, and the weighted data associated with the second stream is mapped to the second gateway priority value 5. The secure access gateway may determine that the second gateway priority value is more favorable than the first gateway priority value based on the second gateway priority value being greater than the first gateway priority value. Then, based on the second gateway priority value being more favorable than the first gateway priority value, the secure access gateway may process (e.g., perform encryption processing, decryption processing, proxy processing, routing processing, forwarding processing, encapsulation processing, decapsulation processing and / or any other form of computing and / or network processing) the second data stream before processing the first data stream.

[0038] Additionally or alternatively, the secure access gateway may include a priority data store in which gateway priority values ​​may be stored. For example, the secure access gateway may store a first mapping between a first flow (and / or priority sorting data) and a first gateway priority value and / or a second mapping between a second flow (and / or weighting data) and a second gateway priority value. In some examples, the secure access gateway may send an indication of the gateway priority value(s) to the associated target resource(s) and / or client device(s), where each respective device may utilize the gateway priority value to prioritize flows (e.g., in opposite directions).

[0039] The secure access gateway may then determine a target resource associated with a given data stream of the multiplexed data stream. For example, the secure access gateway may determine a target resource associated with a second data stream and establish a third data stream connection between the secure access gateway and the target resource. In some examples, the third data stream may include a QUIC protocol, a UDP protocol, and / or a transmission control protocol (TCP). The secure access gateway may then be configured to process network traffic associated with the second data stream and / or transmit it to a target resource before processing network traffic associated with the first data stream and / or transmitting it to a target resource and / or an additional target resource. As previously described, the secure access gateway may determine one or more QoS bits indicating and / or representing a gateway priority value, and send the one or more QoS bits to a target resource so that network traffic traveling in the opposite direction (e.g., from a target resource to a client device) is prioritized in the same manner.

[0040] As previously described, a client computing device can establish a ZTNA connection with a target resource of an enterprise network, for example, via one or more authorization nodes (e.g., network proxies, network relays, etc.) configured as a chain of authorizations. For example, one or more relays can be used to effectively route traffic to proxy nodes and / or VPN nodes such that each relay authorizes a connection to the next stage. In some examples, this approach uses a chain of relays and authorization tokens to allow access to the next hop in the network. Various implementations utilizing relays and / or token chains are described in more detail below.

[0041] In some examples, the MASQUE protocol can be used to create an authorization chain for a client device to access a target resource. Take a two-stage authorization chain (e.g., two nodes requiring authorization) as an example. The first stage can be a first node configured as a relay, which requires a first authorization credential (also referred to herein as an authorization token, a bearer token, etc.), for example, a privacy pass token. The first node can enforce a coarse-grained device-level access policy before proceeding to the next stage in the chain. If the first stage in the authorization chain is successfully traversed, the second stage may require a second authorization credential. For example, the second stage can be a second node configured as a proxy that requires a second authorization credential (e.g., a client certificate). In order to relay the session to the target destination, the second node may require the presentation of a client certificate. In this scenario, resource access permission is completed in the second stage via a token different from the first stage. Therefore, the above-mentioned token chain contains two links, which are first satisfied by a confidentiality pass and then satisfied by a client certificate. This implementation of the authorization chain is referred to as an onion layer encapsulation in this article.

[0042] By configuring the authorization chain in this way, unauthorized devices cannot even access the second node configured as a proxy for the target resource. Once the proxy is accessed, only authorized users can access the target resource. In some examples, packets can be encapsulated with layers corresponding to the authorization stage, where each layer in the sequence can be encrypted and can transmit the authentication token required to continue to the next stage. That is, each layer can have its own encryption and authentication components for that layer. This is referred to as onion routing in this article, where each layer is conceptualized as an onion layer. If the policy is satisfied at the previous layer, each layer in the onion can be exposed (for example, after satisfying the first stage by presenting the first layer including the privacy pass token, the second layer including the client certificate can be exposed). Ultimately, the onion layers can be traversed until the core (e.g., the target resource) is accessed only after the policies required for each outer layer are satisfied.

[0043] As previously described, the encapsulation packet may include two layers: a first outer layer including a privacy pass token and a second inner layer including a client certificate. In addition, a third innermost layer may be conceptualized. For example, the third inner layer may correspond to a single sign-on (SSO) user credential for accessing a target resource. That is, once the first two stages are satisfied by the corresponding authorization credentials, the third and final stage may be accessed at the target resource, where the user may be required to provide SSO user credentials to access the target resource. In such an example, all three stages of the authorization chain will need to be included in order for unauthorized users to access the target resource. Although example authorization credentials are described, any non-user interaction credential (e.g., a privacy pass token, a client certificate, and / or any other type of authorization credential) and / or any user interaction credential (e.g., an SSO user credential, a biometric credential, etc.) may be utilized at any stage in the authorization chain.

[0044] Additionally or alternatively, the authorization chain can be configured with a single encryption layer between the target resource and the client device. In such an example, the authorization chain can be embedded in the flow at the beginning of the traffic as metadata. This can be implemented using various encapsulation protocols (e.g., Generic Network Virtualization Encapsulation (GENEVE), Generic Routing Encapsulation (GRE), Generic UDP Encapsulation (GUE), Proxy Protocol, etc.). This implementation of the authorization chain is referred to herein as a single encrypted embedded encapsulation.

[0045] In such a configuration, each authorization token may be transmitted as a link within a chain. In some examples, it may not be required to place the authorization tokens sequentially in sequence (as opposed to the onion routing example described above, where the packets are encapsulated with each layer in an order corresponding to the authorization chain). Additionally or alternatively, it may provide a computational improvement to order the authorization tokens in sequence, avoiding the need to analyze the entire chain for matching tokens. Each token may be encrypted in such a way that only nodes associated with the token (e.g., nodes enforcing the authorization phase) can decrypt the token. The encryption may be performed using any encryption protocol (e.g., Hybrid Public Key Encryption (HPKE), etc.).

[0046] In some examples, the authorization credentials (e.g., bearer tokens) may not be presented in-band with the flow. In such a scenario, the protocol may indicate that the token is to be received out-of-band and how the flow is to be associated with a given out-of-band authentication and authorization. As described above, there may not be a requirement to configure the tokens in order. In addition, as tokens are processed, they may be removed from the chain of tokens by the node in the authorization chain that processed the token. Additionally or alternatively, a bit in the payload may be configured to be modified by the node in the authorization chain that processed the token to indicate that the token has been exhausted.

[0047] Additionally or alternatively, a token chain may be implemented using blockchain technology. That is, authorization tokens may be stored in one or more blocks of a distributed ledger associated with a blockchain network. In some examples, each block may store an encrypted token, and the block may be required to satisfy the policy requirements of a given node in order to traverse to the next node in the authorization chain. Additionally or alternatively, each block may store a hash of a previous block header so that a given block can verify that the policy requirements at the previous node are satisfied by computing the hash. This implementation of the authorization chain is referred to herein as a single encrypted blockchain encapsulation.

[0048] Take, for example, a user of a client computing device attempting to establish a ZTNA connection to a target resource. The network path between the client computing device and the target resource may include an authorization chain comprising one or more nodes, the one or more nodes including authorization requirements to be satisfied to connect to the target resource. The nodes may be configured as proxy nodes, relay nodes, etc. In some examples, as previously described in the onion layer encapsulation implementation of the authorization chain, the client computing device may generate a packet encapsulated with an encryption layer of authorization credentials configured to satisfy the authorization requirements associated with the nodes.

[0049] The client computing device may be configured to generate a packet indicating a request to connect to a target resource. In some examples, the client computing device may identify an authorization chain based at least in part on the target resource. That is, the client computing device may identify individual nodes and authorization requirements associated with the individual nodes. Once the authorization chain is identified, the client computing device may identify an authorization credential that will be used to satisfy the authorization requirements associated with the nodes of the authorization chain. In some examples, the authorization credential may be stored on the client computing device and / or remotely stored in a data store accessible by the client computing device.

[0050] The client computing device may also be configured to generate an encapsulated packet by encapsulating previously generated packets with various encryption layers including authorization credentials. In some examples, the client computing device may determine the order of nodes in the authorization chain (e.g., the order of nodes to be traversed on the network path to the target resource). The client computing device may utilize the order of the nodes to generate an encapsulated packet by encapsulating the packet with encryption layers according to the order of the nodes. That is, the outermost encryption layer of the encapsulated packet may include a first authorization credential, which is used to satisfy the first authorization requirement associated with the first node to be accessed in the authorization chain. Additionally or alternatively, the innermost encryption layer of the encapsulated packet may include a second authorization credential, which is used to satisfy the last authorization requirement associated with the last node to be accessed before the target resource in the authorization chain. In some examples, the authorization chain may include any number of nodes from 1 to N, where N may be any integer greater than 1. Additionally or alternatively, the encapsulated packet may include any number of encryption layers from 1 to N, where N may be any integer greater than 1.

[0051] Using the generated encapsulated packet, the client computing device can be configured to send the encapsulated packet to the target resource via the authorization chain of the node. For example, the client computing device can send the encapsulated packet to the first node of the authorization chain. The first node can consume the authorization credential associated with the outermost encryption layer. That is, the first node can be configured to decrypt the outermost encryption layer and access the authorization credential included therein. In some examples, the consumption of the authorization credential may cause the first node to remove the outermost encryption (or encapsulation) layer, leaving the second encryption layer as the new outermost encryption layer after consumption. Additionally or alternatively, the authorization credential associated with a given encryption layer can be configured as an interactive authorization credential (e.g., requiring a user of the client computing device to perform some interaction) or a non-interactive authorization credential (e.g., a confidential pass, a client certificate, and / or any other form of authorization token). In an example where the authorization credential is configured as an interactive authorization credential, the corresponding node can return instructions for satisfying the interactive authorization credential to the client computing device.

[0052] After traversing the authorization chain of nodes and satisfying the corresponding authorization requirements at each node, the target resource can send a request to authenticate the user associated with the client computing device with the target resource. The client computing device can display the authentication request to prompt the user for necessary input. Once the user provides input of the authentication credentials to the client computing device, the client computing device can send an authentication response including the authentication credentials to the target resource, where the user can be authenticated with the target resource and a connection can be established.

[0053] Additionally or alternatively, the authorization chain can be configured with a single encryption layer between the client computing device and the target resource, as previously described with respect to the single encryption inline package and / or (one or more) single encryption blockchain embodiments. That is, the authorization chain can be configured such that it is embedded in the flow at the beginning of the traffic as metadata. The authorization chain can include one or more nodes that contain authorization requirements to be satisfied in order to connect to the target resource. As previously described, the nodes can be configured as proxy nodes, relay nodes, etc.

[0054] In some examples, the client computing device can be configured to determine nodes along a network path (e.g., an authorization chain of nodes) between the first computing device and the target resource based on the target resource. Each of the nodes may include authorization requirements that are required to be satisfied before proceeding to the next node. Once the nodes along the network path are identified, the client computing device can identify authorization credentials that will be used to satisfy the authorization requirements associated with the nodes along the network path. In some examples, the authorization credentials can be stored on the client computing device and / or stored remotely in a data store accessible by the client computing device.

[0055] The client computing device may also be configured to generate a packet indicating a request to connect to a target resource. In some examples, the packet may include an authorization credential corresponding to the authorization requirement. Additionally or alternatively, each authorization credential may be encrypted using an encryption type corresponding to the node that includes the associated authorization requirement. That is, the authorization credential may be encrypted in such a way that only the node that includes the corresponding authorization requirement may be configured to decrypt the corresponding authorization credential.

[0056] Additionally or alternatively, the client computing device may be configured to store the identified authorization credentials in a block of a distributed ledger associated with the blockchain network. The client computing device may then generate a packet indicating a request to connect to a target resource. In some examples, the packet may include an indication of an address of a block associated with the blockchain network. That is, the respective authorization credentials may be stored in respective blocks of the blockchain network and may be accessed via the address. Additionally or alternatively, each authorization credential may be encrypted using an encryption type corresponding to a node including an associated authorization requirement. That is, the authorization credential may be encrypted in such a manner that only a node including a corresponding authorization requirement may be configured to decrypt the corresponding authorization credential.

[0057] Using the generated packet, the client computing device can be configured to send the packet to the target resource via the nodes along the network path. For example, the client computing device can send the packet to the first node in the node. The first node can consume the authorization credential configured to meet the corresponding authorization requirements. That is, the first node can be configured to decrypt and access the authorization credential included therein. In some examples, the consumption of the authorization credential may result in modifying at least one bit in the packet indicating that the authorization credential has been exhausted. Additionally or alternatively, a subsequent node receiving the packet can check the bit indicating that the previous authorization credential has been exhausted before decrypting the next authorization credential. In an example where the authorization credential is stored in a block of a blockchain, the node can modify the hash of the block to indicate that the corresponding authorization credential has been exhausted, and the subsequent node can use the next block to confirm that the previous authorization credential has been exhausted. For example, the node can check the block header for the hash of the previous block to determine that the previous authorization credential has been exhausted. Additionally or alternatively, the associated authorization credential may be configured as an interactive authorization credential (e.g., requiring some interaction by a user of the client computing device) or a non-interactive authorization credential (e.g., a confidentiality pass, a client certificate, and / or any other form of authorization token). In examples where the authorization credential is configured as an interactive authorization credential, the corresponding node may transmit instructions for satisfying the interactive authorization credential back to the client computing device.

[0058] After traversing the nodes along the network path and satisfying the corresponding authorization requirements at each node, the target resource can send a request to authenticate the user associated with the client computing device with the target resource. The client computing device can display the authentication request to prompt the user for necessary input. Once the user provides input of the authentication credentials to the client computing device, the client computing device can send an authentication response including the authentication credentials to the target resource, where the user can be authenticated with the target resource and a connection can be established.

[0059] As previously described, a deception service can be used to deploy deception at scale in a network. For example, a deception service can utilize and / or be composed of a DNS proxy, a NAT service, and / or a DHCP monitor / proxy, wherein the DNS proxy is configured to make it appear as if many hosts are joining the network, the NAT service is configured to dynamically convert network traffic to and from the deception hosts, and the DHCP monitor / proxy is configured to consume and release IP addresses in the network as needed. The deception service and / or its components are described in more detail below.

[0060] The deception service can be configured so that a small number of deception hosts will actually exist. In some examples, the deception service can configure the deception hosts with enough hosts to cover all operating systems (OS) and / or components typically found in a network data center (e.g., an enterprise data center), such as active directories, domain servers, web servers, directory servers, application servers, file servers, OS servers, database servers, etc. For example, there will be a small pool of active directory server deceptions. Initially, a configurable amount of each deception type will be started on physical, virtual, and / or container hosts. In some examples, each of these options can be policy-driven (e.g., a configurable amount of each deception type, host type, etc.). This configuration can be driven by a deception service provider (e.g., a SASE provider) rather than by individual customers using the deception service. Options can be used to allow customers to match custom deceptions that can be modified to their enterprise environment and place these custom deceptions in a customer-specific pool. For example, a customer may want to deploy an active directory deception that more closely matches their enterprise configuration. Additionally or alternatively, deception can be a mix of actual systems and simulations. In some examples, where possible, simulation of the protocol is used instead of hosting the actual service. For example, an SSH emulator will be sufficient to attract attackers while at the same time producing a low false positive detection rate, thereby saving computing resources. In addition, physical hosts can be used and reserved for attacks on physical host types that cannot be virtualized or containerized for technical reasons.

[0061] As previously described, the deception service can utilize a DHCP agent (or an instance thereof) and / or a programmable NAT service. Once the initial deception is deployed, they can interact with the DHCP agent. The DHCP agent instance can proxy DHCP requests to the customer network (bidirectionally). In some examples, the policy can allow customers to choose how many deceptions they want to simulate on the network using the DHCP agent. Additionally or alternatively, the DHCP agent can be configured so that when in fact all hosts are mapped back to a small set of actual deceptions, it will appear as if many hosts are joining the customer's network. The percentage of unused network addresses can be configurable so that deception can use N percent of the available address space, where N can be any percentage between 0 and 100, including 0 and 100. This is referred to as deception density in this article. In this way, customers can use 100% of the unallocated network IP addresses for deception. For example, customers can choose any density they want as a percentage of available network addresses. In some examples, this can be done for each subnet with a different value.

[0062] Additionally or alternatively, the DHCP proxy can be configured to remove spoofed hosts from the client network when real hosts want network addresses and the available network address pool is exhausted (e.g., all IP addresses are allocated) and / or the spoof density is exceeded. In this way, the spoofing service can dynamically assign network addresses to spoofs without changing the actual number of spoofed hosts. Instead, multiple IP addresses are mapped to the same spoofed host.

[0063] In some examples, a programmable NAT service can be utilized in conjunction with a DHCP proxy to dynamically map NAT network traffic to and from an actual spoofed host back to an assigned DHCP proxy address. For example, if 50 unique DHCP addresses are mapped to a single spoofed host, the NAT service can be configured to map and convert 50 entries to a single actual node at different addresses. Assuming that a malicious user or network attacker typically moves laterally within the network, the assigned DHCP address is provided to the spoof. This allows the spoofed host to be accessed by lateral movement using an assigned DHCP address rather than a NAT address. This ensures that accesses completed without using a domain name service (DNS) (e.g., a simple IP hub) are also addressed using the techniques described herein.

[0064] As mentioned above, the spoofing service can also utilize a DNS proxy. The DNS proxy can be configured to return an assigned IP address in the form of an algorithm, which is associated with a DHCP / NAT system value assigned to a host name that does not actually exist in the network. This makes it appear as if the host actually exists when it does not actually exist. The client can configure the percentage of non-existent domains (NXDOMAIN), NODATA, and / or NAT IP address responses for a given host name query. For example, a network administrator can configure a spoofing service to randomly return 30% to 50% NXDOMAIN responses to non-existent hosts, otherwise return NATIP. Therefore, such a configuration can increase the authenticity of the spoofing service by not always appearing as if the host exists when the host does not exist.

[0065] Additionally or alternatively, stickiness can be used so that when a service answers a host name query, the service can continue to return the same answer for a configurable amount of time (e.g., any number of minutes, hours, days, weeks, etc.). By configuring the deception service to implement the stickiness function, a non-existent host may appear to be real to an attacker for a configurable amount of time (e.g., one day). That is, if an attacker requests the same host name for a configurable amount of time, the same answer can be returned instead of another NAT IP. In some examples, any mixture of responses can be configured, including using machine learning (ML) and / or artificial intelligence (AI) methods to decide when to respond with a deceptive host and when to respond with an indicator that the host does not exist (e.g., NXDOMAIN, NODATA, etc.). In this way, a malicious user who performs a directory scan on a host name only gets an answer sometimes, which may seem more realistic than always answering affirmatively (e.g., always returning the host). In addition, as previously described, a customer can configure the deception service to always assert that a non-existent host name exists and return a deceptive address from the NAT service.

[0066] The DNS proxy can be configured to be resilient to accidental user errors. In this way, a dictionary system will be used to verify that similar domains do not exist on the network, which may be a simple user error when entering a domain. ML and / or AI techniques can also be used to determine what may be a user input error rather than an attack method by a malicious user attacker. For example, adjacent keys are often entered on the query keyboard of a domain. Additionally or alternatively, it can be expected that a user may accidentally type a web address. For example, if a user attempts to access "www.mydomain.com", the user may accidentally type "www.mydomian.com" or something similar. That is, the spoofing service can be configured to exploit some form of typosquatting or other detection method for this scenario.

[0067] Additionally or alternatively, spoofing may be desirable for actual domains on the network. For example, SSH may be a common protocol that attackers interact with. The real SSH host may be "ssh.mycompany.com". In some examples, an enterprise may set a policy that SSH is only available over a tunneled connection. In this scenario, the network access method may play a role in whether a valid DNS result for a given host is returned. This may be configured by the enterprise and / or network owner. For example, if a DNS query for a host is not connected via a VPN or ZTNA, a spoofed response may be returned, and the spoofs in the pool will occupy NAT addresses and DHCP addresses on the network. The DHCP agent may be configured to ensure that name conflicts for the host do not occur.

[0068] As described herein, a deception service can be configured so that it can consider networked scans or probes that are insufficient to determine that a network attack is being performed. For example, a user who accidentally mistypes a domain name may not trigger the deception service, as previously described. Similarly, a vulnerability scanner may scan and probe in a manner that does not have prior knowledge of the systems available on the network. A scanner that uses a dictionary to try different domains will likely create interactions with the deception. In this way, the deception service can be configured to ensure that significant engagement (e.g., a threshold interaction) occurs before isolating a deceptive host as part of an attacker's workflow.

[0069] Additionally or alternatively, the deception service may also be configured to ensure that sufficient attacker interaction (e.g., a threshold interaction) has occurred with a deception from the pool. Once a deception has received enough engagement to determine that something other than a network scan is occurring, the deception may be removed from the pool and bound to the assigned NAT and DHCP addresses as if it were an actual host on the network. At this point, a new deception of the same type may be added to the pool to replace the deception that was isolated for the purpose of engaging the attacker. From here, the attacker may engage the deception, and normal deception detection techniques may be used to alert that an active attack is ongoing (e.g., sending an alert to a network administrator). It may be assumed that once a threshold interaction occurs, deception techniques may take over to catch the attacker.

[0070] For example, SSH can be a common attack vector. A real SSH host in the network may be "ssh.mycompany.com". The deception service can be configured to intelligently handle typical squatting domain type user errors so that closely related domain names do not result in deception interactions, but instead return the expected NXDOMAIN response to the user. Additionally or alternatively, the host "ssh.finance.mycompany.com" may be an example of something that a user would not be likely to mistype when attempting to access "ssh.mycompany.com", a domain name that is not a squatting type error can certainly respond to deception from the pool. However, this alone may not be enough for the deception service to remove the deception from the deception pool to complete the attacker participation cycle. What may be required as a threshold interaction is a successful authentication with an SSH server using legitimate credentials within the enterprise. Once this threshold interaction is achieved, the deception service can remove the deception host from the pool and assign NAT and DHCP addresses as part of the participation. New deceptions of the same type can be added to the pool to replace deceptions that have been isolated from attackers. By configuring the deception service with this just-in-time (JIT) deception creation, a very small amount of resources can be used to provision a complete network of deceptions in a manner that can be dynamically adapted as an attacker engages in a given deception. Once the attacker completes their engagement and the deception service senses no network activity with the deception host, the deception is either shut down or returned to the pool based on this configuration (e.g., based on deception density, number of actual hosts joining the network, etc.).

[0071] Take a network (e.g., an enterprise network) with a host computing device configured to host various services and / or resources of the network as an example. A service provider can provide a deception service for deploying deceptions in the network in proportion according to the technology described herein. Deception can be configured to simulate a virtual machine of a computing resource type (or a protocol associated with a computing resource type) associated with the network. The deception service can allocate one or more IP addresses from an available IP address pool associated with the network to the deception, making it appear as if a large number (e.g., hundreds, thousands, millions, etc.) of hosts are connected to the network when the IP address is actually mapped back to a small number (e.g., 5, 10, 15, etc.) of deceptions. That is, the deception service can be configured to maintain the deception density on the network as a percentage (e.g., 70%, 80%, 90%, etc.) of hosts configured to be deceiving, rather than the actual host. The configuration of the deployment of deceptions in the network can be configured by one or more policies via a network user (e.g., a network administrator). Although example numbers and / or percentages of deceptions are provided, these numbers / percentages are used for exemplary purposes and any number / percentage can be configured.

[0072] In some examples, the deception service can be configured to determine a threshold amount of computing resource types associated with the network. For example, the deception service can determine that there are 8 different computing resource types that include different functions and / or protocols. In this way, the deception service can execute a certain amount of deception host computing devices to meet the threshold amount of computing resource types associated with the network. For example, the deception service can execute 8 deception host computing devices, each deception host computing device corresponding to a different computing resource type associated with the network. In some examples, the execution of the deception host computing devices can be dynamic, in that the deception service can execute more and / or fewer deception host computing devices as computing resource types are added to the network and / or removed from the network.

[0073] The deception service may then determine the number of deceptions to be emulated on the network. For example, each of the deception host computing devices may be configured to provide functionality and / or protocols associated with a computing resource type in the network, and the deception may be configured to emulate various services provided by the computing resource type (e.g., providing different functionality and / or utilizing different protocols). The deception service may generate the number of deceptions to be emulated on the host computing device. As previously described, the deceptions may be associated with the computing resource types in the network. The deception service may then store a first mapping between the deceptions and the deception host computing devices. In some examples, the first mapping may be based at least in part on the protocols associated with the deceptions and / or the computing resource types associated with the deception host computing devices.

[0074] Additionally or alternatively, the deception service may allocate multiple IP addresses in the network to a single deception in the network. In some examples, the deception service may determine the percentage of deceptions to be simulated on the network (e.g., the density of deceptions in the network compared to real hosts). The deception service may utilize a policy to determine the percentage of deceptions to be simulated. For example, a network administrator associated with a network may configure a policy indicating the density of deceptions at the network so as to maintain on the network when possible, for example, 90% of the hosts are deceptions in the network, while the remaining 10% are actual hosts in the network. That is, the deception service may maintain a pool of available IP addresses associated with the network. When actual hosts join and / or leave the network, the deception service may allocate and / or de-allocate IP addresses to the actual hosts. Additionally or alternatively, the deception service may allocate available IP addresses to deceptions on the network to meet the density of deceptions. For example, if 7% of the IP addresses are currently being used by actual hosts on the network, the deception service may be configured to allocate 90% of the IP addresses to the deceptions and not allocate the remaining 3%. Additionally or alternatively, if the policy indicates that 95% of the hosts should be spoofs and 7% have been assigned to actual hosts, the deception service may assign 93% of the IP addresses to the spoofs. In some examples, when the actual hosts are disconnected from the network (e.g., outside of business hours), the deception service may reuse the IP addresses previously assigned to the actual hosts to the spoofs until the threshold density is met. When the actual hosts return online, the deception service may then release the IP addresses from the spoofs as needed and assign them to the actual hosts. The deception service may store a second mapping between the IP addresses in the network and the spoofs. The deception service may then deploy the spoofs to the spoof host computing devices based at least in part on the first mapping and / or the second mapping.

[0075] Once deception is deployed in the network, the deception service can begin monitoring the deception activity. In some examples, a DNS proxy associated with the deception service can receive a request for a host name and forward the request to the DNS server of the network. The DNS server can respond in one of a variety of ways (e.g., the host name of the actual host in the network, NXDOMAIN response, NODAT response). The deception service can also be configured by a policy associated with the network, for example, configuring the percentage of NXDOMAIN and / or NODATA responses (e.g., requests associated with non-existent host names) to return a deception IP address. In some examples, the DNS proxy of the deception service can receive a response indicating that the requested host is a host that does not exist in the network. Based on the configuration of the deception service, the deception service can then request a NAT IP (e.g., mapped to a deception IP address) from a programmable NAT service. The NAT service can then get deception from an IP address pool, where a DHCP agent can be configured to manage the allocation of IP addresses to deception and / or actual hosts and / or release of IP addresses from deception and / or actual hosts, as described above. The NAT service may then map the NAT to an IP address in the network and return the NAT IP to the DNS proxy, where a connection to the corresponding spoofed host computing device hosting the spoof may be established.

[0076] The deception service can then determine that a connection with the first deception host computing device has been established. The deception service can be configured to determine a first IP address associated with the connection, and based on a second mapping between the IP address and the deception, the deception service can identify a first deception associated with the first IP address. From this point on, the deception service can be configured to not take action until a threshold interaction occurs with the first deception (e.g., an exchange of authentication data, an exchange of authorization data, an exchange of credentials, an SSH connection, etc.). That is, the deception service can identify an interaction associated with the first deception and determine whether the interaction meets a threshold interaction for isolating the deception. If the interaction meets the threshold, the deception service can isolate the first deception from the deception (e.g., containerize), where the interaction can be further monitored by the deception service, and / or deception techniques can be employed by the deception service and / or the deception technology service to attract the attacker to further interact with the deception.

[0077] In the event that the first deception is isolated from the other deceptions, the deception service may generate a new deception of the same type as the isolated first deception and / or associated with a computing resource type of the deception host on which the first deception is executing. The IP address previously assigned to the first deception may now be assigned to the new deception (and, if necessary, to additional IP addresses to reach a deception threshold density), and the second mapping between IP addresses and deceptions is updated to reflect the new deception. The new deception may then be deployed to the deception host computing device based on the updated second mapping.

[0078] As described herein, computing-based and / or cloud-based solutions, services, and / or resources may generally include any type of resource implemented by virtualization technology, such as containers, virtual machines, virtual storage, etc. In addition, although the described techniques are described as being implemented in a data center and / or cloud computing network, the described techniques are generally applicable to any network of devices managed by any entity in which virtual resources are configured. In some instances, the described techniques may be performed by a scheduler or orchestrator, and in other examples, various components may be used in a system that performs the techniques described herein. The devices and components that perform the techniques described herein are a matter of implementation, and the described techniques are not limited to any particular architecture or implementation.

[0079] The techniques described herein provide various improvements and efficiencies with respect to ZTNA solutions and network security. For example, the techniques described herein may allow for prioritization of flows with different protocols (e.g., HTTP / 2 and / or HTTP / 3) within a multiplexed connection using ZTNA. By determining a priority value at a secure access gateway, HTTP / 2 weighted data and / or HTTP / 3 prioritization data may be utilized to determine which flow to process (e.g., compute and / or network process) first. In addition, by configuring an authorization chain of nodes between a client device and a target resource, the security of a ZTNA solution may be greatly increased by enforcing individual authorization requirements at each node along the authorization chain prior to authentication at the target resource. In this manner, the attack surface of a ZTNA connection may be reduced because an attacker may not be able to reach the authentication stage unless they are able to provide one or more authorization credentials at a specific node along the network path. In addition, by mapping a large number of IP addresses to a threshold number of deceptions that satisfy many types of computing resources of the network, deceptions may be deployed in proportion in the network while retaining a large number of actual computing resources. In addition, security in the network may be greatly increased. For example, a network can be configured such that 90% of IP addresses (or hostnames) map to spoofs, while 10% map to actual hosts in the network. In this way, an attacker essentially has to play a guessing game when attacking the network. Additionally, if a threshold interaction (e.g., authorization, authentication, SSH connection, and / or any other credential exchange) occurs relative to the spoof, the spoof can be isolated, where the attacker can continue to interact with the spoof, thereby delaying any subsequent attacks by the attacker. Furthermore, after any interaction with the spoof, the spoof service can configure the spoof to maintain the same IP address for a configurable amount of time, resulting in consistent responses to hostname requests and making the spoof appear as if it were a real host in the network, which also increases the security of the network.

[0080] Certain implementations and embodiments of the present disclosure will now be described more fully below with reference to the accompanying drawings, in which various aspects are shown. However, various aspects can be implemented in many different forms and should not be construed as being limited to the implementations set forth herein. As described herein, the present disclosure encompasses variations of the embodiments. Similar reference numerals refer to similar elements throughout.

[0081] Figure 1A system architecture diagram of an example environment 100 is shown in which a secure access gateway 102 is configured to assign computation and / or network prioritization to individual flows within a multiplexed session so that ZTNA connects a client device 104 associated with a remote network 106 to a target resource 108 of an enterprise network 110. The environment 100 may include one or more networks 112 in which the secure access gateway 102 may be deployed. In some examples, the networks 112 may include one or more cloud networks, wide area networks (WANs), software defined WANs (SDWANs), etc. Additionally, Figure 1 An example process is shown in which the secure access gateway 102 establishes a multiplexed connection with one or more client devices 104, determines gateway priority values ​​associated with individual flows of the multiplexed flows, and provides ZTNA access to the one or more client devices 104 to the target resource 108 while prioritizing the flows based on the corresponding gateway priority values.

[0082] In some examples, the network(s) 112, the remote network 106, and / or the enterprise network 110 may include one or more data centers, including various network components, such as (one or more) network switches (also referred to as (one or more) nodes) operating on physical servers. In some examples, the physical server(s) may host one or more virtual machines. Each virtual machine may be configured to perform one of various operations and act as one or more virtual components of the network(s) 112, such as the secure access gateway 102 and / or the DNS proxy / forwarder 114 associated with the secure access gateway 102. In some examples, the physical server(s) may host any number of virtual machines. In some examples, the physical server(s) in the enterprise network may host various network components of the enterprise network, such as the target resource 108.

[0083] Take, for example, a secure access gateway 102 service (or a node executing a QUIC proxy service) configured to provide secure remote access to a target resource 108 to a client device 104 via ZTNA. The QUIC proxy 102 may be configured to assign computational and networking prioritization to individual flows within an HTTP / 2 and / or HTTP / 3 multiplexing session of the ZTNA. In some examples, the secure access gateway 102 may include one or more VPN technologies, proxy technologies, and the like. Additionally or alternatively, the secure access gateway 102 may employ various protocols, such as Datagram Transport Layer Security (DTLS), Hypertext Transfer Protocol (HTTP) / 2, HTTP / 3, QUIC, and / or any other secure protocol. Both HTTP / 2 and HTTP / 3 have the ability to perform prioritization on traffic in a multiplexed stream. For example, HTTP / 2 includes a built-in relevance weighting value that assigns an integer weight between 1 and 256 to all relevant flows (e.g., see RFC 7540). Additionally or alternatively, HTTP / 3 includes a priority header field that allows HTTP clients to communicate preferences regarding priorities (e.g., see RFC 9218). In some examples, these prioritizations can be used to prioritize zero-trust traffic using the multiplexing capabilities of the forward proxy built into both HTTP / 3 (e.g., MASQUE) and HTTP / 3 (e.g., CONNECT method) described herein. In this way, the forward proxy capabilities of HTTP / 3 and HTTP / 2 (e.g., as a fallback when HTTP / 3 is not possible) can be used to deliver ZTNA via a proxy system. In some examples, the HTTP / 2 protocol can be enhanced with the CONNECT-UDP method found in HTTP / 3 to allow fallback when UDP:443 cannot traverse the network (e.g., an enterprise that limits outbound traffic to only TCP:443). Using this approach, multiplexed flows can be built on HTTP / 2 or HTTP / 3 via forward proxy technology to achieve ZTNA of the network. Traditionally, the ability to prioritize different traffic in a ZTNA solution is not possible.

[0084] Using the techniques described herein, forward proxy technology (e.g., implemented via the secure access gateway 102) may be combined with built-in capabilities to prioritize HTTP / 2 and HTTP / 3 traffic for ZTNA. For example, using built-in relevance weighting and / or priority information provided by HTTP / 2 and / or HTTP / 3, a client may indicate to a ZTNA server what the priority of a given flow is. The ZTNA server may then prioritize computing (e.g., encryption, decryption, proxying, etc.) and / or networking (e.g., routing, forwarding, stream encapsulation, stream decapsulation, etc.) resources to ensure that priority traffic is processed first (by both computing and / or networking resources) before lower priority traffic. That is, these built-in priorities and / or weighting information may be mapped back to network prioritization (e.g., quality of service (QoS) bits) or other network prioritization schemes and CPUs, data planes, etc., for processing at the secure access gateway 102.

[0085] There are 1 to 256 possible weighting values ​​in HTTP / 2. Using these built-in weighting values, a gateway priority value (or other form of scoring) can be determined to cover all multiplexed traffic that will be in a forward proxy request for a given ZTNA session. In general, a ZTNA session can handle a subset of access requests compared to a traditional VPN session. In other words, each forward proxy session will likely only transmit a small number of access requests for a given proxy session. Therefore, multiple ZTNA proxy sessions from a given endpoint will be transmitted in one or more multiplexed sessions. Using the techniques described herein, each proxy session can have a priority independent of the multiplexed stream, so that a given proxy session is given a higher priority than another proxy session using the same weighting concept described for streams within a multiplexed session. That is, the secure access gateway 102 that is serving many ZTNA sessions from many client devices 104 can prioritize real-time traffic higher than other traffic types (e.g., web requests) that may not require the same computing and / or network resources, so that all real-time traffic in the entire set of user sessions is given priority higher than other traffic types (e.g., web requests). In some examples, the endpoint software (e.g., target resource 108) may also perform the same prioritization on the reverse network path, so that real-time traffic (or other high priority traffic) is processed before lower priority flows in terms of both computing and / or network resources. Additionally or alternatively, because the secure access gateway 102 is handling sessions from many users (e.g., client devices 104), the techniques described herein may also allow a given user to have a higher priority than another user if such a system is desired.

[0086] At "1", the secure access gateway 102 may establish a multiplexed data stream with one or more client devices 104. For example, the secure access gateway 102 may establish a first data stream connection with one or more client devices 104 and / or establish a second data stream connection with one or more client devices 104. In some examples, the first data stream connection may include a first HTTP protocol, such as HTTP / 3. Additionally or alternatively, the second data stream connection may include a second HTTP protocol, such as HTTP / 2. That is, the individual data streams included in the multiplexed data stream may be configured as HTTP / 2 and / or HTTP / 3 connections.

[0087] At "2", once a multiplexing connection is established with one or more client devices 104, the secure access gateway 102 may be configured to determine an indication of priority sorting data associated with a first data stream of the multiplexed data stream. In some examples, the secure access gateway 102 may determine the priority sorting data based on the one or more client devices 104. That is, the one or more client devices 104 may indicate the priority sorting data associated with the first data stream in a priority header field associated with the data packet and / or the connection. Additionally or alternatively, the secure access gateway 102 may be configured to determine an indication of weighted data associated with a second data stream of the multiplexed data stream. In some examples, the secure access gateway 102 may determine the weighted data based on one or more weighted bits associated with the second data stream. That is, the data packet associated with the second data stream connection may include one or more bits indicating the weighted data, as previously described.

[0088] At "3", using the weighted data and / or priority data determined for the data stream, the secure access gateway 102 can map the respective weighted data and / or priority data to a gateway priority value at the secure access gateway 102. In some examples, for a given data stream of a multiplexed data stream, the weighted data and / or priority data can indicate the type of network traffic associated with the data stream. In some examples, the secure access gateway 102 can determine the gateway priority value based on the type of network traffic. For example, the priority data associated with the first data stream can indicate that the first data stream is associated with a web request, and the weighted data associated with the second data stream can indicate that the second data stream is associated with real-time traffic. In this scenario, the secure access gateway 102 can be configured to assign a more favorable gateway priority value to the second data stream based on the priority ranking of real-time traffic being higher than web request traffic. In some examples, the secure access gateway 102 can determine the gateway priority value based on a policy enforced at the secure access gateway 102. In some examples, the policy may indicate a gateway priority value associated with a given network traffic type, where the traffic type may be determined based on a data flow, a client device, a target resource, weighting data, and / or prioritization data. Additionally or alternatively, the policy may indicate which built-in weighting values ​​for HTTP / 2 are more favorable than prioritization data associated with HTTP / 3. Additionally or alternatively, the policy may indicate specific users and / or roles associated with specific users that should be prioritized over other users and / or roles.

[0089] For example, the secure access gateway 102 may determine that the prioritization data associated with the first data stream is mapped to a first gateway priority value, and the weighted data associated with the second data stream is mapped to a second gateway priority value. In some examples, the gateway priority value may be configured as an integer, and the secure access gateway 102 may be configured to prioritize one stream higher than another stream based on the associated gateway priority value. Additionally or alternatively, the gateway priority value may be represented by one or more QoS bits. Consider an example in which the prioritization data associated with the first stream is mapped to a first gateway priority value of 2 and the weighted data associated with the second stream is mapped to a second gateway priority value of 5. The secure access gateway 102 may determine that the second gateway priority value is more favorable than the first gateway priority value based on the second gateway priority value being greater than the first gateway priority value.

[0090] Additionally or alternatively, the secure access gateway 102 can include a priority data store 116, and the gateway priority values ​​can be stored in the priority data store 116. For example, the secure access gateway 102 can store a first mapping between a first flow (and / or prioritization data) and a first gateway priority value and / or a second mapping between a second flow (and / or weighting data) and a second gateway priority value in the data store 116. In some examples, the secure access gateway 102 can send an indication of the gateway priority value(s) to the associated target resource(s) 108 and / or client device 104, where each respective device can prioritize the flows using the gateway priority values ​​(e.g., in opposite directions).

[0091] At "4", based on the second gateway priority value being more favorable than the first gateway priority value, the secure access gateway 102 may process the second data stream before processing the first data stream (e.g., perform encryption processing, decryption processing, proxy processing, routing processing, forwarding processing, encapsulation processing, decapsulation processing, and / or any other form of computing and / or network processing). The secure access gateway 102 may determine a target resource associated with a given data stream of the multiplexed data stream. For example, the secure access gateway 102 may determine a target resource 108 associated with the second data stream and establish a third data stream connection between the secure access gateway 102 and the target resource 108. In some examples, the third data stream may include the QUIC protocol, the UDP protocol, and / or the Transmission Control Protocol (TCP). The secure access gateway 102 may then be configured to process network traffic associated with the second data stream and / or transmit it to the target resource 108 before processing network traffic associated with the first data stream and / or transmitting it to the target resource and / or additional target resource. As previously described, the secure access gateway 102 can determine one or more QoS bits that indicate and / or represent a gateway priority value and send the one or more QoS bits to the target resource 108 so that network traffic traveling in the opposite direction (e.g., from the target resource to the client device) is prioritized in the same manner.

[0092] Additionally or alternatively, the ZTNA techniques described herein may be implemented via a plurality of secure access gateways 102 configured as, for example, as described below with reference to FIG. 2A to FIG. 2C The authorization chain described.

[0093] FIG. 2A to FIG. 2CSystem architecture diagrams of example environments 200, 220, and 230 are shown in which a client computing device 202 in a remote network 204 establishes a ZTNA connection with a target resource 206 in a network (e.g., an enterprise network 208, etc.) via one or more authorization nodes 210(1)-(N) (e.g., network proxies, network relays, etc.) configured as an authorization chain, where N can be any integer greater than 1. In some examples, the nodes 210 can be deployed in one or more networks 212.

[0094] In some examples, network(s) 212, remote network(s) 204, and / or enterprise network(s) 208 may include one or more data centers, including various network components, such as network switch(es) operating on physical servers (also referred to as node(s)). In some examples, physical server(s) may host one or more virtual machines. Each virtual machine may be configured to perform one of various operations and act as one or more virtual components, such as node(s) 210, of network(s) 212. In some examples, physical server(s) may host any number of virtual machines. In some examples, physical server(s) in enterprise network 104 may host various network components of enterprise network 104, such as target resource(s) 206.

[0095] As described herein, a client computing device 202 can establish a ZTNA connection with a target resource 206 of an enterprise network 208, for example, via one or more authorization nodes 210 (e.g., network proxies, network relays, etc.) configured as a chain of authorization. For example, one or more relays can be used to effectively route traffic to proxy nodes and / or VPN nodes such that each relay authorizes the connection to the next stage. In some examples, this approach uses a chain of relays and authorization tokens to allow access to the next hop in the network. Reference FIG. 2A to FIG. 2C Various implementations utilizing relays and / or token chaining are described in more detail.

[0096] Figure 2AA system architecture diagram of an example environment 200 is shown in which a client computing device 202 establishes a ZTNA connection with a target resource 206 of an enterprise network 208 via one or more authorization nodes 210 configured as an authorization chain. In some examples, the MASQUE protocol can be used to create an authorization chain for the client device 202 to access the target resource 206. Take a two-stage authorization chain (e.g., two nodes 210(1) and 210(N) requiring authorization) as an example. The first stage can be a first node 210(1) configured as a relay that requires a first authorization credential 214(1) (also referred to herein as an authorization token, a bearer token, etc.), such as a privacy pass token. The first node 210(1) can enforce a coarse-grained device-level access policy before proceeding to the next stage in the chain. If the first stage in the authorization chain is successfully traversed, the second stage may require a second authorization credential 214(2). For example, the second stage can be a second node 210(N) configured as a proxy that requires a second authorization credential 214(2) (e.g., a client certificate). In order to relay the session to the target destination 206, the second node 210 (N) may require the presentation of a client certificate. In this scenario, the resource 206 access grant is accomplished in the second phase via a different token than in the first phase. Thus, the token chain described above contains two links that are first satisfied by the confidentiality pass and then by the client certificate. This implementation of the authorization chain is referred to herein as onion-layer encapsulation.

[0097] By configuring the authorization chain in this manner, unauthorized devices cannot even access the second node 210(N) configured as a proxy to the target resource 206. Once the proxy node 210(N) is accessed, only authorized users can access the target resource 206. In some examples, packets can be encapsulated with encryption layers 216(1) to (N) corresponding to authorization stages, where each layer 216 in the sequence can be encrypted and can transmit the authentication credentials 214 required to proceed to the next stage. That is, each layer 216 can have its own encryption and authentication components for that layer 216. This is referred to herein as onion routing, where each layer 216 is conceptualized as an onion layer. Each layer 216 in the onion can be exposed if the policy at the previous layer 216 is satisfied (e.g., after the first stage is satisfied by presenting the first layer 216(1) including the privacy pass token, the second layer 216(N) including the client certificate can be exposed). Ultimately, the onion layers can be traversed until the core (e.g., the target resource 206) is accessed only after the required policies at each outer layer are satisfied.

[0098] As previously described, the encapsulation packet may include two layers 216: a first outer layer 216(1) including a privacy pass token and a second inner layer 216(N) including a client certificate. Additionally, a third innermost layer may be conceptualized. For example, the third inner layer may correspond to a single sign-on (SSO) user credential 214(N) for accessing the target resource 206. That is, once the first two stages are satisfied by the corresponding authorization credentials 214(1), 214(2), the third and final stage may be accessed at the target resource 206, where the user may be required to provide the SSO user credential 214(N) to access the target resource 206. In such an example, all three stages of the authorization chain would need to be included in order for an unauthorized user to access the target resource 206. Although an example authorization credential 214 is described, any non-user interaction credential (e.g., a privacy pass token, a client certificate, and / or any other type of authorization credential) and / or any user interaction credential (e.g., an SSO user credential, a biometric credential, etc.) may be utilized at any stage in the authorization chain.

[0099] Take, for example, a user of a client computing device 202 attempting to establish a ZTNA connection to a target resource 206. The network path between the client computing device 202 and the target resource 206 may include an authorization chain including one or more nodes 210 that include authorization requirements to be satisfied to connect to the target resource 206. The nodes 210 may be configured as proxy nodes, relay nodes, etc. In some examples, as previously described in the onion layer encapsulation implementation of the authorization chain, the client computing device 202 may generate a packet encapsulated with an encryption layer 216(1)-(N) (where N may be any integer greater than 1) of authorization credentials 214(1)-(N) configured to satisfy the authorization requirements associated with the nodes 210.

[0100] The client computing device 202 may be configured to generate a packet indicating a request to connect to the target resource 206. In some examples, the client computing device 202 may identify an authorization chain based at least in part on the target resource 208. That is, the client computing device may identify various nodes 210 and authorization requirements associated with the various nodes 210. Once the authorization chain is identified, the client computing device 202 may then identify authorization credentials 214 to be used to satisfy the authorization requirements associated with the nodes 210 of the authorization chain. In some examples, the authorization credentials 214 may be stored on the client computing device 202 and / or remotely in a data store accessible by the client computing device 202 via the network 212.

[0101] The client computing device 202 may also be configured to generate an encapsulated packet by encapsulating the previously generated packet with various encryption layers 216(1)-(N) including the authorization credentials 214(1)-(N). In some examples, the client computing device may determine an order of the nodes 210 in the authorization chain (e.g., an order of the nodes to be traversed on a network path to a target resource). The client computing device 202 may utilize the order of the nodes 210 to generate the encapsulated packet by encapsulating the packet with the encryption layers 216 according to the order of the nodes 210. That is, the outermost encryption layer 216(1) of the encapsulated packet may include a first authorization credential 214(1) for satisfying a first authorization requirement associated with a first node 210(1) to be accessed in the authorization chain. Additionally or alternatively, the innermost encryption layer 216(N) of the encapsulated packet may include a second authorization credential 216(2) for satisfying a last authorization requirement associated with a last node 210(N) in the authorization chain to be accessed before the target resource 206.

[0102] Using the generated encapsulated packet, the client computing device 202 can be configured to send the encapsulated packet to the target resource 206 via the authorization chain of nodes 210. For example, the client computing device 202 can send the encapsulated packet to the first node 210(1) of the authorization chain. The first node 210(1) can consume the authorization credential associated with the outermost encryption layer 216(1). That is, the first node 210(1) can be configured to decrypt the outermost encryption layer 216(1) and access the authorization credential 214(1) included therein. In some examples, the consumption of the authorization credential 214(1) can cause the first node 210(1) to remove the outermost encryption (or encapsulation) layer 216(1), leaving the second encryption layer 216(N) as the new outermost encryption layer after consumption. Additionally or alternatively, the authorization credential 214 associated with a given encryption layer 216 may be configured as an interactive authorization credential 214 (e.g., requiring some interaction from a user of the client computing device) or a non-interactive authorization credential 214 (e.g., a confidentiality pass, a client certificate, and / or any other form of authorization token). In examples where the authorization credential 214 is configured as an interactive authorization credential 214, the corresponding node 210 may transmit instructions for satisfying the interactive authorization credential 214 back to the client computing device 202.

[0103] After traversing the authorization chain of nodes 210 and satisfying the corresponding authorization requirements at each node 210, the authentication layer 218 can be accessed, and the target resource 206 can send a request to authenticate the user associated with the client computing device 202 with the target resource 206. The client computing device 202 can display the authentication request to prompt the user for necessary input. Once the user provides the input of the authentication credentials 214 (N) to the client computing device 202, the client computing device 202 can send an authentication response including the authentication credentials 214 (N) to the target resource 206, where the user can be authenticated with the target resource 206, and a connection can be established.

[0104] Figure 2B Another system architecture diagram of an example environment 220 is shown in which a client computing device 202 establishes a ZTNA connection with a target resource 206 of an enterprise network 208 via one or more authorization nodes 210 configured as a chain of authorization.

[0105] In some examples, the authorization chain can be configured with a single encryption layer between the target resource 206 and the client device 202 (e.g., encrypted session information 222). In such an example, the encrypted authorization credentials 224(1)-(N) can be embedded in the flow at the beginning of the traffic as metadata. This can be implemented using various encapsulation protocols (e.g., Generic Network Virtualization Encapsulation (GENEVE), Generic Routing Encapsulation (GRE), Generic UDP Encapsulation (GUE), Proxy Protocol, etc.). This implementation of the authorization chain is referred to herein as a single encrypted embedded encapsulation.

[0106] In such a configuration, each authorization credential (also referred to herein as a token) 224 may be transmitted as a link within the chain. In some examples, it may not be required to place the authorization tokens 224 (with reference to Figure 2A In contrast to the described onion routing example, where packets are encapsulated with layers in an order corresponding to the authorization chain). Additionally or alternatively, it can provide a computational improvement to order the authorization tokens 224 in order, avoiding the need to analyze the entire chain for matching tokens 224. Each token 224 can be encrypted in such a way that only the node 210 associated with the token 224 (e.g., the node 210 enforcing the authorization phase) can decrypt the token 224. The encryption can be performed using any encryption protocol (e.g., Hybrid Public Key Encryption (HPKE), etc.).

[0107] In some examples, the authorization credential 224 (e.g., a bearer token) may not be presented in-band with the flow. In such a scenario, the protocol may indicate that the token 224 is to be received out-of-band and how the flow is to be associated with a given out-of-band authentication and authorization. As described above, the tokens 224 may not be required to be configured in order. In addition, as tokens 224 are processed, they may be removed from the chain of tokens 224 by the node 210 in the authorization chain that processed the token 224. Additionally or alternatively, a bit in the payload may be configured to be modified by the node 210 in the authorization chain that processed the token 224 to indicate that the token 224 has been exhausted, such as Figure 2B as shown (e.g., an “X” next to encryption certificate 2 224(2)).

[0108] The client computing device 202 may be configured to determine nodes 210 along a network path (e.g., an authorization chain of nodes 210) between the client computing device 220 and the target resource 206 based on the target resource 206. Each of the nodes 210 may include authorization requirements that are required to be satisfied before proceeding to the next node 210. Once the nodes 210 along the network path are identified, the client computing device 202 may identify authorization credentials 224 that will be used to satisfy the authorization requirements associated with the nodes 210 along the network path. In some examples, the authorization credentials 224 may be stored on the client computing device 202 and / or remotely in a data store accessible by the client computing device 202 via one or more networks 212.

[0109] The client computing device 202 may also be configured to generate a packet indicating a request to connect to the target resource 206. In some examples, the packet may include an authorization ticket 224 corresponding to the authorization requirement. Additionally or alternatively, each authorization ticket 224 may be encrypted using an encryption type corresponding to the node 210 that includes the associated authorization requirement. That is, the authorization ticket (e.g., 224(2)) may be encrypted in such a way that only the node 210(1)( Figure 2B ) may be configured to decrypt the corresponding authorization credential 224(2).

[0110] Using the generated packet, the client computing device 202 can be configured to send the packet to the target resource 206 via the nodes 210 along the network path. For example, the client computing device 202 can send the packet to a first node 210 among the nodes 210. The first node 210 can consume an authorization credential 224 configured to satisfy a corresponding authorization requirement. That is, the first node 210 can be configured to decrypt and access the authorization credential 224(2) included therein. In some examples, the consumption of the authorization credential 224(2) can result in modifying at least one bit in the packet indicating that the authorization credential has been exhausted. Additionally or alternatively, a subsequent node 210 receiving the packet can check the bit indicating that the previous authorization credential 224(2) has been exhausted before decrypting the next authorization credential 224. Additionally or alternatively, the associated authorization credential 224 can be configured as an interactive authorization credential 224 (e.g., requiring some interaction by a user of the client computing device 202) or a non-interactive authorization credential 224 (e.g., a confidentiality pass, a client certificate, and / or any other form of authorization token). In examples where the authorization ticket 224 is configured as an interactive authorization ticket 224 , the corresponding node 210 may transmit instructions for satisfying the interactive authorization ticket 224 back to the client computing device 202 .

[0111] After traversing the nodes 210 along the network path and satisfying the corresponding authorization requirements at each node 210, the authentication layer 218 can be accessed, and the target resource 206 can send a request to authenticate the user associated with the client computing device 202 with the target resource 206. The client computing device 202 can display the authentication request to prompt the user for necessary input. Once the user provides input of the authentication credentials to the client computing device, the client computing device 202 can send an authentication response including the authentication credentials to the target resource 206, where the user can be authenticated with the target resource 206, and a connection can be established.

[0112] Figure 2C Another system architecture diagram of an example environment 230 is shown in which a client computing device 202 establishes a ZTNA connection with a target resource 206 of an enterprise network 208 via one or more authorization nodes 210 configured as a chain of authorization.

[0113] As reference Figure 2B Similarly described, the authorization chain can be configured with a single encryption layer between the target resource 206 and the client device 202 (e.g., encrypted session information 232). In some examples, blockchain 234 technology can be used to implement the reference Figure 2BThe token chain described. That is, the encrypted credentials 224 can be stored in one or more blocks 236 of the distributed ledger associated with the blockchain 234 network. In some examples, each block 236 can store an encrypted token 224, and the block 236 can be required to meet the policy requirements of a given node in order to traverse to the next node 210 in the authorization chain. Additionally or alternatively, each block 236 can store a hash of a previous block 238, so that a given block 236 can verify that the policy requirements at the previous node 210 are met by calculating the hash of the previous block 238. Additionally or alternatively, each block 236 can include a block header 240, which includes a hash of the previous block 238, a timestamp 242 associated with the block 236, a random number 244 associated with the block 236, and / or a hash of the block data 246. This implementation of the authorization chain is referred to herein as a single encrypted blockchain encapsulation.

[0114] In some examples, it may not be required that the authorization tokens 224 be placed sequentially in the block 236 (as in the reference Figure 2A In contrast to the described onion routing example, where packets are encapsulated with layers in an order corresponding to the authorization chain). Additionally or alternatively, it can provide a computational improvement to order the blocks 236 and / or authorization tokens 224 in order, avoiding the need to analyze all blocks 236 for matching tokens 224. Each token 224 can be encrypted in a manner that only the node 210 associated with the token 224 (e.g., the node 210 enforcing the authorization phase) can decrypt the token 224. The encryption can be performed using any encryption protocol (e.g., Hybrid Public Key Encryption (HPKE), etc.).

[0115] In some examples, the authorization credential 224 (e.g., a bearer token) may not be presented in-band with the flow. In such a scenario, the protocol may indicate that the token 224 is to be received out-of-band (e.g., associated with the blockchain 234), and how the flow is to be associated with a given out-of-band authentication and authorization. Additionally, as tokens 224 are processed, they may be removed from the chain of tokens 224 by the node 210 in the authorization chain that processed the token 224. Additionally or alternatively, a bit in the payload may be configured to be modified by the node 210 in the authorization chain that processed the token 224 to indicate that the token 224 has been exhausted, such as Figure 2C as shown (e.g., an “X” next to encryption certificate 2 224(2)).

[0116] Take, for example, a client computing device 202 requesting to establish a connection with a target resource 206. The client computing device 202 may be configured to determine nodes 210 along a network path (e.g., an authorization chain of nodes 210) between the client computing device 220 and the target resource 206 based on the target resource 206. Each of the nodes 210 may include authorization requirements that need to be satisfied before proceeding to the next node 210. Once the nodes 210 along the network path are identified, the client computing device 202 may identify authorization credentials 224 that will be used to satisfy the authorization requirements associated with the nodes 210 along the network path. In some examples, the authorization credentials 224 may be stored on the client computing device 202 and / or remotely in a data store accessible by the client computing device 202 via one or more networks 212.

[0117] As previously described, the client computing device 202 may also be configured to store the identified authorization credentials 224 in a block 236 of the distributed ledger associated with the blockchain network 234. The client computing device 202 may then generate a packet indicating a request to connect to the target resource 206. In some examples, the packet may include an indication of the address of the block 236 associated with the blockchain network 234. That is, the respective authorization credentials 224 may be stored in the respective blocks 236 of the blockchain network 234 and may be accessed via the address. Additionally or alternatively, each authorization credential 224 may be encrypted using an encryption type corresponding to the node 210 that includes the associated authorization requirement. That is, the authorization credentials 224 may be encrypted in such a manner that only the node 210 that includes the corresponding authorization requirement may be configured to access the corresponding authorization credential (as previously referenced). Figure 2B described).

[0118] Using the generated packets, the client computing device 202 can be configured to send the packets to the target resource 206 via the nodes 210 along the network path. For example, the client computing device 202 can send the packets to the first node 210 of the nodes 210. The first node can consume the authorization credential 224 configured to meet the corresponding authorization requirements. That is, the first node 210 can be configured to decrypt and access the authorization credential included therein. In some examples, the node 210 can modify the hash of the block 240 to indicate that the corresponding authorization credential 224 has been exhausted, and the subsequent node 210 can use the next block 236 to confirm that the previous authorization credential 224 has been exhausted. For example, the node 210 can check the block header 240 against the hash of the previous block 238 to determine that the previous authorization credential 224 has been exhausted. Additionally or alternatively, the associated authorization credential 224 may be configured as an interactive authorization credential 224 (e.g., requiring some interaction from a user of the client computing device) or a non-interactive authorization credential 224 (e.g., a confidentiality pass, a client certificate, and / or any other form of authorization token). In examples where the authorization credential 224 is configured as an interactive authorization credential 224, the corresponding node 210 may transmit instructions for satisfying the interactive authorization credential 224 back to the client computing device 202.

[0119] After traversing the nodes 210 along the network path and satisfying the corresponding authorization requirements at each node 210, the authentication layer 218 can be accessed, and the target resource 206 can send a request to authenticate the user associated with the client computing device 202 with the target resource 206. The client computing device 202 can display the authentication request to prompt the user for necessary input. Once the user provides input of the authentication credentials to the client computing device 202, the client computing device 202 can send an authentication response including the authentication credentials to the target resource 206, wherein the user can be authenticated with the target resource 206, and a connection can be established between the client device 202 and the target resource 206.

[0120] Figure 3 A system architecture diagram of an example environment for a deception service 302 associated with a network 304 (e.g., a client network, an enterprise network, etc.) to deploy deception 306 at scale in the network 304 is shown. In some examples, the deception service 302 can be deployed in various ways and associated with various networks 308. For example, the deception service 302 can be provided by a service provider and utilized by one or more networks 304 configured as a cloud computing network, a SASE network, a ZTNA network, etc. In addition, Figure 3 An example flow of a deception service 302 deploying deception 306 at scale in a network 304 is shown.

[0121] In some examples, spoofing service 302 may utilize and / or be comprised of DNS proxy 312, which is configured to make it appear as if many hosts are joining network 304, programmable NAT service 314, which is configured to dynamically switch network traffic to and from spoofed hosts 306, and / or DHCP monitor / agent 316, which is configured to consume and release IP addresses in network 304 as needed. Spoofing service 302 and / or its components are described in more detail below.

[0122] In some examples, the network(s) 308, remote access path 310, and / or client network 304 may include one or more data centers, including various network components, such as (one or more) network switches (also referred to as (one or more) nodes) operating on physical servers. In some examples, the physical server(s) may host one or more virtual machines. Each virtual machine may be configured to perform one of various operations and act as one or more virtual components of the network(s) 308, such as a deception service 302, a DNS proxy 312 associated with the deception service 302, a programmable NAT service 314 associated with the deception service 302, and / or a DHCP proxy 316 associated with the deception service 302. In some examples, the physical server(s) may host any number of virtual machines. In some examples, the physical server(s) in the client network 304 may host various network components of the client network 304, such as a client DNS 318 and / or a client DHCP 320.

[0123] The deception service 302 can be configured so that a small number of deception hosts 306 will actually exist. In some examples, the deception service 302 can configure the deception hosts 306 with enough hosts to cover all operating systems (OS) and / or components typically found in a network 304 data center (e.g., an enterprise data center), such as active directory, domain servers, web servers, directory servers, application servers, file servers, OS servers, database servers, etc. (shown as VM-1 to VM-N and / or multi-VM-1 to multi-VM-N). For example, there will be a small pool of active directory server deceptions 306. Initially, a configurable amount of each deception type will be started on physical, virtual, and / or container hosts. In some examples, each of these options can be policy driven (e.g., a configurable amount of each deception type, host type, etc.). This configuration can be driven by a deception service provider (e.g., a SASE provider) rather than by individual customers using the deception service 302. Options can be used to allow customers to match custom deceptions 306 that can be modified to their enterprise network 304 and place these custom deceptions 306 into a customer-specific pool. For example, a customer may wish to deploy an Active Directory deception 306 that more closely matches their enterprise network 304 configuration. Additionally or alternatively, the deception 306 may be a mix of actual systems and emulations. In some examples, emulations of protocols are used instead of hosting actual services where possible. For example, an SSH emulator would be sufficient to attract an attacker while at the same time producing a low false positive detection rate, thereby saving computing resources. Additionally, physical hosts may be used and reserved for attacks on physical host types that cannot be virtualized or containerized for technical reasons.

[0124] As previously described, the deception service 302 can utilize the DHCP agent 316 (or an instance thereof) and / or the programmable NAT service 314. Once the initial deception 306 is deployed, they can interact with the DHCP agent 316. The DHCP agent 316 instance can proxy DHCP requests to the customer network 304 (in both directions). In some examples, the policy can allow the customer to select how many deceptions they want to emulate on the network using the DHCP agent 316. Additionally or alternatively, the DHCP agent 316 can be configured so that when in fact all hosts are mapped back to a small set of actual deceptions 306, it will appear as if many hosts are joining the customer's network 304. The percentage of unused network addresses can be configurable so that the deception 306 can use N percent of the available address space, where N can be any percentage between 0 and 100, including 0 and 100. This is referred to as deception density in this article. In this way, the customer can use 100% of the unallocated network IP addresses for deception 306. For example, the customer can choose any density they want as a percentage of available network addresses. In some examples, this can be done for each subnet with a different value.

[0125] Additionally or alternatively, DHCP agent 316 can be configured to remove spoofed hosts 306 from customer network 304 when real hosts want network addresses and the available network address pool is exhausted (e.g., all IP addresses are allocated) and / or the spoof density is exceeded. In this way, spoofing service 302 can dynamically assign network addresses to spoofs 306 without changing the actual number of spoofed hosts 306. Instead, multiple IP addresses are mapped to the same spoofed host 306.

[0126] In some examples, the programmable NAT service 314 can be used in conjunction with the DHCP agent 316 to dynamically NAT network traffic to and from the actual spoof host 306, mapping them back to the addresses assigned by the DHCP agent 316. For example, if 50 unique DHCP addresses are mapped to a single spoof host 306, the NAT service can be configured to map and translate the 50 entries to a single actual node at different addresses. Assuming that malicious users or network attackers typically move laterally within the network, the assigned DHCP address is provided to the spoof 316. This allows the spoof host 306 to be accessed through lateral movement using the assigned DHCP address rather than the NAT address. This ensures that access that is completed without using a domain name service (DNS) 318 (e.g., a simple IP hub) is also addressed using the techniques described herein.

[0127] As previously described, the deception service 302 can also utilize the DNS proxy 312. The DNS proxy 312 can be configured to return an assigned IP address in the form of an algorithm, which is associated with a DHCP / NAT system value assigned to a host name that does not actually exist in the network 304. This makes it appear as if the host actually exists when the host does not actually exist. The customer can configure the percentage of non-existent domains (NXDOMAIN), NODATA, and / or NAT IP address responses for a given host name query. For example, a network administrator can configure the deception service to randomly return 30% to 50% NXDOMAIN responses to non-existent hosts, otherwise return NAT IP. Therefore, such a configuration can increase the authenticity of the deception service 302 by not always looking as if the host exists when the host does not exist. Although example values ​​of 30% to 50% are provided herein, the percentage can be any percentage between 0 and 100, including 0 and 100.

[0128] Additionally or alternatively, stickiness can be used so that when the deception service 302 answers a host name query, the deception service 302 can continue to return the same answer within a configurable amount of time (e.g., any number of minutes, hours, days, weeks, etc.). By configuring the deception service 302 to implement the stickiness function, a non-existent host may appear to be real to an attacker within a configurable amount of time (e.g., one day). That is, if the attacker requests the same host name within a configurable amount of time, the same answer can be returned instead of another NAT IP. In some examples, any mixture of responses can be configured, including using machine learning (ML) and / or artificial intelligence (AI) methods to decide when to respond with a deceptive host and when to respond with an indicator that the host does not exist (e.g., NXDOMAIN, NODATA, etc.). In this way, a malicious user who performs a directory scan on a host name only gets an answer sometimes, which may seem more realistic than always answering affirmatively (e.g., always returning the host). In addition, as previously described, a customer can configure the deception service 302 to always assert that a non-existent host name exists and return a deceptive address from the NAT service 314.

[0129] The DNS proxy 312 can be configured to be resilient to unexpected user errors. In this way, a dictionary system will be used to verify that similar domains do not exist on the network, which may be a simple user error when entering a domain. ML and / or AI techniques can also be used to determine what may be a user input error rather than a malicious user attacker espionage technique. For example, adjacent keys are often entered on the query keyboard of a domain. Additionally or alternatively, it can be expected that a user may accidentally type a web address. For example, if a user attempts to access "www.mydomain.com", the user may accidentally type "www.mydomian.com" or something similar. That is, the spoofing service 302 can be configured to take advantage of some form of typosquatting or other detection method for this scenario.

[0130] Additionally or alternatively, spoof 306 may be desired for an actual domain on network 304. For example, SSH may be a common protocol that an attacker interacts with. The real SSH host may be "ssh.mycompany.com". In some examples, an enterprise may set a policy that SSH is only available over a tunneled connection. In such a scenario, the network access method may play a role in whether a valid DNS result for a given host is returned. This may be configured by the enterprise and / or network owner. For example, if a DNS query for a host is not connected via a VPN or ZTNA, a spoof response may be returned and the spoof 306 in the pool will occupy a NAT address and a DHCP address on network 304. DHCP agent 316 may be configured to ensure that name conflicts for hosts do not occur.

[0131] As described herein, deception service 302 can be configured so that it can consider networked scans or probes that are insufficient to determine that a network attack is being performed. For example, a user who accidentally mistypes a domain name may not trigger deception service 302, as previously described. Similarly, vulnerability scanners may scan and probe in a manner that does not have prior knowledge of the systems available on the network. Scanners that use dictionaries to try different domains will likely create interactions with deception 306. In this way, deception service 302 can be configured to ensure that significant engagement (e.g., a threshold interaction) occurs before deception host 306 is isolated as part of an attacker's workflow.

[0132] Additionally or alternatively, the deception service 302 may also be configured to ensure that sufficient attacker interaction (e.g., a threshold interaction) has occurred with a deception 306 from the pool. Once a deception 306 has received enough engagement to determine that something other than a network scan is occurring, the deception 306 may be removed from the pool and bound to the assigned NAT and DHCP addresses as if it were an actual host on the network 304. At this point, a new deception 306 of the same type may be added to the pool to replace the deception that was isolated for the purpose of engaging the attacker. From here on, the attacker may engage the deception 306, and normal deception detection techniques may be used to alert that an active attack is ongoing (e.g., sending an alert to a network administrator). It may be assumed that once a threshold interaction occurs, deception techniques may take over to catch the attacker.

[0133] For example, SSH can be a common attack vector. The real SSH host in the network can be "ssh.mycompany.com". The deception service 302 can be configured to intelligently handle typical squatting domain type user errors, so that closely related domain names do not cause deception interactions, but instead return the expected NXDOMAIN response to the user. Additionally or alternatively, the host "ssh.finance.mycompany.com" can be an example of something that will not be mistyped when a user attempts to access "ssh.mycompany.com", and a domain name that is not a squatting type error can respond to the deception 306 from the pool with certainty. However, this alone may not be enough for the deception service 302 to remove the deception 306 from the deception pool to complete the attacker participation cycle. What may be required as a threshold interaction is a successful authentication with an SSH server using legitimate credentials within the enterprise. Once this threshold interaction is achieved, the deception service can remove the deception host 306 from the pool and assign the NAT and DHCP addresses as part of the participation. New deceptions 306 of the same type can be added to the pool to replace the deceptions that have been isolated from the attacker. By configuring the deception service 302 with such just-in-time (JIT) deception creation, very small amounts of resources can be used to provision a complete network of deceptions 306 in a manner that can be dynamically adapted as an attacker engages a given deception 306. Once the attacker has completed their engagement and the deception service 302 senses no network activity with the deception host 306, then based on the configuration (e.g., based on deception density, number of actual hosts joining the network, etc.), the deception 306 is either shut down or returned to the pool.

[0134] Take, for example, a client network 304 (e.g., an enterprise network) having host computing devices configured to host various services and / or resources of the network 304. A service provider may provide a deception service 302 for deploying deceptions 306 at scale in the network 304 according to the techniques described herein. The deceptions 306 may be configured to emulate virtual machines of a computing resource type (or a protocol associated with a computing resource type) associated with the network 304. The deception service 302 may assign one or more IP addresses from a pool of available IP addresses associated with the network to the deceptions 306, making it appear as if a large number (e.g., hundreds, thousands, millions, etc.) of hosts are connected to the network 304 when in fact the IP addresses map back to a small number (e.g., 5, 10, 15, etc.) of deceptions 306. That is, the deception service 302 may be configured to maintain the deception density on the network 304 as a percentage (e.g., 70%, 80%, 90%, etc.) of hosts configured to be deceptions 306, rather than the actual hosts. The configuration of the deployment of deception 306 in network 304 may be configured via one or more policies by a network user (e.g., a network administrator). Although example numbers and / or percentages of deception 306 are provided, these numbers / percentages are for exemplary purposes and any number / percentage may be configured.

[0135] In some examples, the deception service 302 can be configured to determine a threshold amount of computing resource types associated with the network 304. For example, the deception service 302 can determine that there are 8 different computing resource types that include different functions and / or protocols. As such, the deception service 302 can execute a certain amount of deception host computing devices 306 to satisfy the threshold amount of computing resource types associated with the network. For example, the deception service 302 can execute 8 deception host computing devices 306, each deception host computing device 306 corresponding to a respective different computing resource type associated with the network 304. In some examples, the execution of the deception host computing devices 306 can be dynamic, in that the deception service 302 can execute more and / or fewer deception host computing devices 306 as computing resource types are added to the network 304 and / or removed from the network 304.

[0136] The deception service 302 may then determine a number of deceptions 306 to emulate on the network 304. For example, each of the deception host computing devices 306 may be configured to provide functionality and / or protocols associated with a computing resource type in the network 304, and the deceptions 306 may be configured to emulate various services provided by the computing resource type (e.g., provide different functionality and / or utilize different protocols). The deception service 302 may generate a number of deceptions 306 to emulate on the host computing device. As previously described, the deceptions 306 may be associated with the computing resource types in the network. The deception service 302 may then store a first mapping between the deceptions 306 and the deception host computing devices 306. In some examples, the first mapping may be based at least in part on the protocols associated with the deceptions 306 and / or the computing resource types associated with the deception host computing devices 306.

[0137] Additionally or alternatively, the deception service 302 can assign multiple IP addresses in the network 304 to a single deception 306 in the network 304. In some examples, the deception service 302 can determine a percentage of deceptions 306 to be emulated on the network 304 (e.g., the density of deceptions in the network compared to real hosts). The deception service 302 can utilize a policy to determine the percentage of deceptions 306 to be emulated. For example, a network administrator associated with the network 304 can configure a policy at the deception service 302 indicating the density of deceptions 306 so as to maintain, when possible, on the network 304, for example, 90% of the hosts are deceptions 306 in the network 304, while the remaining 10% are real hosts in the network 304. That is, the deception service 302 can maintain a pool of available IP addresses associated with the network 304. As real hosts join and / or leave the network 304, the deception service 302 can assign and / or de-assign IP addresses to real hosts. Additionally or alternatively, the deception service 302 may allocate available IP addresses to the deceptions 306 on the network to meet the density of the deceptions 306. For example, if 7% of the IP addresses are currently being used by real hosts on the network 304, the deception service 302 may be configured to allocate 90% of the IP addresses to the deceptions 306 and not allocate the remaining 3%. Additionally or alternatively, if the policy indicates that 95% of the hosts should be deceptions 306 and 7% have been allocated to real hosts, the deception service 302 may allocate 93% of the IP addresses to the deceptions 306. In some examples, when the real hosts are disconnected from the network 304 (e.g., outside of business hours), the deception service 302 may reuse the IP addresses previously allocated to the real hosts to the deceptions 306 until the threshold density is met. When the real hosts return online, the deception service 302 may then release the IP addresses from the deceptions 306 as needed and allocate them to the real hosts. The deception service 302 may store a second mapping between the IP addresses in the network 304 and the deceptions 306. Deception service 302 can then deploy deception 306 to deception host computing device 306 based at least in part on the first mapping and / or the second mapping.

[0138] Once deception 306 is deployed in the network, deception service 302 may begin monitoring deception 306 for activity.

[0139] At “ 1 ,” DNS proxy 312 associated with spoofing service 302 may receive a request for a host name associated with network 304 .

[0140] At “ 2 ”, DNS proxy 312 may resolve the host name by forwarding the request to DNS server 318 of network 304 .

[0141] At "3", DNS server 318 may respond in one of a variety of ways (e.g., a host name of an actual host in the network, a NXDOMAIN response, a NODATA response). Spoofing service 302 may also be configured by a policy associated with network 304, such as configuring a percentage of NXDOMAIN and / or NODATA responses (e.g., requests associated with a non-existent host name) to return a spoofed IP address.

[0142] At "4", DNS proxy 312 of spoofing service 302 may receive a response indicating that the requested host is a host that does not exist in network 304. Based on the configuration of spoofing service 302, spoofing service 302 may then request a NAT IP (e.g., mapped to the IP address of spoof 306) from programmable NAT service 314.

[0143] At "5", the NAT service 314 can then get the spoof 306 from the IP address pool.

[0144] At "6", DHCP agent 316 may be configured to manage the allocation and release of IP addresses to spoof 306 and / or actual hosts, as previously described.

[0145] At “ 7 ”, NAT service 314 may then NAT map to an IP address in network 304 .

[0146] At “ 8 ”, the NAT service 314 may return the NAT IP to the DNS proxy 312 , which may then establish a connection between the attacker and the corresponding spoofed host computing device 306 hosting the spoof 306 .

[0147] At "9", DNS proxy 312 may process subsequent requests connected to the NAT-mapped IP address (eg, spoof 306) and may connect the attacker with the corresponding spoof host computing device 306 hosting spoof 306. This stickiness is described in more detail above.

[0148] Additionally or alternatively, the deception service 302 may monitor the activity of the connection to the deception 306. For example, the deception service 302 may be configured to determine a first IP address associated with the connection, and based on a second mapping between the IP address and the deception 306, the deception service 302 may identify a first deception 302 associated with the first IP address. From this point on, the deception service 302 may be configured to not take action until a threshold interaction (e.g., an exchange of authentication data, an exchange of authorization data, an exchange of credentials, an SSH connection, etc.) occurs with the first deception 306. That is, the deception service 302 may identify an interaction associated with the first deception 306 and determine whether the interaction satisfies a threshold interaction for isolating the deception 306. If the interaction satisfies the threshold, the deception service 302 may isolate the first deception 306 from the deception 306 (e.g., containerize the deception 306), where the interaction may be further monitored by the deception service 302, and / or deception techniques may be employed by the deception service 302 and / or additional deception techniques service to attract an attacker to further interact with the deception 306.

[0149] In the event that the first deception 306 is isolated from the other deceptions 306, the deception service 302 may generate a new deception 306 of the same type as the isolated first deception 306 and / or associated with a computing resource type of the deception host 306 on which the first deception 306 is executing. The IP address previously assigned to the first deception 306 may now be assigned to the new deception 306 (and to additional IP addresses if necessary to reach a deception threshold density), and the second mapping between IP addresses and deceptions 306 is updated to reflect the new deception 306. The new deception 306 may then be deployed to the deception host computing device 306 based on the updated second mapping.

[0150] Additionally or alternatively, the above reference Figures 1 to 2C The ZTNA and / or authorization chaining techniques described herein can be used to utilize and / or implement the deception service 302. That is, reference Figures 1 to 2C The described enterprise network 110 , 208 can utilize a deception service 302 from a service provider to deploy deception at scale in the enterprise network 110 , 208 .

[0151] Figures 4 to 9 Flowcharts of example methods 400 to 900 are shown, and illustrate methods that are at least partially implemented by (one or more) cloud networks, (one or more) enterprise networks, (one or more) application networks, and / or (one or more) metadata-aware networks and / or by Figures 1 to 3 The various aspects of the functions performed by the corresponding components described in this article. Figures 4 to 9The described logical operations may be implemented as (1) a sequence of computer-implemented actions or program modules running on a computing system and / or (2) interconnected machine logic circuits or circuit modules within a computing system. In some examples, methods 400 to 900 may be performed by a system including one or more processors and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform (one or more) methods 400 to 900.

[0152] The implementation of the various components described herein is a matter of choice that depends on the performance and other requirements of the computing system. Therefore, the logical operations described herein are referred to variously as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules may be implemented in software, firmware, dedicated digital logic, and any combination thereof. It should also be understood that more than one embodiment may be implemented. Figures 4 to 9 The present invention also can be used to describe more or less operations shown in and described in this article. These operations can also be performed in parallel, or in an order different from that described in this article. Some or all of these operations can also be performed by components other than those specifically identified. Although the techniques described in this disclosure refer to specific components, in other examples, these techniques can be implemented by fewer components, more components, different components, or any configuration of components.

[0153] Figure 4 A flowchart of an example method 400 of a secure access gateway distributing computation and networking priority ranking to individual flows within an HTTP / 2 and / or HTTP / 3 multiplexing session of a ZTNA is shown. In some examples, the secure access gateway may correspond to reference Figure 1 A secure access gateway 102 is described.

[0154] At 402, process 400 may include establishing, by a secure access gateway, a first data flow connection with one or more client devices. In some examples, the first data flow connection may include a first hypertext transfer protocol (HTTP) protocol. Additionally or alternatively, the client device may correspond to a reference Figure 1 A client device 104 is described.

[0155] At 404, process 400 can include establishing, by the secure access gateway, a second data flow connection with one or more client devices. In some examples, the second data flow connection can include a second HTTP protocol different from the first HTTP protocol.

[0156] At 406, process 400 can include determining first prioritization data associated with the first data flow. In some examples, the first prioritization data can be determined by a secure access gateway and / or based at least in part on one or more client devices.

[0157] At 408, process 400 can include determining first weighted data associated with the second data flow. In some examples, the first weighted data can be determined by the secure access gateway and / or based at least in part on the second data flow.

[0158] At 410, process 400 may include storing a first mapping between a first data stream and a first priority value. In some examples, the first mapping may be stored by a secure access gateway and / or based at least in part on the first priority ranking data. Additionally or alternatively, the first priority value may correspond to a reference Figure 1 The gateway priority value described.

[0159] At 412, process 400 may include storing a second mapping between the second data stream and the second priority value. In some examples, the second mapping may be stored by the secure access gateway and / or based at least in part on the first weighted data. Additionally or alternatively, the second priority value may correspond to the reference Figure 1 The gateway priority value described.

[0160] At 414, process 400 can include determining that the first priority value is more favorable than the second priority value. In some examples, determining that the first priority value is more favorable than the second priority value can be based at least in part on determining that the first priority value is greater than the second priority value.

[0161] At 416 , process 400 can include processing the first data stream before processing the second data stream based at least in part on the first priority value being more favorable than the second priority value.

[0162] In some examples, the first HTTP protocol may be an HTTP / 3 protocol, and / or the second HTTP protocol may be an HTTP / 2 protocol.

[0163] In some examples, processing the first data stream may include at least one of: performing an encryption process associated with the first data stream, performing a decryption process associated with the first data stream, performing a proxy process associated with the first data stream, performing a routing process associated with the first data stream, performing a forwarding process associated with the first data stream, performing an encapsulation process associated with the first data stream, and / or performing a decapsulation process associated with the first data stream.

[0164] Additionally or alternatively, process 400 may include identifying one or more bits in a packet associated with the second data stream indicating the first weighted data. In some examples, determining the first weighted data associated with the second data stream may be based at least in part on identifying the one or more bits.

[0165] Additionally or alternatively, process 400 may include receiving an indication of first prioritization data associated with the first data stream from a client device of the one or more client devices. In some examples, determining the first prioritization data associated with the first data stream may be based at least in part on receiving the indication.

[0166] Additionally or alternatively, process 400 may include: determining, by the secure access gateway, a target resource associated with the first data flow. Additionally or alternatively, process 400 may include: establishing, by the secure access gateway, a third data flow connection with the target resource, wherein the third data flow includes at least one of a QUIC protocol, a UDP protocol, or a transmission control protocol (TCP). Additionally or alternatively, process 400 may include: sending, via the third data flow, network data received at the secure access gateway via the first data flow to the target resource before processing the second data flow.

[0167] Additionally or alternatively, process 400 may include determining, by the secure access gateway, one or more quality of service (QOS) bits associated with the first data flow. In some examples, the one or more QOS bits may represent a first mapping between the first data flow and the first priority value. Additionally or alternatively, process 400 may include sending, from the secure access gateway to the target resource, the one or more QOS bits associated with the first data flow. In some examples, the one or more QOS bits may cause the target resource to process the first data flow before processing at least the second data flow.

[0168] Figure 5 A flowchart of an example method 500 of establishing a ZTNA connection between a client computing device and a target resource of a network (e.g., an enterprise network) via one or more authorization nodes (e.g., a network proxy, a network relay, etc.), wherein the one or more authorization nodes are configured as an authorization chain. In some examples, the client computing device, the target resource, the network, and / or the authorization node may correspond to reference Figure 2A Client device 202, target resource 206, enterprise network 208, and / or node 210 are depicted.

[0169] At 502, process 500 can include generating, by a first computing device, a packet. In some examples, the packet can indicate a request to connect to a target resource.

[0170] At 504, process 500 can include identifying an authorization chain along a network path between the first computing device and the target resource based at least in part on the target resource. In some examples, the authorization chain can include nodes that include authorization requirements to be satisfied for connections to the target resource.

[0171] At 506, process 500 may include identifying an authorization credential for satisfying the authorization requirement. In some examples, the authorization credential may correspond to a reference Figure 2A Authorization credentials 214 are described.

[0172] At 508, process 500 may include generating an encapsulated packet based at least in part on encapsulating the packet with respective encryption layers corresponding to the authorization credential. In some examples, the encryption layers may correspond to the reference Figure 2A An encryption layer 216 is described.

[0173] At 510 , process 500 can include sending the encapsulated packet from the first computing device to a target resource via a delegation chain of nodes.

[0174] At 512, process 500 can include receiving, at a first computing device, a first request to authenticate a user with a target resource. In some examples, the user can be associated with the first computing device.

[0175] At 514, process 500 can include sending authentication credentials corresponding to the target resource to the target resource in response to the first request to authenticate the user.

[0176] In some examples, each node may be configured as one of a proxy node or a relay node. Additionally or alternatively, each authorization credential may include at least one of an authorization credential or a confidentiality pass.

[0177] Additionally or alternatively, process 500 may include causing the first computing device to display a request to authenticate the user with the target resource. Additionally or alternatively, process 500 may include receiving, by the first computing device, user input representing authentication credentials.

[0178] Additionally or alternatively, process 500 may include determining, based at least in part on the authorization chain, that a first node associated with a first authorization requirement will receive the encapsulated packet before a second node associated with a second authorization requirement. Additionally or alternatively, generating the encapsulated packet may include encapsulating the packet with a first encryption layer including a first authorization credential configured to satisfy the second authorization requirement. Additionally or alternatively, generating the encapsulated packet may include encapsulating the packet with a second encryption layer including a second authorization credential configured to satisfy the first authorization requirement. In some examples, the first encryption layer is encapsulated by the second encryption layer.

[0179] Additionally or alternatively, process 500 may include encrypting the first encryption layer using a first encryption type. In some examples, the first encryption type may be configured such that the second node can decrypt the first authorization credential from the first encryption layer. Additionally or alternatively, process 500 may include encrypting the second encryption layer using a second encryption type different from the first encryption type. In some examples, the second encryption type is configured such that the first node can decrypt the second authorization credential.

[0180] Additionally or alternatively, process 500 may include determining an order of nodes associated with the authorization chain. In some examples, the order may indicate a first node at which the authorization chain begins. Additionally or alternatively, process 500 may include establishing a connection between the first computing device and a first node of the nodes associated with the authorization chain. In some examples, the connection may include one of a QUIC protocol or a Hypertext Transfer Protocol (HTTP) / 2 protocol. In some examples, sending the encapsulated packet to the target resource may include sending the encapsulated packet to the first node via the connection.

[0181] In some examples, the request to authenticate the user with the target resource may be a first request. Additionally or alternatively, process 500 may include: receiving, at the first computing device, from a node in the node associated with the authorization chain, a second request for user input associated with the authorization credential in the authorization credential. In some examples, the second request may be received before the first request. Additionally or alternatively, process 500 may include: receiving, via the first computing device, user input associated with the authorization credential. Additionally or alternatively, process 500 may include: sending, in response to the second request for user input, the user input associated with the authorization credential to the node.

[0182] Figure 6 A flowchart of another example method 600 of establishing a ZTNA connection between a client computing device and a target resource of a network (e.g., an enterprise network) via one or more authorization nodes (e.g., a network proxy, a network relay, etc.) configured as an authorization chain is shown. In some examples, the client computing device, the target resource, the network, and / or the authorization node may correspond to reference Figure 2B Client device 202, target resource 206, enterprise network 208, and / or node 210 are depicted.

[0183] At 602, process 600 can include determining, by a first computing device, a node along a network path between the first computing device and the target resource based at least in part on the target resource. In some examples, the node can include an authorization requirement associated with connecting to the target resource.

[0184] At 604, process 600 can include identifying an authorization credential corresponding to the authorization requirement.

[0185] At 606, process 600 may include generating a packet indicating a request to connect to a target resource. In some examples, the packet may include an encrypted authorization credential corresponding to the authorization requirement. Additionally or alternatively, the authorization credential may correspond to a reference to a resource. Figure 2B Described encrypted credentials 224.

[0186] At 608, process 600 can include sending the packet from the first computing device to the target resource via the node.

[0187] At 610 , process 600 can include receiving a request to authenticate a user with a target resource, the user associated with a first computing device.

[0188] At 612, process 600 can include sending the authentication credentials to the target resource.

[0189] Additionally or alternatively, process 600 may include determining a first encryption type associated with a first node in the node based at least in part on the nodes along the network path. Additionally or alternatively, process 600 may include encrypting a first authorization credential in the authorization credential using the first encryption type. In some examples, the first encryption type may be configured so that the first node associated with the first authorization requirement can decrypt the first authorization credential. Additionally or alternatively, process 600 may include determining a second encryption type associated with a second node in the node based at least in part on the nodes along the network path. In some examples, the second encryption type may be different from the first encryption type. Additionally or alternatively, process 600 may include encrypting a second authorization credential in the authorization credential using the second encryption type. In some examples, the second encryption type may be configured so that the second node associated with the second authorization requirement can decrypt the second authorization credential.

[0190] In some examples, a first node associated with a first authorization requirement can be configured to decrypt the first authorization credential based at least in part on a first decryption type associated with the first encryption type, process the first authorization credential, modify a packet after processing the first authorization credential to include an indication that the first authorization credential has been exhausted, and / or send the packet to a second node.

[0191] In some examples, each node is configured as one of a proxy node or a relay node. Additionally or alternatively, each authorization credential includes at least one of an authorization credential or a confidentiality pass.

[0192] Additionally or alternatively, process 600 may include causing the first computing device to display a request to authenticate the user with the target resource. Additionally or alternatively, process 600 may include receiving, by the first computing device, user input representing authentication credentials.

[0193] Additionally or alternatively, process 600 may include determining an order of nodes along a network path between the first computing device and the target resource. Additionally or alternatively, process 600 may include establishing a connection between the first computing device and a first node in the nodes based at least in part on the order. In some examples, the connection may include one of a QUIC protocol or a Hypertext Transfer Protocol (HTTP) / 2 protocol. In some examples, sending the packet to the target resource may include sending the packet to the first node via the connection.

[0194] In some examples, the request to authenticate the user with the target resource may be a first request. Additionally or alternatively, process 600 may include: receiving, at the first computing device, from a node in a network path between the first computing device and the target resource, a second request for user input associated with the authorization credential in the authorization credential. In some examples, the second request may be received before the first request. Additionally or alternatively, process 600 may include: receiving, via the first computing device, user input associated with the authorization credential. Additionally or alternatively, process 600 may include: sending, in response to the second request for user input, the user input associated with the authorization credential to the node.

[0195] Figure 7 A flowchart of another example method 700 of establishing a ZTNA connection between a client computing device and a target resource of a network (e.g., an enterprise network) via one or more authorization nodes (e.g., a network proxy, a network relay, etc.) configured as an authorization chain is shown. In some examples, the client computing device, the target resource, the network, and / or the authorization node may correspond to reference Figure 2C Client device 202, target resource 206, enterprise network 208, and / or node 210 are depicted.

[0196] At 702, process 700 can include determining, by a first computing device, a node along a network path between the first computing device and the target resource based at least in part on the target resource. In some examples, the node can include an authorization requirement associated with connecting to the target resource.

[0197] At 704, process 700 may include identifying an authorization credential corresponding to the authorization request. In some examples, the authorization credential may correspond to a reference Figure 2C The encrypted authorization certificate 224 is described.

[0198] At 706, process 700 may include storing the authorization credential in a block of a distributed ledger associated with a blockchain network. In some examples, the block and / or blockchain network may correspond to a reference Figure 2C Block 236 and / or blockchain 234 are depicted.

[0199] At 708, process 700 may include generating a packet indicating a request to connect to a target resource, the packet including an indication of an address of a block associated with the blockchain network. In some examples, the block may include an authorization credential corresponding to the authorization request.

[0200] At 710 , process 700 can include sending a packet from a first computing device to a target resource via a node.

[0201] At 712 , process 700 can include receiving a request to authenticate a user with a target resource, the user associated with a first computing device.

[0202] At 714, process 700 can include sending the authentication credentials to the target resource.

[0203] Additionally or alternatively, process 700 may include determining an order of nodes along a network path between the first computing device and the target resource.In some examples, the grouping may include an indication of addresses of the blocks arranged according to the order.

[0204] Additionally or alternatively, process 700 may include determining, based at least in part on nodes along a network path between the first computing device and the target resource, that a first node associated with a first authorization requirement will receive a packet before a second node associated with a second authorization requirement. Additionally or alternatively, storing the authorization credentials in a block may include storing a first authorization credential corresponding to the first authorization requirement in a first block of the distributed ledger and / or storing a second authorization credential corresponding to the second authorization requirement in a second block. In some examples, the second block may have a header that includes a hash of the first block as an indication of a previous block.

[0205] In some examples, a first node associated with a first authorization requirement may be configured to decrypt a first authorization credential from the first block, process the first authorization credential, modify a hash of the first block after processing the first authorization credential to include an indication that the first authorization credential has been exhausted, and / or send a packet to a second node.

[0206] In some examples, a second node associated with the second authorization requirement may be configured to determine that the first authorization credential has been exhausted based on the hash of the first block and / or to process the second authorization credential after determining that the first authorization credential has been exhausted.

[0207] Additionally or alternatively, process 700 may include causing the first computing device to display a request to authenticate the user with the target resource. Additionally or alternatively, process 700 may include receiving, by the first computing device, user input representing authentication credentials.

[0208] Figure 8 A flow chart of an example method 800 for deploying deception at scale in a network by a deception service associated with a network is shown. In some examples, the deception service, the network, and / or the deception may correspond to reference Figure 3 The deception service 302, deception 306, and / or client network 304 are described. Additionally or alternatively, the deception service can be respectively connected to a DNS proxy, a programmable NAT, and / or a DHCP proxy (e.g., see Figure 3 The described DNS proxy 312, programmable NAT 314 and / or DHCP proxy 316) are associated.

[0209] At 802 , process 800 can include determining, by a spoofing service associated with a network, a threshold amount of a computing resource type associated with a network.

[0210] At 804, process 800 may include executing a dynamic amount of a spoofed host computing device to satisfy a threshold amount of a computing resource type associated with a network. In some examples, the spoofed host computing device may correspond to a reference Figure 3 A physical or simulated spoof host 306 is described.

[0211] At 806, process 800 can include determining a number of spoofs to emulate on the network.

[0212] At 808 , process 800 can include generating a number of spoofs emulated on the spoof host computing device, the spoofs being associated with the computing resource type.

[0213] At 810, process 800 can include storing a first mapping between spoofs and spoof host computing devices. In some examples, the first mapping can be based at least in part on a protocol associated with the spoofs and / or a computing resource type associated with the spoof host computing device.

[0214] At 812 , process 800 can include deploying a deception to a deception host computing device based at least in part on the first mapping.

[0215] In some examples, respective spoofs can include emulation of a protocol associated with one of the computing resource types and / or emulation of a computing resource type.

[0216] Additionally or alternatively, process 800 may include receiving a policy from a computing device associated with the network indicating a threshold number of spoofs to emulate on the network. Additionally or alternatively, process 800 may include determining the number of spoofs to emulate on the network based at least in part on the policy.

[0217] Additionally or alternatively, process 800 may include determining an Internet Protocol (IP) address associated with the network that is available for assignment. Additionally or alternatively, process 800 may include assigning a subset of the IP addresses to each of the spoofs. Additionally or alternatively, process 800 may include storing a second mapping between the IP addresses and the spoofs based at least in part on assigning the subset of IP addresses to each of the spoofs. In some examples, deploying the spoofs to the spoof host computing device may be based at least in part on the second mapping.

[0218] Additionally or alternatively, process 800 may include determining that a connection associated with a first spoof host computing device in the spoof host computing devices has been established. Additionally or alternatively, process 800 may include determining a first IP address associated with the connection, the first IP address being included in a first subset of the subsets of IP addresses. Additionally or alternatively, process 800 may include identifying a first spoof associated with the first IP address based at least in part on the second mapping. In some examples, the first spoof may be deployed to the first spoof host computing device and associated with the first subset of IP addresses. Additionally or alternatively, process 800 may include identifying an interaction associated with the first spoof. Additionally or alternatively, process 800 may include determining that the interaction satisfies a threshold interaction for isolating the first spoof from the spoof. Additionally or alternatively, process 800 may include isolating the first spoof from the first spoof host computing device and isolating the first IP address from the first subset of IP addresses based at least in part on determining that the interaction satisfies the threshold interaction. Additionally or alternatively, process 800 may include generating a second deception associated with a first computing resource type based at least in part on a first computing resource type associated with the first deception. Additionally or alternatively, process 800 may include assigning a first subset of IP addresses to the second deception. Additionally or alternatively, process 800 may include storing a third mapping between the first subset of IP addresses and the second deception based at least in part on assigning the first subset of IP addresses to the second deception. Additionally or alternatively, process 800 may include deploying the second deception to the first deception host computing device based at least in part on the first mapping and the third mapping.

[0219] Additionally or alternatively, process 800 may include: receiving a request for a first IP address associated with the network from a host computing device associated with the network. Additionally or alternatively, process 800 may include: determining that an IP address associated with the network is not available for allocation. Additionally or alternatively, process 800 may include: determining that a first IP address of the IP addresses is allocated to a first spoof of the spoofs. Additionally or alternatively, process 800 may include: cancelling the allocation of the first IP address to the first spoof. Additionally or alternatively, process 800 may include: updating a second mapping between the IP address and the spoof based at least in part on cancelling the allocation of the first IP address to the first spoof. Additionally or alternatively, process 800 may include: allocating the first IP address to the host computing device.

[0220] Additionally or alternatively, process 800 may include determining that the host computing device has an inactive connection on the network. Additionally or alternatively, process 800 may include determining that an active number of spoofs associated with the network is below a threshold number of spoofs. Additionally or alternatively, process 800 may include unassigning the first IP address to the host computing device. Additionally or alternatively, process 800 may include assigning the first IP address to the first spoof. Additionally or alternatively, process 800 may include updating a second mapping between IP addresses and spoofs based at least in part on assigning the first IP address to the first spoof.

[0221] Fig. 9 A flowchart of an example method 900 is shown in which a deception service associated with a network isolates deception from additional deceptions deployed in the network based on a threshold interaction occurring for deception. In some examples, the deception service, the network, and / or the deception may correspond to reference Figure 3 The deception service 302, deception 306, and / or client network 304 are described. Additionally or alternatively, the deception service can be respectively connected to a DNS proxy, a programmable NAT, and / or a DHCP proxy (e.g., see Figure 3 The described DNS proxy 312, programmable NAT 314 and / or DHCP proxy 316) are associated.

[0222] At 902, process 900 may include executing, by a deception service associated with a network, a dynamic amount of deception of a host computing device to satisfy a threshold amount of a computing resource type associated with the network. In some examples, the deception host computing device may be configured to emulate a threshold amount of deception on the network. Additionally or alternatively, the deception host computing device may correspond to a reference Figure 3 A physical or simulated spoof host 306 is described.

[0223] At 904, process 900 can include determining that the first device satisfies a threshold interaction associated with a first spoof among spoofs on the network. Figure 3 An example of determining a threshold interaction associated with spoofing is described.

[0224] At 906, process 900 can include determining a first Internet Protocol (IP) address associated with the first spoof.

[0225] At 908, process 900 can include isolating the first spoof from the spoof based at least in part on the first IP address.

[0226] At 910, process 900 can include determining that an amount of spoofing on the network is below a spoofing threshold amount.

[0227] At 912, process 900 can include generating a second spoof based at least in part on determining that the amount of spoofing on the network is below a spoofing threshold amount. In some examples, the second spoof can be of the same spoof type as the first spoof.

[0228] At 914, process 900 can include deploying a second spoof to be emulated on the spoof host computing device. In some examples, the second spoof can be assigned a second IP address that is different from the first IP address.

[0229] In some examples, determining that the first device satisfies a threshold interaction associated with the first spoof may include at least one of determining that the first device exchanged credentials with the first spoof, determining that the first device exchanged authorization data with the first spoof, determining that the first device exchanged authentication data with the first spoof, and / or determining that a secure shell (SSH) protocol connection was established between the first device and the first spoof.

[0230] Additionally or alternatively, process 900 may include storing a mapping between an IP address associated with a network and a spoof on the network. Additionally or alternatively, process 900 may include receiving a request for an IP address from a host computing device associated with the network for an IP address of the IP address associated with the network. Additionally or alternatively, process 900 may include determining that an IP address associated with the network is not available for allocation. Additionally or alternatively, process 900 may include canceling the allocation of a second IP address to a second spoof. Additionally or alternatively, process 900 may include allocating a second IP address to the host computing device. Additionally or alternatively, process 900 may include updating a mapping between an IP address on the network and a spoof based at least in part on allocating the second IP address to the host computing device.

[0231] Additionally or alternatively, process 900 may include determining that the host computing device has an inactive connection on the network. Additionally or alternatively, process 900 may include determining that an amount of spoofing on the network is below a spoofing threshold amount. Additionally or alternatively, process 900 may include canceling the assignment of the second IP address to the host computing device based at least in part on determining that the host computing device has an inactive connection on the network. Additionally or alternatively, process 900 may include assigning the second IP address to the second spoof based at least in part on determining that an amount of spoofing on the network is below a spoofing threshold amount. Additionally or alternatively, process 900 may include updating a mapping between IP addresses on the network and spoofs based at least in part on assigning the second IP address to the host computing device.

[0232] Additionally or alternatively, process 900 may include receiving a first query indicating a first host name associated with a network at a first time before isolating the first spoof. Additionally or alternatively, process 900 may include determining that the first host name is associated with the first spoof. Additionally or alternatively, process 900 may include returning a first IP address associated with the first spoof in response to the first query. Additionally or alternatively, process 900 may include isolating the first spoof from the spoof at a second time after the first time. In some examples, the first spoof may be isolated from the spoof until a third time after the second time. Additionally or alternatively, process 900 may include receiving a second query indicating the first host name at a fourth time after the second time. Additionally or alternatively, process 900 may include returning the first IP address associated with the first spoof in response to the second query based at least in part on determining that the fourth time is before the third time.

[0233] Additionally or alternatively, process 900 may include receiving a policy from a computing device associated with the network indicating a threshold amount of spoofing to be emulated on the network. In some examples, the threshold amount of spoofing to be emulated on the network includes at least one of a number of spoofing to be emulated on the network and / or a percentage of IP addresses associated with the network to be allocated to spoofing.

[0234] Fig.10 An example computer architecture is shown for a computing device (or network routing device) 1000 that is capable of executing program components for implementing the functionality described above. Fig.10 The computer architecture shown illustrates a conventional server computer, workstation, desktop computer, laptop computer, tablet computer, web appliance, e-reader, smart phone, or other computing device and can be used to execute any software components presented herein. In some examples, computing device 1000 may correspond to Figures 1 to 3A physical server associated with the (one or more) networks, secure access gateways, (one or more) nodes, (one or more) remote networks, enterprise networks and / or (one or more) client networks described in.

[0235] The computing device 1000 includes a baseboard 1002, or "motherboard," which is a printed circuit board to which a number of components or devices may be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units ("CPUs") 1004 operate in conjunction with a chipset 1006. The CPU 1004 may be a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of the computing device 1000.

[0236] The CPU 1004 performs operations by transitioning from one discrete physical state to the next, where the state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide output states based on logical combinations of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adders and subtractors, arithmetic logic units, floating point units, etc.

[0237] Chipset 1006 provides an interface between CPU 1004 and the remaining components and devices on baseboard 1002. Chipset 1006 may provide an interface with RAM 1008, which is used as main memory in computing device 1000. Chipset 1006 may further provide an interface with a computer-readable storage medium, such as read-only memory ("ROM") 1010 or non-volatile RAM ("NVRAM"), for storing basic routines that help boot computing device 1000 and transfer information between various components and devices. ROM 1010 or NVRAM may also store other software components necessary for the operation of computing device 1000 according to the configuration described herein.

[0238] The computing device 1000 may operate in a networked environment, using logical connections to remote computing devices and computer systems through a network, such as the network 1024. The chipset 1006 may include functionality for providing network connectivity through a NIC 1012, such as a Gigabit Ethernet adapter. The NIC 1012 is capable of connecting the computing device 1000 to other computing devices through the network 1024. It should be appreciated that multiple NICs 1012 may be present in the computing device 1000, connecting the computer to other types of networks and remote computer systems.

[0239] The computing device 1000 can be connected to a storage device 1018 that provides non-volatile storage for the computing device 1000. The storage device 1018 can store an operating system 1020, programs 1022, and data, which have been described in more detail herein. The storage device 1018 can be connected to the computing device 1000 through a storage controller 1014 connected to the chipset 1006. The storage device 1018 can be composed of one or more physical storage units. The storage controller 1014 can be connected to the physical storage unit through a serial attached SCSI (serial attached SCSI, "SAS") interface, a serial advanced technology attachment (serial advanced technology attachment, "SATA") interface, a fiber channel (fiber channel, "FC") interface, or other types of interfaces for physically connecting and transferring data between a computer and a physical storage unit.

[0240] The computing device 1000 may store data on the storage device 1018 by transforming the physical state of the physical storage unit to reflect the information being stored. In different embodiments of the present specification, the specific transformation of the physical state may depend on various factors. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage unit, whether the storage device 1018 is characterized as primary storage or secondary storage, etc.

[0241] For example, the computing device 1000 may store information to the storage device 1018 by issuing instructions through the storage controller 1014 to change the magnetic properties of a specific location within a disk drive unit, the reflective or refractive properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of the present specification, and the foregoing examples are provided only for the convenience of the present specification. The computing device 1000 may further read information from the storage device 1018 by detecting the physical state or properties of one or more specific locations within the physical storage unit.

[0242] In addition to the mass storage device 1018 described above, the computing device 1000 may also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It will be appreciated by those skilled in the art that a computer-readable storage medium is any available medium that provides non-transitory storage of data and can be accessed by the computing device 1000. In some examples, the operations performed by the computing resource network 102 and / or any components included therein may be supported by one or more devices similar to the computing device 1000. In other words, some or all of the operations performed by a physical server associated with (one or more) networks, secure access gateways, (one or more) nodes, (one or more) remote networks, enterprise networks, and / or (one or more) client networks and / or any components included therein may be performed by one or more computing devices 1000 operating in a cloud-based arrangement.

[0243] By way of example, and not limitation, computer-readable storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically-erasable programmable ROM ("EEPROM"), flash memory or other solid-state memory technology, compact disc ROM ("CD-ROM"), digital versatile disk ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY or other optical storage, cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory manner.

[0244] As briefly mentioned above, the storage device 1018 may store an operating system 1020 that is utilized to control the operation of the computing device 1000. According to one embodiment, the operating system comprises a LINUX operating system. According to another embodiment, the operating system comprises an UNIX operating system from MICROSOFT Corporation of Redmond, Washington. SERVER operating system. According to another embodiment, the operating system may include a UNIX operating system or one of its variants. It should be understood that other operating systems may also be used. Storage device 1018 may store other systems or applications and data utilized by computing device 1000.

[0245] In one embodiment, storage device 1018 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into computing device 1000, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform computing device 1000 by specifying how CPU 1004 transitions between states. According to one embodiment, computing device 1000 is able to access a computer-readable storage medium storing computer-executable instructions that, when executed by computing device 1000, perform the above-described Figures 1 to 10 The computing device 1000 may also include a computer-readable storage medium having stored thereon instructions for performing any other computer-implemented operations described herein.

[0246] The computing device 1000 may also include one or more input / output controllers 1016 for receiving and processing input from a number of input devices, such as a keyboard, a mouse, a touch pad, a touch screen, an electronic stylus, or other types of input devices. Similarly, the input / output controller 1016 may provide output to a display, such as a computer monitor, a flat panel display, a digital projector, a printer, or other types of output devices. It will be appreciated that the computing device 1000 may not include Fig.10 All components shown in the Fig.10 Other components not explicitly shown may be used in conjunction with Fig.10 A completely different architecture is shown in .

[0247] In summary, techniques are described for signal calculation and / or network prioritization of individual flows within a multiplexed session using a secure access gateway for zero trust network access (ZTNA). The secure access gateway may be configured to identify weighted data and / or prioritization data associated with individual flows within a multiplexed session including various protocols (e.g., HTTP / 2 and / or HTTP / 3), and determine a gateway priority value. That is, the secure access gateway may be configured to prioritize certain types of traffic (user roles, resource types, etc.) over other traffic, regardless of the protocols employed by the individual flows. The secure access gateway may then prioritize the processing of a first flow (e.g., networking and / or computing resources) for which the gateway priority value is more favorable than that of a second flow. In addition, the secure access gateway may be configured to transmit an indication of the gateway priority value to a target resource so that flows may be prioritized in the opposite direction.

[0248] Although the present invention is described with respect to specific embodiments, it should be understood that the scope of the present invention is not limited to these specific embodiments. Because other modifications and changes that change to adapt to specific operating requirements and environments are obvious to those skilled in the art, the present invention is not considered to be limited to the examples selected for the purpose of disclosure, but includes all changes and modifications that do not constitute a deviation from the true spirit and scope of the present invention.

[0249] Although the present application describes embodiments with specific structural features and / or method actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Instead, the specific features and actions are merely illustrative of some embodiments falling within the scope of the claims of the present application.

Claims

1. A method comprising: Establishing a first data flow connection between the secure access gateway and one or more client devices, wherein the first data flow connection includes a first Hypertext Transfer Protocol (HTTP) protocol; Establishing a second data flow connection between the secure access gateway and the one or more client devices, wherein the second data flow connection includes a second HTTP protocol different from the first HTTP protocol; determining, by the secure access gateway, first prioritization data associated with the first data flow based at least in part on the one or more client devices; determining, by the secure access gateway, first weighted data associated with the second data flow based at least in part on the second data flow; storing, by the secure access gateway, a first mapping between the first data flow and a first priority value based at least in part on the first prioritization data; storing, by the secure access gateway, a second mapping between the second data flow and a second priority value based at least in part on the first weighted data; determining that the first priority value is more favorable than the second priority value; and Based at least in part on the first priority value being more favorable than the second priority value, the first data stream is processed before the second data stream.

2. The method according to claim 1, wherein: The first HTTP protocol is the HTTP / 3 protocol, and the second HTTP protocol is the HTTP / 2 protocol.

3. The method according to claim 1 or 2, wherein: Processing the first data stream includes at least one of the following: performing an encryption process associated with the first data stream; performing a decryption process associated with the first data stream; executing an agent process associated with the first data flow; performing a routing process associated with the first data flow; performing a forwarding process associated with the first data flow; performing an encapsulation process associated with the first data stream; as well as A decapsulation process associated with the first data flow is performed.

4. The method according to any one of claims 1 to 3, further comprising: One or more bits indicative of the first weighted data are identified in packets associated with the second data stream, wherein determining the first weighted data associated with the second data stream is based at least in part on identifying the one or more bits.

5. The method according to any one of claims 1 to 4, further comprising: An indication of the first prioritization data associated with the first data flow is received from a client device of the one or more client devices, wherein determining the first prioritization data associated with the first data flow is based at least in part on receiving the indication.

6. The method according to any one of claims 1 to 5, further comprising: Determining, by the secure access gateway, a target resource associated with the first data flow; Establishing a third data stream connection between the secure access gateway and the target resource, wherein the third data stream includes at least one of a QUIC protocol, a UDP protocol, or a Transmission Control Protocol (TCP); as well as Prior to processing the second data flow, network data received at the secure access gateway via the first data flow is sent to the target resource via the third data flow.

7. The method according to claim 6, further comprising: determining, by the secure access gateway, one or more quality of service (QOS) bits associated with the first data flow, the one or more QOS bits representing a first mapping between the first data flow and the first priority value; and The one or more QOS bits associated with the first data flow are sent from the secure access gateway to the target resource, the one or more QOS bits causing the target resource to process the first data flow before processing at least the second data flow.

8. A system comprising: one or more processors; as well as One or more computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: The secure access gateway establishes a multiplexed data stream connection with one or more client devices; determining, by the secure access gateway, a first indication of first prioritization data associated with a first data flow in the multiplexed data flow, the first data flow being associated with the first network protocol; determining, by the secure access gateway, a second indication of first weighted data associated with a second data stream in the multiplexed data stream, the second data stream being associated with a second network protocol different than the first network protocol; storing, by the secure access gateway, a first mapping between the first data flow and a first priority value based at least in part on the first indication; storing, by the secure access gateway, a second mapping between the second data flow and a second priority value based at least in part on the second indication; and Based at least in part on the first priority value being more favorable than the second priority value, a first operation associated with the first data flow is performed before a second operation associated with the second data flow.

9. The system according to claim 8, wherein: The first network protocol is a Hypertext Transfer Protocol (HTTP) / 3 protocol, and the second network protocol is an HTTP / 2 protocol.

10. The system according to claim 8 or 9, wherein: Performing the operation associated with the first data flow includes at least one of the following: performing an encryption process associated with the first data stream; performing a decryption process associated with the first data stream; executing an agent process associated with the first data flow; performing a routing process associated with the first data flow; performing a forwarding process associated with the first data flow; performing an encapsulation process associated with the first data stream; as well as A decapsulation process associated with the first data flow is performed.

11. A system according to any one of claims 8 to 10, wherein: The operations also include identifying one or more bits representing the second indication of the first weighted data in packets associated with the second data stream, wherein determining the first weighted data associated with the second data stream is based at least in part on identifying the one or more bits.

12. The system according to any one of claims 8 to 11, wherein the operations further comprise: A first indication of the first prioritization data associated with the first data flow is received from a client device of the one or more client devices, wherein determining the first prioritization data associated with the first data flow is based at least in part on receiving the first indication.

13. A system according to any one of claims 8 to 12, wherein: The operation is a first operation, and the operation further includes: determining, by the secure access gateway, a third indication of one of second prioritization data or second weighted data associated with a third data stream of the multiplexed data stream, the third data stream being associated with one of the first protocol or the second protocol; storing, by the secure access gateway, a third mapping between the third data flow and a third priority value based at least in part on the third indication; determining, by the secure access gateway, that the third priority value is more favorable than the first priority value and the second priority value; and Based at least in part on determining that the third priority value is more favorable than the first priority value and the second priority value, a third operation associated with the third data stream is performed before performing the first operation associated with the first data stream and the second operation associated with the second data stream.

14. The system according to any one of claims 8 to 13, wherein the operations further comprise: determining the first priority value based at least in part on the first prioritization data and a policy associated with the secure access gateway; as well as The second priority value is determined based at least in part on the first weighted data and the policy associated with the secure access gateway.

15. A method comprising: The secure access gateway establishes a multiplexed data stream connection with one or more client devices; determining, by the secure access gateway, a first indication of first prioritization data associated with a first data flow in the multiplexed data flow, the first data flow being associated with the first network protocol; determining, by the secure access gateway, a second indication of first weighted data associated with a second data stream in the multiplexed data stream, the second data stream being associated with a second network protocol different than the first network protocol; storing, by the secure access gateway, a first mapping between the first data flow and a first priority value based at least in part on the first indication; storing, by the secure access gateway, a second mapping between the second data flow and a second priority value based at least in part on the second indication; as well as The first data flow is processed based at least in part on the first priority value being more favorable than the second priority value.

16. The method according to claim 15, wherein: The first network protocol is a Hypertext Transfer Protocol (HTTP) / 2 protocol, and the second network protocol is an HTTP / 3 protocol.

17. The method according to claim 15 or 16, wherein: Processing the first data stream includes at least one of the following: performing an encryption process associated with the first data stream; performing a decryption process associated with the first data stream; executing an agent process associated with the first data flow; performing a routing process associated with the first data flow; performing a forwarding process associated with the first data flow; performing an encapsulation process associated with the first data stream; as well as A decapsulation process associated with the first data flow is performed.

18. The method according to any one of claims 15 to 17, further comprising: Determining, by the secure access gateway, a target resource associated with the first data flow; Establishing a third data stream connection between the secure access gateway and the target resource, wherein the third data stream includes at least one of a QUIC protocol, a UDP protocol, or a Transmission Control Protocol (TCP); determining, by the secure access gateway, one or more quality of service (QOS) bits associated with the first data flow, the one or more QOS bits representing a first mapping between the first data flow and the first priority value, and causing the target resource to process the first data flow before processing at least the second data flow; and Prior to processing the second data flow, network data received at the secure access gateway via the first data flow is sent to the target resource via the third data flow, the network data including the one or more QOS bits associated with the first data flow.

19. A method according to any one of claims 15 to 18, wherein: The first data stream is associated with a first computing device of the one or more computing devices and the second data stream is associated with the first computing device; or The first data stream is associated with the first computing device and the second data stream is associated with a second computing device of the one or more computing devices.

20. The method according to any one of claims 15 to 19, further comprising: determining a first target resource associated with the first data flow based at least in part on the first prioritization data; determining a second target resource associated with the first data flow based at least in part on the first weighted data, the second target resource being different from the first target resource; determining, based at least in part on a policy associated with the secure access gateway, that the first target resource is prioritized over the second target resource; as well as Based at least in part on determining that the first target resource is prioritized higher than the second target resource, the first data stream is processed before the second data stream.

21. An apparatus comprising: means for establishing, by the secure access gateway, a first data flow connection with one or more client devices, wherein the first data flow connection comprises a first Hypertext Transfer Protocol (HTTP) protocol; means for establishing, by the secure access gateway, a second data stream connection with the one or more client devices, wherein the second data stream connection comprises a second HTTP protocol different from the first HTTP protocol; means for determining, by the secure access gateway, first prioritization data associated with the first data flow based at least in part on the one or more client devices; means for determining, by the secure access gateway, first weighted data associated with the second data flow based at least in part on the second data flow; means for storing, by the secure access gateway, a first mapping between the first data flow and a first priority value based at least in part on the first prioritization data; means for storing, by the secure access gateway, a second mapping between the second data flow and a second priority value based at least in part on the first weighted data; means for determining that the first priority value is more favorable than the second priority value; and Means for processing the first data stream before processing the second data stream based at least in part on the first priority value being more favorable than the second priority value.

22. The apparatus of claim 21, further comprising means for implementing the method of any one of claims 2 to 2.

23. An apparatus comprising: means for establishing a multiplexed data stream connection between the secure access gateway and one or more client devices; means for determining, by the secure access gateway, a first indication of first prioritized data associated with a first data flow in the multiplexed data flow, the first data flow being associated with the first network protocol; means for determining, by the secure access gateway, a second indication of first weighted data associated with a second data stream in the multiplexed data stream, the second data stream being associated with a second network protocol different than the first network protocol; means for storing, by the secure access gateway, a first mapping between the first data flow and a first priority value based at least in part on the first indication; means for storing, by the secure access gateway, a second mapping between the second data flow and a second priority value based at least in part on the second indication; as well as Means for processing the first data flow based at least in part on the first priority value being more favorable than the second priority value.

24. The apparatus of claim 23, further comprising means for implementing the method of any one of claims 16 to 20.

25. A computer program, a computer program product or a computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 7 or the steps of the method according to any one of claims 15 to 20.

Images