10-26 may be protected from threats even when a compute instance 10-26 is not connected to the enterprise facility 102 network, such as when compute instances 22 or 26 use a network that is outside of the enterprise facility 102 and separated from the enterprise facility 102, e.g., by a gateway, a public network, and so forth.

In some implementations, compute instances 10-26 may communicate with cloud applications, such as a SaaS application 156. The SaaS application 156 may be an application that is used by but not operated by the enterprise facility 102. Examples of commercially available SaaS applications 156 include Salesforce, Amazon Web Services (AWS) applications, Google Apps applications, Microsoft Office 365 applications and so on. A given SaaS application 156 may communicate with an identity provider 158 to verify user identity consistent with the requirements of the enterprise facility 102. The compute instances 10-26 may communicate with an unprotected server (not shown) such as a web site or a third-party application through an network 154 such as the Internet or any other public network, private network or combination thereof.

In embodiments, aspects of the threat management facility 100 may be provided as a stand-alone solution. In other embodiments, aspects of the threat management facility 100 may be integrated into a third-party product. An application programming interface (e.g., a source code interface) may be provided such that aspects of the threat management facility 100 may be integrated into or used by or with other applications. For instance, the threat management facility 100 may be stand-alone in that it provides direct threat protection to an enterprise or computer resource, where protection is subscribed to the facility 100. Alternatively, the threat management facility 100 may offer protection indirectly, through a third-party product, where an enterprise may subscribe to services through the third-party product, and threat protection to the enterprise may be provided by the threat management facility 100 through the third-party product.

The security management facility 122 may provide protection from a variety of threats by providing, as non-limiting examples, endpoint security and control, email security and control, web security and control, reputation-based filtering, machine learning classification, control of unauthorized users, control of guest and non-compliant computers, and more.

The security management facility 122 may provide malicious code protection to a compute instance. The security management facility 122 may include functionality to scan applications, files, and data for malicious code, remove or quarantine applications and files, prevent certain actions, perform remedial actions, as well as other security measures. Scanning may use any of a variety of techniques, including without limitation signatures, identities, classifiers, and other suitable scanning techniques. In embodiments, the scanning may include scanning some or all files on a periodic basis, scanning an application when the application is executed, scanning data transmitted to or from a device, scanning in response to predetermined actions or combinations of actions, and so forth. The scanning of applications, files, and data may be performed to detect known or unknown malicious code or unwanted applications. Aspects of the malicious code protection may be provided, for example, in a security agent of an endpoint 12, in a wireless access point 11 or firewall 10, as part of application protection 150 provided by the cloud, and so on.

In an embodiment, the security management facility 122 may provide for email security and control, for example to target spam, viruses, spyware and phishing, to control email content, and the like. Email security and control may protect against inbound and outbound threats, protect email infrastructure, prevent data leakage, provide spam filtering, and more. Aspects of the email security and control may be provided, for example, in the security agent of an endpoint 12, in a wireless access point 11 or firewall 10, as part of application protection 150 provided by the cloud, and so on.

In an embodiment, security management facility 122 may provide for web security and control, for example, to detect or block viruses, spyware, malware, or unwanted applications; help control web browsing; and the like, which may provide comprehensive web access control to enable safe and productive web browsing. Web security and control may provide Internet use policies, reporting on suspect compute instances, security and content filtering, active monitoring of network traffic, Uniform Resource Identifier (URI) filtering, and the like. Aspects of the web security and control may be provided, for example, in the security agent of an endpoint 12, in a wireless access point 11 or firewall 10, as part of application protection 150 provided by the cloud, and so on.

In an embodiment, the security management facility 122 may provide for network access control, which generally controls access to and use of network connections. Network control may stop unauthorized, guest, or non-compliant systems from accessing networks, and may control network traffic that is not otherwise controlled at the client level. In addition, network access control may control access to virtual private networks (VPN), where VPNs may, for example, include communications networks tunneled through other networks and establishing logical connections acting as virtual networks. In embodiments, a VPN may be treated in the same manner as a physical network. Aspects of network access control may be provided, for example, in the security agent of an endpoint 12, in a wireless access point 11 or firewall 10, as part of application protection 150 provided by the cloud, e.g., from the threat management facility 100 or other network resource(s).

