Skip to content

How the Universal Sensor Works

This article explains what the SenseOn Universal Sensor does on an endpoint after installation, how data flows from the host to the SenseOn analysis platform, and what controls are in place to protect that data. It is aimed at security teams reviewing SenseOn, compliance teams documenting data flows, and sysadmins who want to understand the agent running on their estate.

At a Glance

The Universal Sensor is a host-resident agent that collects security telemetry from endpoints (Windows, macOS, and Linux), processes it locally for early signal extraction, and forwards it to the SenseOn analysis platform over a mutually-authenticated TLS connection. It can also act on the endpoint when instructed, for example to isolate a host from the network, terminate a process, or run a forensic script as part of Active Response.

Key characteristics:

  • Outbound-only network model. The sensor does not listen on any inbound port. All communication is initiated from the endpoint to your tenant's SenseOn domain.
  • Latest version installed automatically. Install commands always fetch the latest published Universal Sensor build. Specific versions can be pinned per Device Segment after install.
  • Mutual TLS to a known set of hostnames. Endpoints communicate with *.snson.net and a small number of supporting AWS S3 buckets. See Connectivity Requirements for the full list.
  • Local buffering when offline. Telemetry is buffered on disk if the endpoint cannot reach the analysis platform, then uploaded when connectivity returns.

Process Model

After installation, the following processes run on a Universal Sensor v7+ endpoint:

Process Role
senseon-seed (service) The main Seed Service. Coordinates the sensor lifecycle, manages configuration, and supervises the other components.
senseon-agent (Windows) / senseon-see (macOS / Linux) The telemetry collection process. Reads OS-level events (process activity, network connections, file changes, authentication, etc.) and forwards them to the broker.
senseon-bootstrapper Handles install-time tasks and the post-install handshake with the SenseOn platform. After bootstrap, it monitors for new sensor versions and applies updates.
senseon-logger Captures local diagnostic and health logs for the sensor itself, separate from security telemetry.
senseon-broker Mediates between the collection process and the network upload path. Performs local buffering and rate limiting.

On Linux, each process runs under a dedicated senseon-epns system user where the OS supports it, with privilege escalation only where required for specific telemetry sources (for example raw socket access for network capture).

Service Names

OS Service identifier Where to view it
Windows senseon-seed Services console (services.msc)
Linux senseon-seed.service systemctl status senseon-seed.service
macOS com.senseon.see (LaunchDaemon) sudo seectl status

Data Flow

The high-level data flow from a host to the SenseOn analysis platform is:

+----------------------+      +-----------------+      +-----------------+
| OS-level events &    |      | Local broker &  |      | SenseOn         |
| network observations | ---> | on-disk buffer  | ---> | analysis        |
| collected by agent   |      | (encrypted)     |      | platform        |
+----------------------+      +-----------------+      +-----------------+
                                       |
                                       v
                                +-----------------+
                                | Local detection |
                                | rules (EPP /    |
                                | inline actions) |
                                +-----------------+

Collection

The agent collects telemetry from the operating system via native APIs and, on Linux, via eBPF where available. Collected categories include:

  • Process telemetry — process creation, parent / child relationships, command line, executable hash, code signature status
  • Network telemetry — TCP / UDP connections, DNS lookups, and TLS metadata. The sensor inspects a broad set of common application-layer protocols (for example HTTP, DNS, TLS, SMB, Kerberos, LDAP, SSH, and FTP) and writes the metadata it extracts from each. Packet payloads are not transmitted to the platform. On Linux without eBPF support, network telemetry is unavailable and only process telemetry is collected. See Endpoint Requirements for details.
  • File telemetry — file create, modify, delete, and rename events for paths covered by the active detection set. Some of these events are analysed by local detection and EPP rules at the moment they occur, but not every observed file event is retained as telemetry on the platform. The retention scope is determined by the active detection set and the segment configuration applied to the device.
  • Authentication telemetry — logon events, account changes, privilege use
  • Endpoint Protection (EPP) telemetry — antivirus / antimalware scan results where EPP is enabled. See Endpoint Protection.

Local processing

Before upload, the broker:

  • Deduplicates highly repetitive events
  • Runs Endpoint Protection (EPP) rules locally so that file and process-level malware decisions are made on-host without waiting for the cloud
  • Applies a subset of detection rules locally, including the rules used by Reflex, so that high-confidence detections trigger automated actions without round-tripping through the cloud
  • Compresses telemetry batches
  • Buffers batches on disk while awaiting upload

Cloud-side analytics still run on the full telemetry once it arrives at the platform, so local processing is additive rather than a replacement.

