Posture Analytics - Security Transitions

Posture Analytics provides change-driven threat detection. Where the Data Security Posture topology shows what your storage looks like now, this page shows what changed and whether the change is a threat.

The platform keeps a history for every scan: PII classifications, language-coherence (LC) integrity scores, pod, PVC, and bucket inventory snapshots, and audit throughput. The latest value alone, such as "this file has PII count 12, LC 0.82", hides the security signal. The signal is usually in the transition from one state to another. Examples include:

• A file that changes from clean to PII, which means sensitive data was written where it should not be.
• A file that changes from coherent to gibberish. A sharp LC drop with an entropy spike and a changed content hash is the pattern of ransomware encrypting in place, corruption, or steganographic exfiltration.
• An ephemeral pod that ran for minutes and read a sensitive volume.
• A throughput spike at 2 a.m. on a Sunday against a quiet weekend baseline, which can indicate exfiltration staging.

The page shows these transitions as a live feed, scores them, and lets you triage them.

Transitions feed

The transitions feed lists detected changes, newest first. Each row describes one transition rather than one raw value. For example:

• PII 0 → 12 (new: SSN) — a file that was clean now has 12 PII entities, including a new entity type (SSN).
• LC 0.82 → 0.21 ⚠ gibberish — language coherence collapsed because the file's bytes changed. This is the main ransomware and integrity signal.
• ephemeral pod read 4.1 GB from aisec-pii-test-pvc — a short-lived pod accessed sensitive storage.

Each row contains the following fields.

Field	Description
Signal	The detector that fired. See Signals.
Entity	The file, pod, PVC, or bucket where the transition was observed, with its namespace.
From → To	The state before and after, for example clean → pii, 0.82 → 0.21, or absent → present.
Severity	INFO, LOW, MEDIUM, HIGH, or CRITICAL.
Confidence	A value from 0 to 1. A single signal is noisy and has lower confidence. Confidence rises when two or more signals occur on the same entity in the same time window.
Evidence	The rows or correlated child transitions that contributed, and a sparkline of the metric's recent trend for the file.

Signals

Signal	Description
pii	A change in PII classification.
lc	A sharp content-integrity drop. See LC and LC drift.
lc_drift	A slow content-integrity drift. See LC and LC drift.
ephemeral	A short-lived pod that accessed sensitive storage.
access	A change in access to an entity.
throughput	A throughput spike against the work-zone baseline. See Throughput anomalies.
correlated	Two or more signals that occur together on the same entity.
data_security_event	A single summary of failed audit events from the last 24 hours. See Data Security Event.
Trino (structured)	A filter group for all Trino SQL behavioral anomalies. See Trino (structured) filter group.

LC and LC drift

• lc — a sharp content-integrity drop. In a single scan, a file's bytes changed and its coherence collapsed. This is the main ransomware signal.
• lc_drift (shown as LC Drift) — a slow drift. The file's recent-weighted coherence and entropy gradually move into the concerning range through many small changes that never trigger the sharp detector. This is a low-severity early warning. It is never higher than MEDIUM and does not raise an alarm by itself. Treat it as a prompt to watch the file.

Trino (structured) filter group

Trino (structured) is a filter group, not a single detector. Selecting it limits the feed to all Structured Anomaly Detection signals so you can see every Trino SQL behavioral anomaly together. These signals are:

• trino_volume
• trino_write_surge
• trino_destruction
• trino_novel_access
• trino_rare_access
• trino_opmix_shift
• trino_peer_outlier
• trino_failed_probe
• trino_table_anomaly

Each card still shows its specific trino_<signal> label. For the learned baselines behind these signals, see Structured Behavioral Baselines.

Data Security Event

data_security_event is a single summary card that covers every failed audit event in the last 24 hours across PowerScale (Dell OneFS) file storage and ObjectScale (Dell ECS) object storage. There is one card, not one row per failure.

• Collapsed view — a line such as "N failed audit events across E workloads, last 24h".
• Expanded view — a tree of cluster, pod, PVC or bucket, and error code with its count. It shows which pods are hitting permission errors, credential failures, or probing patterns, and on which volume or bucket.
• Included entities — only PVCs and buckets that are mapped to a pod. Unmapped volumes are excluded.
• Error codes — the raw audit failure reason, for example failure(0xC0000022) or failure(403).
• Severity — audit failures are common, so severity is capped at MEDIUM and the card never raises an alarm by itself. Treat it as a signal to investigate.
• Refresh — the card updates about every 30 minutes with the latest 24-hour picture. It disappears when failures stop, so an empty feed means there are no recent failures in the fleet.

Read a transition

1. Check severity, then confidence. A CRITICAL row with high confidence, such as a correlated signal, needs action. A single LOW or INFO transition is usually informational and may be a statistical fluctuation.
2. Check the direction. clean → pii and coherent → gibberish are degradations. The feed shows changes so you can see degradations without reading absolute scores.
3. Open the row for evidence. The row expands to show before and after details and the metric sparkline. For a correlated transition, it also shows the child transitions that contributed. For example, an ephemeral pod, an lc gibberish change on its PVC, and an off-hours throughput spike can combine into one high-confidence alert.
4. Check the entity. A transition links to the entity in the topology and to File Activity, so you can see what else the pod, PVC, or bucket did around the same time.