In an embodiment, the security management facility 122 may provide for host intrusion prevention through behavioral monitoring and/or runtime monitoring, which may guard against unknown threats by analyzing application behavior before or as an application runs. This may include monitoring code behavior, application programming interface calls made to libraries or to the operating system, or otherwise monitoring application activities. Monitored activities may include, for example, reading and writing to memory, reading and writing to disk, network communication, process interaction, and so on. Behavior and runtime monitoring may intervene if code is deemed to be acting in a manner that is suspicious or malicious. Aspects of behavior and runtime monitoring may be provided, for example, in the security agent of an endpoint 12, in a wireless access point 11 or firewall 10, as part of application protection 150 provided by the cloud, and so on.

In an embodiment, the security management facility 122 may provide for reputation filtering, which may target or identify sources of known malware. For instance, reputation filtering may include lists of URIs of known sources of malware or known suspicious IP addresses, code authors, code signers, or domains, that when detected may invoke an action by the threat management facility 100. Based on reputation, potential threat sources may be blocked, quarantined, restricted, monitored, or some combination of these, before an exchange of data can be made. Aspects of reputation filtering may be provided, for example, in the security agent of an endpoint 12, in a wireless access point 11 or firewall 10, as part of application protection 150 provided by the cloud, and so on. In embodiments, some reputation information may be stored on a compute instance 10-26, and other reputation data available through cloud lookups to an application protection lookup database, such as may be provided by application protection 150.

In embodiments, information may be sent from the enterprise facility 102 to a third party, such as a security vendor, or the like, which may lead to improved performance of the threat management facility 100. In general, feedback may be useful for any aspect of threat detection. For example, the types, times, and number of virus interactions that an enterprise facility 102 experiences may provide useful information for the preventions of future virus threats. Feedback may also be associated with behaviors of individuals within the enterprise, such as being associated with most common violations of policy, network access, unauthorized application loading, unauthorized external device use, and the like. In embodiments, feedback may enable the evaluation or profiling of client actions that are violations of policy that may provide a predictive model for the improvement of enterprise policies.

An update facility 120 may provide control over when updates are performed. The updates may be automatically transmitted, manually transmitted, or some combination of these. Updates may include software, definitions, reputations or other code or data that may be useful to the various facilities. For example, the update facility 120 may manage receiving updates from a provider, distribution of updates to enterprise facility 102 networks and compute instances, or the like. In embodiments, updates may be provided to the enterprise facility's 102 network, where one or more compute instances on the enterprise facility's 102 network may distribute updates to other compute instances.

The threat management facility 100 may include a policy management facility 112 that manages rules or policies for the enterprise facility 102. Examples of rules include access permissions associated with networks, applications, compute instances, users, content, data, and the like. The policy management facility 112 may use a database, a text file, other data store, or a combination to store policies. In an embodiment, a policy database may include a block list, a black list, an allowed list, a white list, and more. As a few non-limiting examples, policies may include a list of enterprise facility 102 external network locations/applications that may or may not be accessed by compute instances, a list of types/classifications of network locations or applications that may or may not be accessed by compute instances, and contextual rules to evaluate whether the lists apply. For example, there may be a rule that does not permit access to sporting websites. When a website is requested by the client facility, a security management facility 122 may access the rules within a policy facility to determine if the requested access is related to a sporting website.

The policy management facility 112 may include access rules and policies that are distributed to maintain control of access by the compute instances 10-26 to network resources. These policies may be defined for an enterprise facility, application type, subset of application capabilities, organization hierarchy, compute instance type, user type, network location, time of day, connection type, or any other suitable definition. Policies may be maintained through the threat management facility 100, in association with a third party, or the like. For example, a policy may restrict instant messaging (IM) activity by limiting such activity to support personnel when communicating with customers. More generally, this may allow communication for departments as necessary or helpful for department functions, but may otherwise preserve network bandwidth for other activities by restricting the use of IM to personnel that need access for a specific purpose. In an embodiment, the policy management facility 112 may be a stand-alone application, may be part of the network server facility 142, may be part of the enterprise facility 102 network, may be part of the client facility, or any suitable combination of these.

The policy management facility 112 may include dynamic policies that use contextual or other information to make security decisions. As described herein, the dynamic policies facility 170 may generate policies dynamically based on observations and inferences made by the analytics facility. The dynamic policies generated by the dynamic policy facility 170 may be provided by the policy management facility 112 to the security management facility 122 for enforcement.

