Overview
How datagab works
The few ideas that the whole platform is built on: one shared log format, signals that become cases, an AI analyst that proposes, and people who approve.
One shared format for every log
Every log that reaches datagab is turned into one shared format based on the open OCSF standard. A sign-in from Okta and a sign-in from Microsoft 365 look the same once they are stored.
Because of this, one search covers every source, one detection rule can watch every identity provider, and every dashboard and report reads the same fields. Every attribute of every log can be searched.
Signals, cases and incidents
Three words describe how a problem moves through datagab.
- Signal
- Raised when a detection rule matches. A signal says what looked wrong, where and when.
- Case
- Groups related signals and findings into one piece of work, with an owner, a priority and a timeline.
- Incident
- A confirmed problem that affects the business. Incidents carry tasks, owners and, where the law asks for it, reports.
Findings
Cloud Security and Code Security produce findings rather than signals: a storage bucket open to the internet, a library with a known vulnerability, a secret in code. Findings have an owner, a severity and, where possible, a ready fix.
Emma proposes, people approve
Emma, the AI analyst, investigates signals and findings, writes up what she found and suggests what to do. Anything that changes a system, such as disabling a user or changing a cloud setting, waits for a person to approve it.
Approvals can be given in the console, in Slack or in Microsoft Teams. Both the proposal and the approval are written to the audit trail.
Where your data lives
Logs are stored in a log store built for fast search and long retention. Everything people create, such as rules, signals, cases and workflows, is kept in a separate database. Files and archives are kept in object storage.
All AI used by datagab runs on private models inside secure enclaves. Your data is never used to train models.