Signum is a security operations platform. Alarms from your SIEM, EDR, firewalls and mail security land in one place, each customer or business unit stays in its own tenant, and your analysts take every case from triage to a closed incident and a monthly report.
Signum works the same whether you defend your own company or dozens of customers. The only difference is how many tenants you create.
Your analysts work in a single queue while every customer's data, users and integrations stay separate.
Stop switching between the consoles of your security tools. Work every alarm, incident and response from one place.
Screenshots of Signum running with sample data.
Risk score, alarm and incident counts, response times and top alarm sources for the period you choose, from the last 24 hours to all time.
Filter by status, severity, source, category, host, IP or user, and sort the way you work. Charts show severity, status, source and category at a glance.
Details, custom fields, metadata and tags from the source, with the actions next to them: change status, create an incident, add a note, assign, or merge into a unified alarm.
An analysis with threat level, confidence, indicators, affected assets and recommended actions, plus a timeline of everything that happened to the alarm.
Pick a tenant and a period and generate a branded PDF with alarm and incident statistics and MTTA/MTTR.
One workflow for the whole SOC lifecycle, designed for teams that look after several organizations at the same time.
Alarms arrive in a common format: severities are mapped from whatever the source sends, duplicates are dropped by alarm id, and unified alarms fold a storm of related alerts into one item you can act on.
Promote an alarm to an incident and its whole history comes with it. Optional AI enrichment suggests a threat level and pulls out indicators; playbooks written in Python carry out the response.
Dashboards that show what is really open, a full audit trail, and per-tenant PDF reports (MTTA and MTTR, top sources, incident timelines) ready for the monthly review.
Every alarm follows the same path, and every step is recorded against the tenant it belongs to.
Sources push alarms through the REST API or webhooks with a tenant-scoped key. Severities are normalized and repeats are dropped.
Related alerts are folded into a unified alarm, so a hundred firewall events become one line in the queue.
Analysts assign, comment and look up IP and domain reputation without leaving the alarm.
Escalate to an incident, ask for an AI analysis if useful, and run a playbook to contain the problem.
The closing status is pushed back to the source platform, and the month ends with a PDF report per tenant.
The day-to-day tools of an operations team, in a single self-hosted platform.
Group related alerts into one entity with shared status, notes and timeline: triage hundreds as one.
Status workflow, assignment, merge & promote, optimistic concurrency. No lost updates between analysts.
AI-powered analysis on alarms and incidents: threat level, IOC extraction, similar incidents, next actions.
Tenant-authored Python automations run in ephemeral, network-restricted containers: power without risk.
Close an incident and Signum pushes the status back to the originating platform, tickets included.
Automatic aggregate-report collection straight from your report mailboxes, SPF/DKIM analytics per tenant.
TLS expiry monitoring and firewall-ready allow/block lists served as plain-text feeds your appliances pull.
One-click IP/domain reputation through your configured providers, cached and rate-limit aware.
Tenant separation is not a filter added on top of the UI. It is enforced at the query layer on every read and every write, and it fails closed: if the tenant is unknown, nothing is returned.
On any alarm, unified group or incident an analyst can request an analysis. Signum sends the case context to the AI integration you configured and stores the structured answer next to the case. Nothing runs automatically and nothing is closed for you.
A security tool sits in a privileged position, so it has to be the hardest thing on the network to abuse. These behaviors are covered by an automated test suite.
Signum is self-hosted. Alarms, incidents, reports and credentials stay in your infrastructure, and the only outbound connections are the ones you configure yourself.
Something missing? Write to [email protected] and we will answer directly.
Create one tenant per customer. Each tenant has its own alarms, users, integrations, playbooks and reports, and your analysts are granted only the tenants they cover. One person can work across all of them from a single queue.
Yes, if you want that. Give customer staff a read-only viewer role or a tenant admin role, and they see only their own organization. Single sign-on can be set up per tenant.
Yes. Run one tenant and you get the same queue, incidents, playbooks and reports. If you later add subsidiaries or business units, they become tenants of their own.
No. Those tools keep detecting. Signum receives what they raise and gives your analysts one place to triage, escalate and report.
Yes. Signum is deployed in your own infrastructure so that alarm data and credentials never leave your control. Get in touch to talk through sizing and requirements for your environment.
No. Enrichment is optional, runs only when an analyst asks for it, and uses the AI integration you configure. Without one, the rest of the platform works exactly the same.
Every query is scoped to the tenant on both reads and writes, and requests without a resolved tenant return nothing. API keys are bound to a single organization, and analysts only see the tenants they were granted.
Playbooks are Python scripts written per tenant. Each run happens in a short-lived, non-root container with a read-only filesystem and a restricted network, so a faulty script cannot reach the rest of your systems.
Any OpenID Connect identity provider, configured per tenant. Tokens are signature-verified and users can be provisioned automatically on first sign-in.
Request a demo. We walk through Signum with your kind of sources and tenant layout, and agree the next steps from there.
A demo is a working session, not a slide deck: we look at your sources, your tenant structure and the playbooks you would want first.