Why CSIRT-Pro
CSIRT-Pro replaces a patchwork of disconnected security tools with a single cloud-native platform that unifies SIEM, SOAR, and UEBA capabilities.
The Problem with Traditional SIEMs
- Fragmented tooling. Separate products for log management, automation, and behavior analytics create integration overhead and blind spots.
- Unpredictable cost. Volume-based licensing penalizes growth and discourages comprehensive log collection.
- Slow queries. Row-oriented databases struggle at large scale.
- Complex deployment. On-premises clusters require dedicated infrastructure teams.
How CSIRT-Pro is Different
Unified Platform
SIEM, SOAR, UEBA, case management, and threat intelligence are delivered in one product, with no bolt-on modules and no additional licenses.
Schema-on-Read Storage
CSIRT-Pro stores raw logs in a messages column and extracts fields at query time, in JSON or regex mode.
This schema-on-read design is optimized for ingest speed, schema flexibility, and easy migration from Splunk.
Storage is highly compressed.
| Metric | Measured (≈110M rows, 2026-05) |
|---|---|
| Compression | ~9.3x |
| Point lookup (primary-key hit) | 0.2–1 s |
| Large GROUP-BY aggregation | ~23 s median (full-scans the messages column) |
An honest performance model
These numbers were measured in schema-on-read mode.
Point lookups are fast, but large aggregations full-scan the messages column and take tens of seconds on roughly 100M rows.
This is the trade-off for schema flexibility, fast ingest, and easy migration, so it should not be compared directly with typed-column SIEMs.
The fair comparison is schema-on-read against schema-on-read, that is, CSIRT-Pro against Splunk.1
PRQL as the Query Language
PRQL is pipelined and readable, and it is easier to learn than SPL or KQL. Analysts compose queries as a sequence of steps, which tends to reduce mistakes.
from `firewall_logs`
filter action == "DENY"
group {src_ip} (
aggregate {count = count this}
)
sort {-count}
take 10
Visual Playbook Automation
The visual flow editor offers many action node types, including threat hunting, search, case operations, transforms, variables, custom scripts, sub-playbook calls, pipeline operations, and UEBA actions, alongside Condition and Loop nodes. Custom script nodes run code in an isolated function-execution sandbox. Playbooks can be triggered by threat hunting, a schedule (cron), a webhook, or a case event.
AI-Assisted Operations
- AI parse generation. Paste a sample log and the generative AI proposes a regex and field names. The analyst reviews and applies the result, and field names are normalized to the ECS schema.
- Similar case search. Past cases are ranked by similarity of the case text.
- AI Investigate. A read-only, tool-using AI assistant searches and aggregates logs and cases from natural language, with streaming and progress display. Conversation history is kept in the browser (local storage), and the server itself is stateless.
None of these features take response actions on their own. The AI does not remediate, block traffic, or close cases automatically, and any SOAR write is gated by an approval workflow (request, then approve, then apply).
Multi-Tenancy with Controlled Cross-Org Sharing
Each organization is logically isolated through a dedicated user and dedicated views, and customers cannot reach the data store directly. Controlled cross-organization sharing supports MSSPs and holding companies.
Passwordless Authentication
Passkey and WebAuthn are supported through the identity provider (limited), alongside OAuth2 and OIDC.
Integrations Catalog
A catalog lets administrators enable or disable integration packages by category. Enabling an integration can assign default resources, such as default UEBA groups, with the exact resources depending on the package.
Feature Summary
| Feature | Description |
|---|---|
| Search | PRQL-based real-time log search with multiple visualization types |
| Case Management | Thread-based incident tracking, AI similar-case search, response recommendations |
| Playbook (SOAR) | Visual flow editor, script nodes, schedule/webhook/case/manual triggers, version control |
| Pipeline | Regex and JSON parsing, AI parse generation, configurable retention (TTL) |
| UEBA | Scheduled detection Playbook tasks, task groups, asset management, configurable intervals (detection logic lives in Playbooks) |
| Dashboards | Grid layout, PDF export with cover page, JSON import/export |
| Threat Intelligence | CVE search (NVD), IOC search, MITRE ATT&CK, KEV filtering |
| Chat | Integration ticket chat and the AI Investigate assistant |
| Integrations | Catalog that can provision dashboards, pipelines, playbooks, and UEBA groups |
| Authentication | OAuth2/OIDC via the identity provider, Passkey (WebAuthn/FIDO2), API keys |
| Multi-Tenancy | Organization-scoped logical isolation with controlled cross-org sharing |
| Audit Log | Searchable audit trail of user actions |
| Escalation Policies | Email, SMS, webhook, Slack, and Teams notification channels |
| API | REST API with Swagger/ReDoc documentation and a columnar binary response format |
Comparison with Legacy SIEMs
| Criteria | CSIRT-Pro | Splunk Enterprise | Elastic Security |
|---|---|---|---|
| Architecture | Cloud-native SaaS | On-prem / Cloud (heavy) | On-prem / Cloud |
| Log Storage | Columnar analytics store (schema-on-read) | Proprietary indexing | Inverted index |
| Query Language | PRQL (pipelined, readable) | SPL (proprietary) | KQL / Lucene |
| SOAR | Built-in visual Playbook | Separate product (SOAR) | Limited (detection rules) |
| UEBA | Built-in (Playbook-based scheduling) | Separate add-on (UBA) | Separate ML module |
| Case Management | Built-in with AI assistance | Separate (ITSI / Phantom) | Basic case management |
| Threat Intelligence | Built-in (CVE + IOC) | Add-on (Enterprise Security) | Partial (indicator matching) |
| Automation | Script nodes in visual playbooks | SPL + Phantom | Painless / limited |
| AI Assistance | Parse generation, similar cases, recommendations | Limited | Limited |
| Multi-Tenancy | Native logical isolation with cross-org sharing | Complex (search head clustering) | Spaces (limited isolation) |
| Auth | OAuth2/OIDC + Passkey | SAML/LDAP | SAML/OIDC |
| Pricing | Predictable | Volume-based (GB/day) | Node/resource-based |
| Deployment Time | Minutes | Weeks | Days to weeks |
Ideal Use Cases
- SOC and CSIRT teams seeking a single pane of glass across detection, investigation, and response.
- MSSPs that need multi-tenant isolation with controlled cross-org data sharing.
- Organizations migrating from Splunk or Elastic seeking lower TCO and simpler operations.
- Security teams adopting automation that want visual playbook building without proprietary scripting.
-
Because fields are extracted at query time rather than stored as typed columns, aggregations that scan the full log body are slower than on a typed columnar layout. The benefit is that any field becomes queryable without re-ingesting or redefining a schema. ↩