In embodiments, the threat management facility 100 may provide configuration management as an aspect of the policy management facility 112, the security management facility 122, or some combination. Configuration management may define acceptable or required configurations for the compute instances 10-26, applications, operating systems, hardware, or other assets, and manage changes to these configurations. Assessment of a configuration may be made against standard configuration policies, detection of configuration changes, remediation of improper configurations, application of new configurations, and so on. An enterprise facility may have a set of standard configuration rules and policies for particular compute instances which may represent a desired state of the compute instance. For example, on a given compute instance 12, 14, 18, a version of a client firewall may be required to be running and installed. If the required version is installed but in a disabled state, the policy violation may prevent access to data or network resources. A remediation may be to enable the firewall. In another example, a configuration policy may disallow the use of Universal Serial Bus (USB) disks, and the policy management facility 112 may require a configuration that turns off USB drive access via a registry key of a compute instance. Aspects of configuration management may be provided, for example, in the security agent of an endpoint 12, in a wireless access point 11 or firewall 10, as part of application protection 150 provided by the cloud, or any combination of these.

In embodiments, the threat management facility 100 may also provide for the isolation or removal of certain applications that are not desired or may interfere with the operation of a compute instance 10-26 or the threat management facility 100, even if such application is not malware per se. The operation of such products may be considered a configuration violation. The removal of such products may be initiated automatically whenever such products are detected, or access.

The policy management facility 112 may also require update management (e.g., as provided by the update facility 120). Update management for the security management facility 122 and policy management facility 112 may be provided directly by the threat management facility 100, or, for example, by a hosted system. In embodiments, the threat management facility 100 may also provide for patch management, where a patch may be an update to an operating system, an application, a system tool, or the like, where one of the reasons for the patch is to reduce vulnerability to threats.

In embodiments, the security management facility 122 and policy management facility 112 may push information to the enterprise facility 102 network and/or the compute instances 10-26, the enterprise facility 102 network and/or compute instances 10-26 may pull information from the security management facility 122 and policy management facility 112, or there may be a combination of pushing and pulling of information. For example, the enterprise facility 102 network and/or compute instances 10-26 may pull update information from the security management facility 122 and policy management facility 112 via the update facility 120, an update request may be based on a time period, by a certain time, by a date, on demand, or the like. In another example, the security management facility 122 and policy management facility 112 may push the information to the enterprise facility's 102 network and/or compute instances 10-26 by providing notification that there are updates available for download and/or transmitting the information. In an embodiment, the policy management facility 112 and the security management facility 122 may work in concert with the update facility 120 to provide information to the enterprise facility's 102 network and/or compute instances 10-26. In various embodiments, policy updates, security updates and other updates may be provided by the same or different modules, which may be the same or separate from a security agent running on one of the compute instances 10-26.

As threats are identified and characterized, the definition facility 114 of the threat management facility 100 may manage definitions used to detect and remediate threats. For example, identity definitions may be used for scanning files, applications, data streams, etc. for the determination of malicious code. Identity definitions may include instructions and data that can be parsed and acted upon for recognizing features of known or potentially malicious code. Definitions also may include, for example, code or data to be used in a classifier, such as a neural network or other classifier that may be trained using machine learning. Updated code or data may be used by the classifier to classify threats. In embodiments, the threat management facility 100 and the compute instances 10-26 may be provided with new definitions periodically to include most recent threats. Updating of definitions may be managed by the update facility 120, and may be performed upon request from one of the compute instances 10-26, upon a push, or some combination. Updates may be performed upon a time period, on demand from a device 10-26, upon determination of an important new definition or a number of definitions, and so on.

A threat research facility (not shown) may provide a continuously ongoing effort to maintain the threat protection capabilities of the threat management facility 100 in light of continuous generation of new or evolved forms of malware. Threat research may be provided by researchers and analysts working on known threats, in the form of policies, definitions, remedial actions, and so on.

The security management facility 122 may scan an outgoing file and verify that the outgoing file is permitted to be transmitted according to policies. By checking outgoing files, the security management facility 122 may be able discover threats that were not detected on one of the compute instances 10-26, or policy violation, such transmittal of information that should not be communicated unencrypted.

