Monitoring, Threat Detection and Observability

SANKET's detection capabilities are deterministic and rule-based. This chapter separates the protections that are always active from the optional components, and is explicit that the platform contains no machine-learning detection.

22.1 Always-Active Protections

Table 40: Built-in detection and response

22.2 Optional Stream Processor

An optional stream processor, deployed as a separate service with its own database, correlates security events over time and raises alerts that appear in the administrator console in real time, naming end users by Sanket ID. Most customers combine the built-in protections above with correlation in their own SIEM.

22.3 What Is Not Claimed

SANKET's detection is deterministic and rule-based; no machine-learning detection is claimed.

For most high-trust customers the right model is to forward SANKET's audit stream to their own security operations platform and correlate it there with network, endpoint and identity telemetry.

22.4 Usage Analytics on the Installation

Usage analytics (active users, messages and calls per day, app versions and platforms) are first-party: they are aggregated by a processor that ships with every release and runs on the installation itself. Clients and the server add content-free, pseudonymous events to a capped stream inside the installation; the processor rolls them up into counters in the installation's own database, in day buckets in the organisation's time zone, which the console's Analytics pages read. Only counts are kept, never content. Nothing leaves the installation and no third-party analytics SDK or service is used. The processor is signed, verified and upgraded like every other service, runs with a read-only file system and no added privileges, and publishes no port.

Table 41: Control of usage analytics

Analytics never sits on a user's path. On the devices an event is only appended to a bounded in-memory queue, never awaited on a send, receive, decryption, call or rendering path, and sent in one batched request on an interval, deferred during calls and start-up; on the server, accepting events is a single capped append to the stream with no database write, and the processor runs in its own container under fixed resource limits, so it may fall behind but never slows the API. Written performance budgets, each enforced by a test, show that message sending, delivery and calls are unaffected with analytics on.

The processor's health is visible and alerted. Every Analytics page reports whether the processor is running, when the newest rollup was made and how many events are waiting, and shows a banner instead of empty charts when the processor is down or has stalled. A scheduled monitor raises an administrator alert when the backlog of unprocessed events, or the age of the oldest waiting event, passes a configurable threshold, and clears it when the processor recovers.

22.5 Observability Without Content Exposure

Administrators with the alerts-read permission see live operational monitors that read only counters, health probes and metadata:

Table 42: Operational monitors

The edge records, for each TLS connection, only the time, the protocol version, the negotiated key-exchange group and the server name, with no client address, path or user, so the share of connections that use hybrid post-quantum key exchange can be counted without identifying anyone (Chapter 39).

A health endpoint reports database and licence state, and container health checks cover the principal services. A metrics endpoint is available internally and is not exposed through the edge. Tracing can be exported to a customer-operated collector. None of these channels carries message content; a container-log viewer for administrators redacts passwords, tokens and credential patterns before display and records every viewing in the audit log.