Skip to main content

Upwind Sensors

Overview​

Upwind is a runtime security platform and observability tool. What this means is Upwind applies policy and filtering directly with eBPF in the kernel. It performs the filtering, blocking, and reacting to events directly in the kernel instead of sending events to a user space agent.

Applying filters directly in the kernel drastically reduces observation overhead. By avoiding expensive context switching and wake-ups, especially for high frequency events, such as send, read, or write operations, eBPF reduces required resources. Upwind provides rich filters (file, socket, binary names, namespace/capabilities, etc.) in eBPF, which allows users to get runtime context enrichment on all of events.

Upwind detects and is able to respond to security-significant events, such as

  • Process execution events
  • System call activity
  • I/O activity including network & file access

Runtime Security for Kubernetes​

Architecture​

image1.png

Sensor DaemonSet​

The Upwind Sensor collects real time view of activity occuring at the kernel level. The Sensor monitors and collects process, file system, network and system call activity for all the containers running on the node. This access also allows us to not only detect but also take preventative actions like stopping compromised containers and blocking malicious processes.

The Upwind Sensor runs as a user mode process. If sensor were to fail there would be no impact on the containers or the host kernel itself.

The Upwind Sensor is required and is deployed automatically when using the Upwind Operator. The Upwind Operator creates the necessary RBACs and deploys the Upwind Sensor as a daemonSet.

Cluster Manager​

The Upwind Cluster Manager provides a streamlined, centralized approach to collecting cluster level data. By acting as a proxy between the API server and node-based sensors, the Cluster Manager helps to alleviate server load. It also relays cluster level metadata, allowing to enrich the metadata of collected data.

The Upwind Cluster Manager allows you to:

  • Alleviate the impact of sensors on your infrastructure.
  • Provide cluster level metadata that can only be found in the API server to the Upwind Sensor, in order for them to enrich the metadata of the collected data.
  • Enable the collection of cluster level data, such as the monitoring of services and events.

The Cluster Manager is required and is deployed automatically when using the Upwind Operator. The Upwind Operator creates the necessary RBACs and deploys the Cluster Manager deployment.

Operator​

Upwind Operator is an open source Kubernetes Operator that enables you to deploy and configure the Upwind Sensor and Upwind Cluster Sensor in a Kubernetes environment.

By using the Operator a single chart will deploy the Uwpind Sensor, Upwind Cluster Sensor and Upwind CRDs. The Operator reports deployment status, health, and errors in the Operator's CRD status. Because the Operator uses higher-level configuration options, it limits the risk of misconfiguration.

The Upwind Operator provides the following:

  • Validation for your Sensor configurations
  • Keeping all Sensors up-to-date with your configuration
  • Orchestration for creating and updating Sensor resources
  • Reporting of Sensor configuration status in the Operator's CRD status

Runtime Security for Hosts​

Sensor​

The Upwind Sensor collects real time view of activity occuring at the kernel level. The Sensor monitors and collects process, file system, network and system call activity on the host. This access also allows us to not only detect but also take preventative actions like stopping compromised containers and blocking malicious processes.

The Upwind Sensor runs as a user mode process. If sensor were to fail there would be no impact on the host, or the kernel itself.

Differences between sensors for hosts and containers​

On a host, the Sensor is configured using a YAML file or environment variables, whereas the Sensor configuration options for kubernetes are configured with the values of the Helm chart.

Similarly, while on a host, integrations and customizations are identified through the Sensor configuration file, in a container environment, integrations are automatically identified.

Connectivity​

Upwind is a SaaS product: you need to establish an outbound connection from your network to the public internet. Upwind Sensor must be able to communicate over the network to send data (alerts, events, etc) back to the Upwind SaaS Platform. Traffic is always initiated by the Sensor to Upwind from TLS-encrypted TCP connection by default. No sessions are ever initiated from Upwind back to the Sensor. Additionally, if you want to protect resources with no direct connectivity to the public internet, or with restricted outbound traffic, consider submitting data from a proxy. By default, Upwind Sensor connects to Upwind SaaS with a websocket on TCP port 443. All traffic between Upwind Sensor and Upwind SaaS is TLS encrypted. The Upwind Sensor submits data to Upwind over a TLS-encrypted TCP connection by default.

Sensor Log Obfuscation​

The Upwind Sensor generates local logs in order to support Sensor troubleshooting as required. As a safety precaution, these local logs are filtered for some specific keywords and patterns that could indicate a potential credential (for example, API key, password, and token keywords), which are then obfuscated before being written to disk.

Security​

Upwind Sensor has no privileged access to Upwind SaaS. By design, Upwind SaaS and Upwind Sensor don't trust each other and Upwind Sensor mutual certificate-based authentication is required to connect. Upwind Sensor's capabilities are limited to getting policies from Upwind SaaS and sending event data to Upwind SaaS.

If Upwind Sensor were to be compromised, the risk would be local to the system where it is deployed, the privilege it has on the local system, and the possibility of it sending garbage data to Upwind SaaS. Upwind Sensor has no ability to interact with Upwind SaaS beyond the websocket. Both Upwind SaaS API and web interfaces, served on port 443 (HTTPS), require authentication over a different channel with different credentials (e.g. username and password, oauth token).

For more details on Upwind's security review Security and Trust Center