Configuration Integrity Monitoring

The SIEM watches its own configuration. Every save is sealed with a hash anchored in the tamper-evident audit trail. If the config is ever changed outside the editor — a direct S3 edit that bypasses the audited path — it is detected and raised as a high-severity threat, with a field-level diff of exactly what changed and whether it weakened your posture (a disabled detection, armed auto-remediation, a removed approval gate).

The "Config Tampering" threat

If you see a threat of this type, the SIEM configuration was changed outside the editor (a direct edit of the config object in S3, bypassing the audited path). It carries a field-level diff of what changed. Make configuration changes through the editor so they are audited; a direct edit is flagged by design.

One working copy, one Save

Edits across Detection Rules, Settings, Data Sources, and the report schedule accumulate together into a single working copy and no longer get lost when you switch panels. A header Save commits everything at once (with the conflict check), and Undo discards all unsaved edits and reloads the saved config. An "Unsaved changes" indicator shows whenever the working copy differs from what is saved.

In-progress configuration is periodically saved as a private, per-user draft (never applied to the live config). If your session expires or the tab closes mid-edit, the next sign-in offers to restore the draft. Under Settings → Configuration History, the current version's Diff shows a field-level, colour-coded comparison of your unsaved edits against the saved configuration before you Save.

The integrity seal is written consistently on save, including on cold start, so a well-formed configuration does not raise a spurious "configuration changed outside the editor" alert.