The threat management facility 100 may control access to the enterprise facility 102 networks. A network access facility 124 may restrict access to certain applications, networks, files, printers, servers, databases, and so on. In addition, the network access facility 124 may restrict user access under certain conditions, such as the user's location, usage history, need to know, job position, connection type, time of day, method of authentication, client-system configuration, or the like. Network access policies may be provided by the policy management facility 112, and may be developed by the enterprise facility 102, or pre-packaged by a supplier. Network access facility 124 may determine if a given compute instance 10-22 should be granted access to a requested network location, e.g., inside or outside of the enterprise facility 102. Network access facility 124 may determine if a compute instance 22, 26 such as a device outside the enterprise facility 102 may access the enterprise facility 102. For example, in some cases, the policies may require that when certain policy violations are detected, certain network access is denied. The network access facility 124 may communicate remedial actions that are necessary or helpful to bring a device back into compliance with policy as described below with respect to the remedial action facility 128. Aspects of the network access facility 124 may be provided, for example, in the security agent of the endpoint 12, in a wireless access point 11, in a firewall 10, as part of application protection 150 provided by the cloud, and so on.

In an embodiment, the network access facility 124 may have access to policies that include one or more of a block list, a black list, an allowed list, a white list, an unacceptable network site database, an acceptable network site database, a network site reputation database, or the like of network access locations that may or may not be accessed by the client facility. Additionally, the network access facility 124 may use rule evaluation to parse network access requests and apply policies. The network access facility 124 may have a generic set of policies for all compute instances, such as denying access to certain types of websites, controlling instant messenger accesses, or the like. Rule evaluation may include regular expression rule evaluation, or other rule evaluation method(s) for interpreting the network access request and comparing the interpretation to established rules for network access. Classifiers may be used, such as neural network classifiers or other classifiers that may be trained by machine learning.

The threat management facility 100 may include an asset classification facility 160. The asset classification facility will discover the assets present in the enterprise facility 102. A compute instance such as any of the compute instances 10-26 described herein may be characterized as a stack of assets. The one level asset is an item of physical hardware. The compute instance may be, or may be implemented on physical hardware, and may have or may not have a hypervisor, or may be an asset managed by a hypervisor. The compute instance may have an operating system (e.g., Windows, macOS, OS X, Linux, Android, IOS). The compute instance may have one or more layers of containers. The compute instance may have one or more applications, which may be native applications, e.g., for a physical asset or virtual machine, or running in containers within a computing environment on a physical asset or virtual machine, and those applications may link libraries or other code or the like, e.g., for a user interface, cryptography, communications, device drivers, mathematical or analytical functions and so forth. The stack may also interact with data. The stack may also or instead interact with users, and so users may be considered assets.

The threat management facility 100 may include the entity model facility 162. The entity models may be used, for example, to determine the events that are generated by assets. For example, some operating systems may provide useful information for detecting or identifying events. For examples, operating systems may provide process and usage information that accessed through an application programming interface (API). As another example, it may be possible to instrument certain containers to monitor the activity of applications running on them. As another example, entity models for users may define roles, groups, permitted activities and other attributes.

The event collection facility 164 may be used to collect events from any of a wide variety of sensors that may provide relevant events from an asset, such as sensors on any of the compute instances 10-26, the application protection 150, a cloud computing instance 109 and so on. The events that may be collected may be determined by the entity models. There may be a variety of events collected. Events may include, for example, events generated by the enterprise facility 102 or the compute instances 10-26, such as by monitoring streaming data through a gateway such as firewall 10 and wireless access point 11, monitoring activity of compute instances, monitoring stored files/data on the compute instances 10-26 such as desktop computers, laptop computers, other mobile computing devices, and cloud computing instances 19, 109. Events may range in granularity. One example of an event is the communication of a specific packet over the network. Another example of an event may be identification of an application that is communicating over a network.

The event logging facility 166 may be used to store events collected by the event collection facility 164. The event logging facility 166 may store collected events so that they can be accessed and analyzed by the analytics facility 168. Some events may be collected locally, and some events may be communicated to an event store in a central location or cloud facility. Events may be logged in any suitable format.

Events collected by the event logging facility 166 may be used by the analytics facility 168 to make inferences and observations about the events. These observations and inferences may be used as part of policies enforced by the security management facility Observations or inferences about events may also be logged by the event logging facility 166.

