SOCsimple sits over the rules, decoders and lists your Wazuh managers run. Connect a manager, and it reads everything, shows you what needs a person, and gives your team one safe, recorded path to change it. Wazuh stays the engine.
Someone raised this rule's alert level from 5 → 10, directly on the manager. What it detects is unchanged. Two local rules depend on it. Caught on the 09:12 sync.
The XML that decides what becomes an alert is not, on its own, a versioned or reviewable change system — it’s files on a manager, edited in place. The manager is the deploy target, not the source of truth.
This is the core workflow, in the order your team actually experiences it — shown with one environment's real shape.
Name the environment, point at the manager's API, Test and save. A failed probe stores nothing. A successful one stores exactly what was verified — version, capabilities — and starts the first sync on its own. Read-only from the first second.
The Manager tells SOCsimple what runs. The Indexer shows what it produces. Connect the Indexer when you want noise analysis, firing patterns and measured change outcomes.
The first sync reads every rule, decoder, CDB list and file, the way Wazuh loads them. Your existing local content is adopted as the baseline on the spot: no weeks of defining "correct" before drift detection means anything. Built-in content is indexed, never claimed.
Then it keeps going: scheduled synchronization, connection health that wears its age, and Sync now whenever you need it.
Not a stats page. Findings computed from your synced content — two definitions fighting over one identity, broken dependencies, rules that never load — plus anything drifted and, with an indexer connected, which rules are shouting. Ranked by what it affects, and separated from Wazuh structure that's probably deliberate.
Observed. Why it matters. Next step. A duplicate-ID card says which definition Wazuh actually keeps, what differs, and who depends on it — then lets you decide right there: keep this one, and renumber, remove or comment out the other. The decision becomes a staged draft, opened on the diff.
Underneath is a rule SOCsimple holds everywhere: one rule identity, one intended definition, one history — through edits, renames, moves between files, and redeploys. A collision becomes a decision instead of a winner silently chosen by load order, and new content is admitted with a safe identity before anything ships.
Edit a rule, a decoder or a CDB list, tune a loud built-in into a local suppression, or edit a whole file with a side-by-side diff. Or start from evidence: paste a real log into the Lab, see what matches, and turn the result into a draft — even a new decoder, seeded from what your sample actually contains.
Saving validates the change right then and marks the target Staged. Nothing touches the manager. A colleague can continue the draft; it records its author and its last editor separately.
Before deploy, you make one choice: what should the deploy prove? The recommended answer is a sample log that must fire — before and after the reload.
An operator gives the reason and presses Deploy. For a sample-proven deploy, SOCsimple takes a fresh snapshot, splices in only what you changed, runs the manager's own check, fires your sample against the staged content, reloads without a restart, fires it again live, verifies the bytes, and commits. If any step fails, the manager is restored byte-for-byte and the failure is recorded honestly.
Then it's in Activity — who, why, how it was proved — and in the append-only, hash-chained audit trail underneath.
With an indexer connected, the change keeps reporting back. The impact you predicted was frozen into the draft; Insights measures what really happened and says so plainly — a confirmed drop, or honestly not confirmed yet.
That’s what the loop buys. Tuning stops being a guess you revisit and becomes a decision you close — and the same clarity runs through the rest: what changed, whether it was safe, whether it worked. The hours that went into that archaeology go back into running Wazuh, not excavating it.
Live matches intent.
Someone worked on the manager directly — allowed, and noticed. Surfaced calmly, with the diff.
A draft is open, touching nothing.
Present, with no recorded intent.
The point is not to hide how Wazuh works — it's to stop making every analyst re-derive it. The surface stays in operator words: Draft, Deploy, Prove this change, Restore, Adopt. The complexity lives one layer down, where it is enforced rather than remembered.
Every path that can touch the manager — an edit, a restore, a removal, a tuning rule — runs the same spine. There is no "just this once".
Organised by the question you walked in with — not by data type, and not as a feature catalogue.
Local and built-in rules, decoders and CDB lists, file by file. Pick anything: what it fires on, what it alerts at, what depends on it, whether it passes its checks. For local content, the XML is the bytes on the manager — never rewritten; built-ins are shown from the stock ruleset matching your Wazuh version.
Findings, drift, open drafts and failed deploys, folded into decisions. Needs review is separated from context; red is reserved for genuine failure. Dismissals need a written reason and stay exact.
Find the loud rule and see which signature or field is driving it. The tuning builder stages the change, records what you expect it to reduce, ships it through the same gated deploy — then measures what actually happened.
New rules get a safe identity and a destination file. Decoders can be added, renamed as a declared move, or removed with dependents listed first. CDB lists are edited and deployed through the same recorded change workflow. One open working copy per file — and for rules and decoders, the Lab can turn a real log into a starting point.
A day-grouped timeline of syncs, manager changes, drafts, deploys, rollbacks and decisions — with actor and reason where applicable. Beneath it, an append-only, hash-chained audit log: alter one record and the chain breaks visibly.
Each Wazuh deployment is an environment with its own content, drift, drafts and history. Two or more clients get a portfolio: connection health, sync age and open work per environment — the "which of my 30 needs me today" screen. A per-client Library holds reusable detection content, deployed into any of that client's environments through the same gate.
Collaboration is the intended mode. Silent editing was the bug. Every consequential action has a role that may take it, a scope it is confined to, and a record it leaves.
You want to know the live ruleset matches what the team agreed on, ship rule changes without a nervous SSH session, and answer "who bumped this to level 10?" without a meeting.
"Was that on purpose?"
One workspace, a portfolio of what needs attention — and the target client and environment stay explicit, with scope confirmed before a manager write. A client's failed read shows as unknown — never as a smaller, healthier fleet.
"Which of ours needs someone today?"
Who, what, when, why, and whether it worked — a tamper-evident record instead of a folder of tickets and shell history.
Wazuh 4.x over the standard manager API for read-only visibility; deployments use the ruleset hot-reload introduced in Wazuh 4.13, so the deployment path supports 4.13 and later. Not built yet, and not pretended: stored test results, promote-to-N-environments, notifications. Not a SIEM: SOCsimple doesn't store your alerts, own retention or run response — Wazuh does detection; SOCsimple manages the content it runs.
Not for its core job. Sync — reading rules, decoders, CDB lists and files — is read-only, and deployments are off for every environment until an admin enables them, an audited switch. When on, writes happen only through the deploy channel: operator role, a written reason, the full test-and-rollback pipeline. You provision the API credentials, so the access level is in your hands.
Yes — and that’s a designed-for mode, not a workaround. SOCsimple doesn’t replace the Wazuh dashboard, fence off SSH, or move your content into a proprietary store: your rules, decoders and lists stay in Wazuh’s own files, on your manager. Change something directly and the next sync surfaces it calmly as Drifted, with the diff — adopt it as the new intent, or restore your version through the gate. And if you ever stop using SOCsimple, your manager is exactly as the last deploy left it.
This is the scenario the write path is built around. On a sample-proven deploy, a change that fails its staged log test never triggers a reload — the running ruleset is untouched. If a later step fails, SOCsimple restores its pre-write snapshot of the target file and records exactly what happened. The gated deployment path is lab-verified against live Wazuh managers, and one lock per environment means two deploys can’t race the same manager.
SOCsimple works with Wazuh 4.x over the standard manager API, with nothing installed on the manager host. Deployments use the ruleset hot-reload capability introduced in Wazuh 4.13, so the deployment path supports Wazuh 4.13 and later — lab-verified against live managers, and every manager’s version and capabilities are checked at connect time before deploys are allowed. Support for future major versions will be listed when it is ready and verified.
Each client is its own organization — the hard isolation boundary — and access is granted per environment, on a role ladder. Tenant-scoped data paths are constrained to the organization boundary and covered by cross-tenant isolation tests. The scope path is on screen at all times, and every deploy confirms it before writing.
No. Your detection content is not pooled into a shared SOCsimple catalog or used for model training. Content is shared across your own environments only when you deliberately promote or upload it to your organization’s Library and deploy it from there.
Read-only from the first sync. Your existing content becomes the baseline automatically. Turn on deploys when you're ready — not before.
Private beta. Access is by invitation, and Request access is how you ask for one — every request is reviewed by hand.