SIEM — threat detection over your own ledger

A Wazuh manager decodes every event, runs it through a large built-in ruleset plus LedgerFlow-specific rules, and raises severity-tiered alerts; an OpenSearch indexer stores and searches them; the dashboard is the security console.

• Container & host security — runtime lifecycle / image / mount events, host posture checks and system inventory.
• Database security audit — LedgerFlow's tamper-evident audit trail (who, which role, which table, before/after) is streamed into detection, so credential / role changes, audit-log tampering, and deletions in the append-only ledger escalate — apart from routine writes.
• Web-attack detection — the edge proxies' access logs run through a mature web ruleset that flags SQL injection, XSS, vulnerability scanners, and brute-force / enumeration.
• File-integrity & vulnerability — the source-of-truth config (access-control SQL, audit triggers, approval workflow, proxy config) is watched for change with diffs; known CVEs are detected from a live feed. Data dirs and secrets are excluded.

Every event is decoded, evaluated against rules, escalated by severity, and mapped to security frameworks:

• MITRE ATT&CK — alerts carry technique ids (account manipulation, log tampering / defense evasion, data destruction).
• Regulatory compliance — alerts tagged for PCI-DSS, GDPR, HIPAA, NIST, so detections double as continuous compliance evidence.
• Severity-tiered — high-volume routine activity is classified but kept quiet; the security- relevant subset is escalated, keeping signal high and alert fatigue low.

The Wazuh dashboard is the primary security console — alert triage, rule/decoder management, MITRE ATT&CK, file-integrity, vulnerability detection, and the compliance modules.

The same Grafana that surfaces traces, metrics and logs also gets a read-only view of the security alert stream, so an operator sees "attacked?" next to "healthy?" in one pane — while the dedicated console stays the deep-dive tool.

Detection is only half the job — alerts are routed, reviewed and acted on:

• One alerting hub — security alerts and operational ("is it healthy?") alerts share a single notification layer, severity taxonomy and on-call flow, so a credential change, an audit-tampering attempt or a ledger deletion pages someone the same way a latency spike does. Channels (webhook / Slack / email) are configuration; nothing is hard-wired.
• Low-risk active response — automated containment (e.g. firewall-drop on a brute-forcing or scanning IP) is available but off by default and human-in-the-loop — nothing automated ever touches the ledger, accounts or balances.
• FinTech security dashboard — ledger-integrity, authentication failures, separation-of-duties breaches, mass-export attempts and malware in one pane, alongside the platform health dashboards.
• Scheduled compliance reports — periodic, self-contained per-framework reports generated inside the deployment.
• Per-host agents & PAN tripwire — optional agents extend file-integrity and CVE scanning to the database and service hosts; a PAN tripwire alerts the instant a card-shaped value appears where only tokens are expected (it flags the match and location, never the digits).

What the monitoring actually gives you, by framework — coverage, not a control-by-control audit:

• PCI-DSS (reduced scope) — LedgerFlow stores no cardholder PAN, only tokenized account references, so a deployment sits outside the cardholder-data environment (CDE) — SAQ A / A-EP territory rather than a full Report on Compliance. The SIEM provides Requirement-10 audit evidence and runs the PAN tripwire boundary control.
• SOC 2 / ISO 27001 — the day-to-day fit: continuous logging & monitoring, change detection (file-integrity + configuration), and incident detection & response (alerting, runbooks, retained evidence) map directly onto the security, availability and change-management criteria.
• GDPR / POPIA — access to and changes against personal/customer data are audited and alertable; security data is self-hosted and retained on a tunable, policy-driven schedule.
• MITRE ATT&CK — detections carry technique identifiers (account manipulation, defense evasion / log tampering, data destruction), so coverage lines up with a recognized adversary model.
• Tested & retained — each source class and custom rule has a documented test, evidence is kept on a tunable 12-month window (hot in-indexer + S3 archive), and triage runbooks ship with the template.

• Self-hosted — all security data stays inside your deployment; nothing ships to a third party.
• Tunable retention — how long security / compliance data is kept is a configuration value, with a longer default than operational telemetry; old data ages out automatically by policy.
• Portable & standards-based — OpenSearch storage and a documented ruleset, extensible with your own decoders, rules, and remote agents for hosts beyond the core stack.

LedgerFlow couples an immutable double-entry ledger and a tamper-evident audit trail with rule-based detection over that same trail. So a credential change, an attempt to alter the audit log, a deletion against the ledger, or a scanner probing the API is detected and classified, not just logged — making the platform's security posture and compliance evidence demonstrable from first principles.