When a threat or other policy violation is detected by the security management facility 122, the remedial action facility 128 may remediate the threat. Remedial action may take a variety of forms, non-limiting examples including collecting additional data about the threat, terminating or modifying an ongoing process or interaction, sending a warning to a user or administrator, downloading a data file with commands, definitions, instructions, or the like to remediate the threat, requesting additional information from the requesting device, such as the application that initiated the activity of interest, executing a program or application to remediate against a threat or violation, increasing telemetry or recording interactions for subsequent evaluation, (continuing to) block requests to a particular network location or locations, scanning a requesting application or device, quarantine of a requesting application or the device, isolation of the requesting application or the device, deployment of a sandbox, blocking access to resources, e.g., a USB port, or other remedial actions. More generally, the remedial action facility 128 may take any steps or deploy any measures suitable for addressing a detection of a threat, potential threat, policy violation or other event, code or activity that might compromise security of a computing instance 10-26 or the enterprise facility 102.

FIG. 2 illustrates a system 200 for processing a network communication in accordance with existing techniques. The system 200 includes a cloud server 202 with virtual machines 204a, 204b, and 204c, and a receiving unit 206 for passing instructions to the virtual machines 204a, 204b, and 204c. The cloud server 202 may be accessible over a network 208 and in communication with terminals 210a, 210b, and 210c. Each terminal 210a-c may have a dedicated access tunnel with a respective gateway 212a-c. That is, terminal 210a has a dedicated access tunnel with gateway 212a, terminal 210b has a dedicated access tunnel with gateway 212b, etc.

In operation, each virtual machine 204a-c may be associated with a particular function or application, and have a dedicated access tunnel with the corresponding gateway 212a-c. Accordingly, when a request is sent from a terminal, the intended virtual machine is known, and the request can be forwarded to the intended virtual machine.

Often times, however, there may not be an established tunnel from an endpoint device to a desired network resource. Similarly, a user may not know which instance has an established tunnel with the desired network resource. Accordingly, a user may make a request, but the request may reach a virtual machine instance that does not have an established tunnel with the desired network resource. In this case, a user then have to make a second request.