Severity and correlation

Single signals are treated as low-confidence because one statistical outlier is rarely an incident. HIGH and CRITICAL severity requires two or more signals on the same entity within a sliding time window. For example, an ephemeral pod, an LC gibberish change, and an audit read burst can occur together. This keeps the feed actionable. A row marked correlated indicates that separate signals are probably one event.

Baselines need history. On a new deployment, bands are widened and HIGH severity is suppressed until enough samples accumulate. You see INFO and LOW transitions first, and severity sharpens as the baseline matures.

Acknowledge and suppress

Statistical detection produces some false positives, so you can triage every transition.

• Acknowledge — marks the transition as reviewed. Use it after you investigate a row and decide what to do. The transition still contributes to history, and the action records that a person has seen it.
• Suppress — marks the transition as a known false positive. Use it for expected behavior in your environment, such as a routine nightly batch job that moves large volumes off-hours. Suppressed transitions are kept for audit, but they leave the active triage view and no longer count toward the posture rollup.

These are operator controls. They change how a transition is shown and weighted, not the underlying detection, and they do not delete the record.

Throughput anomalies

The throughput section below the feed uses the audit stream's byte counters to detect exfiltration and ransomware. It has an anomaly table that lists what to act on, and a set of graphs per storage device that gives the overall picture. There are no per-PVC or per-bucket graphs. The table identifies the specific entities.

Work-zone baselines

Throughput is scored against a work-zone baseline, not a single global average. Each hour is compared with its own time-of-day band.

Zone	Hours
Working hours	09:00–17:00, Monday to Friday
After hours	Outside 09:00–17:00, Monday to Friday
Weekends	All day, Saturday and Sunday

Zones use the cluster's local timezone. A value is anomalous when it exceeds the upper limit of its zone's band, which is the mean plus three standard deviations.

• A large read or get spike on a weekend, far above that zone's quiet baseline, is the pattern of data exfiltration.
• A large off-hours write or put spike is the pattern of ransomware staging.

A single global baseline would hide a quiet-weekend spike under the busy weekday average and flag normal weekday activity as anomalous. Work zones avoid both problems.

Anomaly table

The table lists the PVCs and buckets whose throughput crossed their work-zone band in the last 30 days. This is the same window as the device graphs, so the table names the entities behind the crossings you see in the graphs.

• Rows are ranked by severity, and each row lists the pods that use the PVC or bucket.
• Use the Min severity filter to focus on what meets your threshold, for example HIGH and above.
• Each row shows the zone and direction, the peak rate in the window compared with the band, the z-score (standard deviations above normal), the number of hourly buckets that crossed the band, and when it was last seen.
• Sustained current spikes also appear as throughput rows in the transitions feed. They raise an alarm when severity is high.
• An empty table means every monitored PVC and bucket stayed within its bands during the window.

Device graphs

Each storage device (PowerScale cluster or ObjectScale device) has one graph. It shows the device's total bytes per second over the last 30 days as a line, over its work-zone baseline band as a dashed line. Red dots mark where the device as a whole exceeded its expected band.

Use the graphs to check whether anything is unusual across a device. Then use the anomaly table to find the PVC, bucket, and pods responsible.

A new entity or zone with too few samples is not scored until enough buckets accumulate. This avoids false positives at startup.

Triage

Acknowledging or suppressing a transition is a triage action on the feed.

Tips

• The lc gibberish signal, a sharp coherence drop with an entropy spike and a changed content hash, is the strongest single ransomware indicator. Treat a CRITICAL lc row, or any correlated row that includes an lc change, as a priority.
• A throughput transition is meaningful relative to its own work-zone baseline. A large read at 2 p.m. on a Tuesday is normal, but at 2 a.m. on a Sunday it is anomalous. The feed already scores against the matching zone, so rely on the severity rather than the raw byte count.
• Use Suppress sparingly. Over-suppressing reduces the value of the rollup. Use Acknowledge for "seen, benign this time", and use Suppress only for recurring expected behavior.

Common workflows

Triage the day's transitions

1. Open Posture Analytics and read the feed from the top, newest first.
2. Filter to HIGH and CRITICAL to focus on the most important rows.
3. Open each high-severity row, read its evidence and sparkline, and follow the entity link to the topology or File Activity to confirm.
4. Acknowledge the rows you have reviewed. Suppress any that are confirmed expected behavior.

Investigate a suspected ransomware event

1. Filter the feed to the lc signal or to correlated.
2. Look for coherent → gibberish transitions, which are a sharp LC drop with a content-hash change.
3. Open the row. If it is correlated, note the child transitions that were linked, such as an ephemeral pod, a read burst, or off-hours throughput.
4. Follow the links to the affected PVC or pod and to File Activity to determine the scope, then act on the raised alarm.