Structured Anomaly Detection Settings

The Structured Anomaly Detection tab tunes behavioral analytics for your Trino SQL engine. The feature learns each Trino user's normal pattern of structured-data access over a rolling window and flags deviations. Because anomalies are measured against each user's own history and against their peers, rather than fixed rules, it can catch insider misuse and credential abuse that signature rules miss.

The feature flags the following behaviors:

• Reading tables, schemas, or catalogs the user has never touched (scope expansion).
• A sudden spike in rows or bytes read (bulk export).
• A read-mostly analyst issuing INSERT, DELETE, or DROP (role drift).
• Bursts of failed queries (reconnaissance).
• Quiet tables suddenly read by many users or at off-hours (data-asset anomaly).

Detected anomalies appear in the Posture Analytics transitions feed as trino_* signals. The learned baselines are available in the Structured Behavioral Baselines view on the Data Security Posture page.

note

Changes on this tab are staged locally. Click Save Settings at the top of the Settings page to apply them. The tab has no save button of its own. The detection job reads the new settings at its next run, with no restart.

Master Toggle

Enabled turns the whole detector suite on or off. It is on by default. When it is off, the scheduled detection job does no scoring and raises no alarms.

Baseline and Scoring Controls

Setting	Range	Default	Description
Baseline window (days)	1–365	30	The rolling window used to learn normal behavior. This is the main setting. A longer window is more stable but slower to adapt to real role changes. A shorter window adapts faster but is noisier.
Z-score threshold (k)	—	3.0	A numeric metric is anomalous when its robust z-score is at least k. This is the main sensitivity control. A lower value finds more anomalies, and a higher value is quieter.
Min samples	—	8	Numeric detectors stay silent for a user until the user has at least this many baseline samples, so a new user is not flagged against an empty history. Until then, only the peer detector can flag the user.
Novelty min days	—	7	The number of active days of history a user's baseline needs before a first-seen access can fire.
Op-mix JSD threshold	0–1	0.30	The Jensen-Shannon divergence at which a change in the user's mix of read, insert, update, delete, and DDL operations counts as a shift. The divergence is a 0 to 1 measure of distance between two distributions. A lower value is more sensitive.
Rarity floor	0–1	0.01	The relative frequency below which a habitual but infrequent access counts as a rare access. The default means less than 1% of the user's accesses. A rare access differs from novelty, which is a first-ever access.
Detection interval (min)	—	30	How often the detection job runs. Each run rebuilds baselines over the baseline window and scores the trailing 24 hours. An anomaly usually appears within one interval of the activity.
Timezone (IANA)	—	UTC	The timezone used to group activity into working hours, after hours, and weekend. Baselines are kept for each of these zones because structured-data access varies strongly by time. Enter an IANA name, such as UTC or America/New_York.

Detectors

Each detector family has its own toggle. All are on by default. A disabled detector never produces transitions or raises alarms.

Detector	What it flags
Volume / magnitude	Robust z-score on bytes, rows, and queries. Catches bulk reads and exfiltration.
Scope novelty	First-ever access to a catalog, schema, or table. Catches lateral movement and scope expansion. Uses Novelty min days.
Rare access	A habitual but rare table access below the Rarity floor.
Op-mix shift	A change in the read, write, delete, and DDL mix beyond the Op-mix JSD threshold. Catches role drift and destructive activity.
Peer outlier	A comparison against the whole user population (median ± MAD). This is the only detector that can flag a user before their own baseline is mature.
Failed-query probing	A burst of failed or access-denied queries. Catches reconnaissance.
Table-side anomaly	A normally quiet table suddenly read by many, new, or off-hours users. It is evaluated on the data asset, independent of any one user, so it applies to allowlisted accounts too.

User Allowlist

The allowlist holds ETL and service accounts that legitimately touch everything and would otherwise produce constant findings.

• Add an account — type its Trino user name, for example etl.pipeline, and press Enter or click Add.
• Remove an account — click the trash icon on the account.

Allowlisted accounts are exempt from the user-side detectors: volume, novelty, rarity, op-mix, peer, and failed-query probing. Table-side detection still applies to their activity, so a quiet table they access heavily can still be flagged.

Tuning and Troubleshooting

Too many findings. Do any of the following:

• Raise Z-score threshold (k).
• Raise Min samples.
• Raise Op-mix JSD threshold toward 1 to make op-mix detection less sensitive.
• Add known ETL and service accounts to the allowlist.
• Turn off a noisy detector family.

No findings. New users stay silent until they pass the Min samples gate for numeric detectors and the Novelty min days gate for novelty detection. This is expected during initial learning. Confirm that Enabled is on and that Trino audit data is arriving. See Structured Data Audit (Trino).

Findings appear at the wrong times. Check Timezone. Work-zone grouping and the off-hours severity increase depend on it matching your operators' working timezone.

Severity, off-hours escalation, and which findings raise alarms are not configured here. Only HIGH and CRITICAL anomalies raise alarms. See Structured Behavioral Baselines for how scoring works.