FIG. 3 illustrates a system 300 for processing a network communication in accordance with one embodiment. The system 300 may be instantiated by the enterprise facility 102 of FIG. 1 and include components shown in FIG. 1. For example, the system 300 may include one or more user devices 28 executing a user interface 302. The system 300 may further include the firewall 10, cloud compute instances 19a, 19b, 19c, . . . 19n, where n is the number of cloud compute instances in or otherwise associated with the enterprise facility 102, the application load balancer (ALB) 30, the network load balancer (NLB) 34, and one or more databases 32. The instances 19a-n of FIG. 4 each include a proxy component (e.g., instance 19a includes proxy component 304a, instance 19c includes proxy component 304c, etc. These proxy components may use the Socket Secure network protocol to communicate with each other, or at the very least to enable the instance 19a to forward a request to instance 19c. The instance 19c may then forward 424 the request to the firewall 10. The firewall 10 may transmit any appropriate response 426 to acknowledge the request.

FIG. 4 illustrates a message sequence diagram 400 for processing a network communication in accordance with one embodiment. The message sequence diagram 500 references the components of FIG. 4.

When the firewall 10 is initiated, it may first send a request 402 to the NLB 34. The request may be to establish a connection with one of the compute instances 19a-n. The NLB 34 may monitor or otherwise track how many connections are established with instances 19a-n, and may distribute incoming requests based on one or more rules. For example, the NLB 34 may perform a check 404 with an internal counting mechanism to determine which instances are the most or least loaded.

In FIG. 4, the NLB 34 identified that instance 19c is the least loaded of the instances 19a-n, and forwards the request 406 to instance 19c. The instance 19c may respond to the request 408, such as part of a handshake procedure, and a secure tunnel may be established 410 between the firewall 10 and the instance 19c. The secure tunnel between the firewall 10 and the instance 19c may be an SSH tunnel. The instance 19c may also communicate details of the connection 512 to the database 32 for later retrieval.

Some time later, a user of the user device may attempt to access the firewall 10. For example, the user may be a network administrator tasked with monitoring a network, and may want to view a user interface associated with the firewall 10 to view activity occurring on their network. For example, the user interface 302 may execute a browser to issue a request 514 to access the firewall 10. The request may be communicated to the ALB 30, and may be an HTTPS or HTTP request including a network resource locator. The embodiments described herein may also implement single sign-on (SSO) authentication methods to allow a user to authenticate with multiple instances and network resources using a single set of credentials.

The ALB 30 may receive requests and make routing decisions at the application layer. The ALB may direct the request 416 to an instance such as instance 19a. As shown in FIGS. 3 and 4, however, instance 19a is not the instance that has the established tunnel with the firewall 10.

Upon receipt of the request, the instance 19a may reference 418 the database 32 to identify which instance 19b-n has the established tunnel with the firewall 10. As seen in FIGS. 3 and 4, the instance 19a may identify 420 that instance 19c has the established tunnel.

Rather than having the instance 19a relay this information to the ALB 30, the instance 19a forwards the request 422 to instance 19c directly. For example, the instance 19a may use the SOCKS proxy to forward the request to the instance 19c.

Accordingly, each of the instances 19a-n may have at least three ports open. These may include a first port to establish an SSH connection with the firewall 10 via the NLB 34, a second port to establish a connection with the ALB 30, and a third, SOCKS proxy port to establish a connection with another instance. As discussed previously, the instances 19a-n may use an HTTP port to connect to the ALB 30. The SOCKS proxy on each instance may only be accessed by other instances for security purposes.

Accordingly, instances 19a and 19c may each be configured with a proxy component 404a and 404c, respectively. As discussed above, these proxy components 404a and 404c may communicate with each other, or at the very least to enable the instance 19a to forward the request to instance 19c. The instance 19c may then forward 524 the request to the firewall 10. The firewall 10 may transmit any appropriate response 526 to acknowledge the request.

FIG. 5 depicts a flowchart of a method 500 for processing an electronic communication in accordance with one embodiment. The components of FIG. 1 may perform the steps of method 500.

Step 502 involves receiving a request at a first proxy service 302a to access a network endpoint device. The network endpoint device may be associated with an endpoint device such as a firewall 10, for example. The proxy service 302a may be associated with a compute instance 19a. The compute instance 19a may be a cloud computing service such as the AMAZON EC2® computing service by Amazon.com, Inc. headquartered in Seattle, Washington.

Step 504 involves referencing, by the first proxy service 304a, a database 32 to identify a second proxy service 404c, wherein the second proxy service 404c is identified based on having a previously-established secure tunnel with the network endpoint device. Specifically, the second proxy service 304c may be executed by or otherwise associated with a compute instance 19c that has a previously established tunnel with the firewall 10.

Step 506 involves forwarding the request from the first proxy service 304a to the second proxy service 304c. As discussed previously, the first proxy service 304a may forward the request using a SOCKS proxy.

Step 508 involves forwarding the request from the second proxy service 304c through the previously-established secure tunnel to the network endpoint device associated with the firewall 10. Accordingly, the request reaches the firewall 10 without requiring a user to make a second request.

The disclosed embodiments provide novel features and advantages over existing techniques. As discussed previously, existing techniques for accessing resources such as individual firewalls over an enterprise network suffer from various drawbacks. First, these techniques generally involve establishing a secure tunnel between an appliance and one of many compute instances. When a user attempts to access the firewall, the request may not reach the instance that has the tunnel with the firewall. In fact, as the number of compute instances increases, the likelihood of the request reaching the correct instance decreases.

The described embodiments overcome these disadvantages of existing techniques by processing a network request even in situations in which an endpoint device does not have an established tunnel with a desired network resource. The described embodiments also remove redirects and obviate the need for the user to, for example, make a second request. In accordance with the described embodiments, the compute instance that receives the request may forward the request to the correct instance (i.e., the instance that has an established tunnel with the firewall). From there, the request is passed on to the firewall through the established tunnel.

Accordingly, the described embodiments do not require the user's browser to redirect to a different instance. By allowing the instance that initially received a user request to proxy the request to the correct instance, the described embodiments are quicker and require fewer processing steps in comparison to existing techniques.

According to one aspect, embodiments relate to a method for processing an electronic communication. The method includes receiving a request at a first proxy service to access a network endpoint device; referencing, by the first proxy service, a database to identify a second proxy service, wherein the second proxy service is identified based on having a previously-established secure tunnel with the network endpoint device; forwarding the request from the first proxy service to the second proxy service; and forwarding the request from the second proxy service through the previously-established secure tunnel to the network endpoint device.

In some embodiments, referencing the database involves the first proxy service querying the database to identify the second proxy service having the previously-established secure tunnel with the network endpoint device.