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.
  • Two components from v7.0. The bootstrapper installs the sensor, keeps it up to date and refreshes its configuration. The sensor does the collection. See Universal Sensor v7.
  • 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

On a v7.0 or later endpoint, the agent is two components, and each brings its own services. The bootstrapper installs and maintains the sensor, and the sensor does the collection. See Universal Sensor v7 for how the two fit together.

Component Process Role
bootstrapper senseon-bootstrapper Handles install-time tasks and the post-install handshake with the SenseOn platform. After that it installs sensor updates, updates itself, and refreshes the agent's configuration.
bootstrapper senseon-broker Mediates between the collection process and the network upload path. Performs local buffering and rate limiting.
bootstrapper senseon-logger Captures local diagnostic and health logs for the agent itself, separate from security telemetry.
sensor senseon-seed The main Seed Service. Coordinates the sensor lifecycle, manages configuration, and reads OS-level events (process activity, network connections, file changes, authentication, and so on). On Windows the binary is senseon-seed.exe.
sensor senseon-epp (Windows) The Endpoint Protection service. See Endpoint Protection.

A Windows host on v7.0 or later therefore runs five SenseOn services. Sensor versions before 7.0.40 run senseon-quarantine in place of senseon-epp. A legacy Windows host, on v6.x or earlier, runs senseon-seed and senseon-quarantine and has no bootstrapper.

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

The identifiers below are for the sensor. The bootstrapper's own services are listed in Universal Sensor v7.

OS Service identifier Where to view it
Windows senseon-seed Services console (services.msc)
Linux senseon-seed.service systemctl status senseon-seed.service
macOS io.senseon.endpoint-sensor (LaunchDaemon) sudo launchctl list io.senseon.endpoint-sensor

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 to Admins with Active Response access at Assets > Device Session History.

Auto-updates

Where the update package is downloaded from depends on the sensor version:

  • v6.x and earlier download the package directly from seev4.s3.<your-region>.amazonaws.com, where <your-region> is the AWS region hosting your tenant. This is covered by the *.s3.<your-region>.amazonaws.com rule in Connectivity Requirements.
  • v7.0 and later, installed via the bootstrapper, download the package from the appliance, which retrieves it from S3 on the endpoint's behalf. These agents do not contact S3 to update.

Note that crash diagnostic uploads and Active Response file transfers, such as the scripts an analyst runs, go directly to S3 on every version. S3 connectivity is still required on estates that are fully on v7.0 or later. The session itself does not use S3: instructions travel over the mutual TLS channel described above.

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.
  • A sensor on v7.0 or later does not update itself. The bootstrapper asks the SenseOn platform roughly every ten minutes which sensor version the device should be on, and installs the version it is given. It updates itself on the same cycle.
  • Which version a device should be on is set per Device Segment in Settings > Device Configuration: update automatically (the default), hold the version the device already has, or run a specific version. Different parts of the estate can therefore sit on different versions. These settings govern agents on v7.0 and later. Automatic updates are off by default for v6.x and earlier, which stay on their installed version until they are moved to v7. See Universal Sensor v7.
  • Segments set to update automatically receive new builds from the release streams enabled for your organisation. SenseOn manages which release streams (GA, Beta, or Alpha) are enabled, and GA is on by default.
  • To stage a new version across the estate, create a segment for the devices you want to go first. There is no percentage-based or canary rollout.

When a device does not get the version you pinned

A sensor release can require a minimum bootstrapper version, because some releases need an installer capability that an older bootstrapper does not have. The platform offers such a release only to devices whose bootstrapper meets that minimum. A bootstrapper below the minimum, or one that does not report a version, does not qualify.

This has two effects you may see in Assets > Devices:

  • A device reports a lower version than the one you pinned. When a device cannot install the pinned version, it is given the newest version it can install at or below the pin, and it runs that instead. The pin stays as you set it and no error is raised, so the version the device reports is the one to trust.
  • A device stays on its current version. If no release qualifies for that device at all, the platform has nothing to offer it and the sensor is left as it is.

ℹ What to do: Compare the agent version each device reports in Assets > Devices with the version pinned on its segment. The bootstrapper updates itself independently of the segment setting, so a device with a healthy connection to the platform usually catches up on its own within a few update cycles. If a device stays behind, check that it is connecting using Troubleshooting, and contact support if it is.

SenseOn can also hold a platform at or below a maximum sensor version, for example while a release is being qualified. This is not a customer setting and is normally not in use. While it is in place, devices are not given versions above it, whatever their segment says.

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 checks, 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.