Abstract: Techniques and systems described herein relate to monitoring executions of computer instructions on computing devices based on learning and generating a control flow directed graph. The techniques and systems include determining an observation phase for a process or application on a computing device. During the observation phase, CPU telemetry is determined and used to generate a control flow directed graph. After the control flow directed graph is generated, a monitoring phase may be entered where transfers of instruction pointers are monitored based on the control flow directed graph to identify invalid transfers.

Abstract: Techniques and systems described herein relate to monitoring executions of computer instructions on computing devices based on learning and generating a control flow directed graph. The techniques and systems include determining telemetry representing execution of a process on a computing system and accessing a learned control flow diagram graph for the process. A transfer of an instruction pointer is determined based on the telemetry and a validity of the transfer is determined based on the learned control flow directed graph. If invalid, then an action to terminate the process is determined, otherwise the action may be allowed to execute when valid.

Abstract: Techniques and systems described herein relate to monitoring executions of computer instructions on computing devices based on learning and generating a control flow directed graph. The techniques and systems include determining a learned control flow directed graph for a process executed on the computing system. A system call is identified during execution of the process as well as a predetermined number of transitions leading to the system call. A validity of the transitions leading the system call is determined based on the learned control flow directed graph and the computing system may perform an action based on the validity.

Abstract: Techniques for migrating on-premises and/or cloud-based workloads to follow a network session as it potentially migrates, due to multipathing techniques, across multiple edge and/or cloud datacenters. The techniques may include determining, by a controller of a network, that a traffic flow between an endpoint device and a workload has migrated to a different path of a multipath flow such that the traffic flow terminates at a different termination point than the workload. Based at least in part on determining that the traffic flow has migrated, the controller may cause a migration of a state of the workload to a location associated with the different termination point. That is, the controller may cause the workload to be migrated in its current state, which may be specific to the endpoint device, to follow the traffic flow.

Abstract: Techniques for creating in/out App Connectors for secure access solutions without the need for STUN, TURN, and/or a long-lived control plane component. The techniques may include, among other things, establishing, by an App Connector associated with a workload hosted by an enterprise network, a pool of idle sessions between the App Connector and a termination node associated with the enterprise network. The techniques may also include determining, by the App Connector, that a first idle session of the pool of idle sessions has been consumed by the termination node to establish a communication session for a client device to communicate with the workload. Based at least in part on determining that the first idle session has been consumed, the techniques may include establishing, by the App Connector, a second idle session to be added to the pool of idle sessions between the App Connector and the termination node.

Abstract: Techniques for routing service mesh traffic based on whether the traffic is encrypted or unencrypted are described herein. The techniques may include receiving, from a first node of a cloud-based network, traffic that is to be sent to a second node of the cloud-based network and determining whether the traffic is encrypted or unencrypted. If it is determined that the traffic is encrypted, the traffic may be sent to the second node via a service mesh of the cloud-based platform. Alternatively, or additionally, if it is determined that the traffic is unencrypted, the traffic may be sent to the second node via an encrypted tunnel. In some examples, the techniques may be performed at least partially by a program running on the first node of the cloud-based network, such as an extended Berkeley Packet Filter (eBPF) program, and the like.

Abstract: Techniques for creating an optimal and secure data plane based on network constraints. The techniques may include establishing an initial networking connection for a data flow between a client device and a resource such that data plane traffic of the data flow is routed through a relay node disposed between the client device and the resource. In some examples, the techniques may include determining, using a Session Traversal Utilities for Network Address Translators (STUN) server, an alternate networking connection for the data flow that bypasses the relay node. Based at least in part on a determination that the alternate networking connection is a more optimal path for the data plane traffic than the initial networking connection, the techniques may include causing the data plane traffic of the data flow to be routed over the alternate networking connection.

Abstract: Techniques for using computer networking protocol extensions to route control-plane traffic and data-plane traffic associated with a common application are described herein. For instance, a traffic flow associated with an application may be established such that control-plane traffic is sent to a control-plane node associated with the application and data-plane traffic is sent to a data-plane node associated with the application. When a client device sends an authentication request to connect to the application, the control-plane node may send an indication of a hostname to be used by the client device to send data-plane traffic to the data-node. As such, when a packet including the hostname corresponding with the data-plane node is received, the packet may be forwarded to the data-plane node.

Abstract: Methods to securely remediate a captive portal are provided. In these methods, a processor of a user device detects a connection, via a network, to a captive portal. Based on the detected connection to the captive portal, the processor launches a dedicated secure web browser, and selectively restricts access of the user device to the network in order to only allow, via the dedicated secure web browser, communications related to remediation with the captive portal.

Abstract: Techniques for scaling additional capacity for secure access solutions and other workloads of enterprise edge networks in and out of a cloud-computing network based on demand. The techniques may include determining that a capacity associated with a secure access node of an enterprise edge network meets or exceeds a threshold capacity. Based at least in part on the capacity meeting or exceeding the threshold capacity, the techniques may include causing a facsimile of the secure access node to be spun up on a cloud-computing network that is remote from the enterprise edge network. In this way, new connection requests received from client devices can be redirected to the facsimile of the secure access node. Additionally, or alternatively, one or more existing connections between client devices and the secure access node may be migrated to the facsimile of the secure access node in the cloud.

Abstract: Techniques for binding communication flows to unique addresses and/or ports, and configuring networking devices internal to a network to apply policy without the need to further introspect a given stream. Further, by creating mappings of unique addresses and/or ports to flows, the network devices are able to enforce policy without needing to coordinate with an edge node of the network at which the communication session terminates. Further, the techniques may include providing an SDN controller with a mapping between a unique address/port and a network flow, determining flow-specific policy to enforce on the flow, and programming one or more network devices to enforce the flow-specific policy in the network using the unique address/port.