Upload

Telemetry is uploaded over mutually-authenticated TLS 1.2 or higher to your tenant's SenseOn analysis platform on *.snson.net. The sensor presents a client certificate provisioned during installation, and validates the platform's server certificate against a pinned set of acceptable signers.

If outbound connectivity is unavailable, telemetry continues to be collected and buffered on disk locally. When connectivity returns, the broker drains the buffer in order. See Long Term Telemetry Retention for how the platform retains data on the cloud side after upload.

If TLS interception is in place on your network, you must add *.snson.net to the interception bypass list, otherwise mutual TLS authentication will fail. See TLS Interception.

Security Model

Trust establishment

Each endpoint is provisioned with a unique identity at install time:

  • The installer key (SENSEON_INSTALLER_KEY) is used once during the install handshake to authenticate the endpoint to your tenant. It does not need to be retained on the host after install.
  • During the handshake, the platform issues the endpoint a client TLS certificate and private key. These are stored at OS-specific paths under /etc/senseon-see/ (Linux), /var/senseon-see/ (macOS), and C:\Program Files\senseon-see\ (Windows).
  • A precise.uuid file is generated locally and identifies the host across restarts. See Golden Images for how this interacts with cloned VMs.

Inbound exposure

The Universal Sensor does not open any inbound listening ports, and does not expose a localhost-only IPC listener to other local processes either. All communication to the SenseOn platform, and all Active Response sessions, are initiated outbound from the endpoint to known SenseOn domains.

Active Response

When an analyst initiates an Active Response session, the platform sends signed instructions to the endpoint over the existing outbound mutual TLS channel. The sensor executes those instructions at the same privilege level as the Seed Service (root on Linux / macOS, SYSTEM on Windows). All actions are logged to the per-session audit trail visible at Digital Estate > Session History.

Auto-updates

The sensor downloads new versions from seev4.s3.amazonaws.com (covered by the *.s3.amazonaws.com rule in Connectivity Requirements). Before applying an update, the bootstrapper verifies that the update is signed by SenseOn. Unsigned or incorrectly signed updates are rejected.

Update Model

How versions are managed

  • The install command always installs the latest published version of the Universal Sensor.
  • After install, the sensor checks for new versions on a regular interval. New builds in the configured release stream (GA, Beta, or Alpha) are applied automatically.
  • The release stream and any version pinning are configured per Device Segment, so different parts of your estate can sit on different versions.

Rolling back

If a new version causes an issue, the previous version can be selected in Settings > Device Configuration for the affected segment. The next time the bootstrapper runs, it downgrades the sensor on devices in that segment to the chosen version.

Resource Model

The figures below are taken from Endpoint Requirements and represent typical steady-state use, not absolute limits. Actual usage varies with the workload on the host.

Profile CPU (typical) Memory (typical)
Windows, NDR + EDR only < 0.6% ~ 90 MB
Windows, NDR + EDR + EPP < 1% ~ 300 MB
Linux Comparable to Windows EDR-only profile Comparable to Windows
macOS Comparable to Windows EDR-only profile Comparable to Windows

On servers with EPP enabled and a heavy file I/O workload (file servers, build hosts, database hosts), CPU use can climb temporarily to as much as 20% during scans. See the note on Impact on CPU/RAM in the requirements doc.

Network use

On average, bandwidth use is approximately 28 kilobits per second in steady state, or around 300 MiB per host per 24 hours. Bursts above this baseline occur during active investigations (more telemetry surfaced for a specific host) or following an outage when buffered data is uploaded.

What the Universal Sensor Does Not Do

The following are explicit non-behaviours, intended to address common questions from security teams:

  • It does not capture keystrokes. No keylogging is performed.
  • It does not read clipboard contents. Clipboard data is not collected as telemetry.
  • It does not capture screen content. No screenshots or screen recordings are taken.
  • It does not exfiltrate file contents by default. File telemetry covers metadata and events. File contents are only transferred in two specific cases: when explicitly requested via Active Response by an authorised analyst (and only the specific file requested), or when a detection rule that supports file upload matches on a file. File-upload-on-match is currently in beta and is opt-in per rule.
  • It does not read encrypted application data. The sensor operates at the OS level and does not decrypt content that the OS itself does not see in cleartext.
  • It does not perform active network scans. The sensor is a passive observer of traffic to and from the host. It does not probe other devices on the network, port-scan, or generate synthetic traffic.
  • It is not a remote desktop tool. Active Response sessions execute discrete instructions (scripts, file uploads / downloads, isolation actions). They do not stream the user's screen or keyboard.