Abstract: Techniques for operationalizing workloads at edge network nodes, while maintaining centralized intent and policy controls. The techniques may include storing, in a cloud-computing network, a workload image that includes a function capability. The techniques may also include receiving, at the cloud-computing network, a networking policy associated with an enterprise network. Based at least in part on the networking policy, a determination may be made at the cloud-computing network that the function capability is to be operationalized on an edge device of the enterprise network. The techniques may also include sending the workload image to the edge device to be installed on the edge device to operationalize the function capability. In some examples, the function capability may be a security function capability (e.g., proxy, firewall, etc.), a routing function capability (e.g., network address translation, load balancing, etc.), or any other function capability.

Abstract: Techniques for binding communication flows to unique addresses and/or ports, and configuring networking devices internal to a network to apply policy without the need to further introspect a given stream. Further, by creating mappings of unique addresses and/or ports to flows, the network devices are able to enforce policy without needing to coordinate with an edge node of the network at which the communication session terminates. Further, the techniques may include providing an SDN controller with a mapping between a unique address/port and a network flow, determining flow-specific policy to enforce on the flow, and programming one or more network devices to enforce the flow-specific policy in the network using the unique address/port.

Abstract: Techniques for operationalizing workloads at edge network nodes, while maintaining centralized intent and policy controls. The techniques may include storing, in a cloud-computing network, a workload image that includes a function capability. The techniques may also include receiving, at the cloud-computing network, a networking policy associated with an enterprise network. Based at least in part on the networking policy, a determination may be made at the cloud-computing network that the function capability is to be operationalized on an edge device of the enterprise network. The techniques may also include sending the workload image to the edge device to be installed on the edge device to operationalize the function capability. In some examples, the function capability may be a security function capability (e.g., proxy, firewall, etc.), a routing function capability (e.g., network address translation, load balancing, etc.), or any other function capability.

Abstract: Techniques for NAT-based steering of traffic in cloud-based networks. The techniques may include establishing, by a frontend node of a network, a connection with a client device. The frontend node may receive, via the connection, a packet including an indication of an identity of a service hosted on a backend node of the network. Based at least in part on the indication, the frontend node may establish a second connection with the backend node. Additionally, the frontend node may store a mapping indicating that packets received from the client device are to be sent to the backend node. The techniques may also include receiving another packet at the frontend node or another frontend node of the network. Based at least in part on the mapping, the frontend node or other frontend node may alter one or more network addresses of the other packet and forward it to the backend node.

Abstract: In one embodiment, a monitoring engine obtains mesh flow data for traffic flows between nodes in a service mesh. The monitoring engine associates the mesh flow data with network traffic between an endpoint device and an edge of the service mesh. The monitoring engine identifies, based on the mesh flow data, a particular container workload associated with the traffic flows. The monitoring engine provides an indication that the particular container workload is associated with the network traffic between the endpoint device and the edge of the service mesh.

Abstract: Techniques for a computing resource network to send a packet through a processing flow (e.g., a service chain) according to an order of processing workloads (e.g., services) included in the processing flow, configured as an optimized service chain. In some examples, the computing resource network may include a policy evaluation engine configured to determine the best probabilistic outcome of an order of routing between the services that results in the lowest computational costs based on the probability that a given packet will be terminated/modified at one of the earlier processing workloads in the service chain, a prediction engine configured to determine the order of the processing workloads included in the processing flow based on a policy and/or telemetry data associated with the processing workloads, and/or an intelligent routing engine configured to route a packet between the one or more processing workloads included in a processing flow according to the order.

Abstract: Techniques for operationalizing workloads at edge network nodes, while maintaining centralized intent and policy controls. The techniques may include storing, in a cloud-computing network, a workload image that includes a function capability. The techniques may also include receiving, at the cloud-computing network, a networking policy associated with an enterprise network. Based at least in part on the networking policy, a determination may be made at the cloud-computing network that the function capability is to be operationalized on an edge device of the enterprise network. The techniques may also include sending the workload image to the edge device to be installed on the edge device to operationalize the function capability. In some examples, the function capability may be a security function capability (e.g., proxy, firewall, etc.), a routing function capability (e.g., network address translation, load balancing, etc.), or any other function capability.

Abstract: Techniques for routing service mesh traffic based on whether the traffic is encrypted or unencrypted are described herein. The techniques may include receiving, from a first node of a cloud-based network, traffic that is to be sent to a second node of the cloud-based network and determining whether the traffic is encrypted or unencrypted. If it is determined that the traffic is encrypted, the traffic may be sent to the second node via a service mesh of the cloud-based platform. Alternatively, or additionally, if it is determined that the traffic is unencrypted, the traffic may be sent to the second node via an encrypted tunnel. In some examples, the techniques may be performed at least partially by a program running on the first node of the cloud-based network, such as an extended Berkeley Packet Filter (eBPF) program, and the like.

Abstract: In one embodiment, a service receives traffic telemetry data regarding encrypted traffic sent by an endpoint device in a network. The service analyzes the traffic telemetry data to infer characteristics of an application on the endpoint device that generated the encrypted traffic. The service receives, from a monitoring agent on the endpoint device, application telemetry data regarding the application. The service determines that the application is evasive malware based on the characteristics of the application inferred from the traffic telemetry data and on the application telemetry data received from the monitoring agent on the endpoint device. The service initiates performance of a mitigation action in the network, after determining that the application on the endpoint device is evasive malware.