bresrch Documentation

bresrch (Breach Research) is an identity investigation platform that helps security teams query, visualize, and analyze identity data across multiple providers. Get the data you need to investigate breaches, audit access, and respond to security incidents.

Temporal Database
bresrch uses a temporal database that automatically versions all data. Every change is tracked, enabling point-in-time queries and full audit trails for compliance.
Fast Graph Queries

Query identity relationships across providers with sub-50ms response times. Traverse user-group-app relationships in a single query.

Time Travel

Query data as it existed at any point in time. Essential for breach investigation and compliance audits.

Visual Exploration

Interactive Sankey diagrams, chord diagrams, and link graphs help you understand access patterns and identify anomalies.

Query Syntax

bresrch uses a graph query language inspired by SQL with arrow notation for traversing relationships. The query builder provides a visual interface, but you can also write queries directly.

Basic Structure

SELECT [fields or traversal] FROM entity_type:id WHERE conditions

Simple Field Selection

SELECT * FROM users

Returns all users with all fields.

SELECT * FROM users:'00u24m2v4jOPwc106697'

Returns a specific user by their external ID.

Filtering with WHERE

SELECT * FROM users WHERE status = 'ACTIVE'
SELECT * FROM users WHERE email LIKE '%@example.com' AND status = 'ACTIVE'

Graph Traversals

The arrow syntax allows you to traverse relationships between entities. This is the core power of bresrch - understanding who has access to what, and through which paths.

Arrow Notation

Syntax Direction Description
-> Outgoing Follow relationship from source to target
<- Incoming Follow relationship from target back to source

Traversal Patterns

User Traversals

Pattern Description Hops
->member_of->groups Groups a user belongs to 1
->assigned_to->apps Apps directly assigned to user 1
->member_of->groups->has_access->apps Apps accessible via group membership 2
->member_of->groups->governed_by->policies Policies governing user's groups 2

Example: Find All Apps a User Can Access

SELECT ->member_of->groups->has_access->apps FROM users:'00u24m2v4jOPwc106697'
User to Apps Access Flow
Visualizing how user access flows through groups to applications
john@example.com Engineering DevOps All Employees GitHub AWS Console Datadog Slack Google Workspace USER GROUPS APPS
User
Group
Application

Group Traversals

Pattern Description
<-member_of<-users Users who are members of this group
->has_access->apps Apps this group has access to
->governed_by->policies Policies that apply to this group

App Traversals

Pattern Description
<-assigned_to<-users Users directly assigned to this app
<-has_access<-groups Groups with access to this app
<-has_access<-groups<-member_of<-users All users with access through groups

Operators

Comparison Operators

Operator Description Example
= Equals status = 'ACTIVE'
!= Not equals status != 'SUSPENDED'
> Greater than created > '2024-01-01'
< Less than last_login < '2024-06-01'
>= Greater than or equal priority >= 1
<= Less than or equal priority <= 10

String Operators

Operator Description Example
LIKE Pattern matching (% wildcard) email LIKE '%@corp.com'
NOT LIKE Negative pattern matching name NOT LIKE '%test%'
IS NULL Field is empty last_login IS NULL
IS NOT NULL Field has value mfa_enabled IS NOT NULL

Logical Operators

Operator Description
AND Both conditions must be true
OR Either condition must be true

Entity Types

bresrch normalizes identity data from multiple providers into a common schema. This enables cross-provider queries and consistent field access.

Users

Identity accounts from Okta, Google Workspace, Azure AD. Fields: email, status, first_name, last_name, display_name, created, last_login

Groups

Security groups, distribution lists, teams. Fields: name, description, type, member_count, created

Apps

SAML/OIDC applications, OAuth clients. Fields: name, label, status, sign_on_mode, created

Policies

Authentication, authorization, and sign-on policies. Fields: name, status, type, created

Roles

Admin roles and permissions. Fields: name, description, role_type, is_admin, permissions

Devices

ChromeOS, mobile, and managed devices. Fields: name, device_type, model, os, status, compliance_state

Okta Entities

Available Entity Types

Entity Key Fields Common Queries
users email, status, first_name, last_name, login, created, last_login Find inactive users, MFA status
groups name, description, type (OKTA_GROUP, APP_GROUP, BUILT_IN) Group membership analysis
apps label, name, status, sign_on_mode (SAML, OIDC, etc.) App access audit
policies name, status, type (SIGN_ON, MFA, PASSWORD) Policy coverage analysis
policy_rules name, status, type, priority Rule precedence review

Okta Status Values

Status Description
ACTIVEUser can log in and access applications
SUSPENDEDUser temporarily blocked from access
STAGEDUser created but not yet activated
DEPROVISIONEDUser account deactivated
LOCKED_OUTUser locked due to failed login attempts
RECOVERYUser in password recovery flow

Okta Query Examples

Find users who haven't logged in for 90 days

SELECT * FROM users WHERE last_login < '2024-10-01' AND status = 'ACTIVE'

Find all apps accessible to a specific group

SELECT ->has_access->apps FROM groups:'00g123abc'

Find users with access to AWS Console

SELECT <-has_access<-groups<-member_of<-users FROM apps:'0oa789xyz'

Google Workspace Entities

Available Entity Types

Entity Key Fields Common Queries
users email, status, first_name, last_name, is_admin, mfa_enabled Admin audit, MFA compliance
user_aliases alias, primary_email Find shadow accounts
groups name, email, description, member_count Distribution list audit
roles name, role_type, is_system, permissions Admin role analysis
role_assignments user_id, role_id, scope Who has admin access
chromeos_devices device_id, serial, model, os_version, status Device compliance
mobile_devices device_id, model, type, os, compliance_state BYOD audit
domains domain_name, is_primary, is_verified Domain verification
org_units name, path, parent_id OU structure analysis

Google Workspace Query Examples

Find all admin users

SELECT * FROM users WHERE is_admin = 'true'

Find users without MFA enabled

SELECT * FROM users WHERE mfa_enabled = 'false' AND status = 'active'

Find non-compliant mobile devices

SELECT * FROM mobile_devices WHERE compliance_state != 'COMPLIANT'

Find group membership for a user

SELECT ->member_of->groups FROM users:'user@example.com'

Temporal Versioning

bresrch automatically versions all data using a temporal database. Every sync creates a new version, enabling powerful historical queries essential for breach investigation and compliance.

Why Versioning Matters
During a breach investigation, you need to answer: "What access did this user have 3 months ago when the compromise occurred?" Without temporal data, this question is impossible to answer.

How It Works

Every entity has automatic versioning with these fields:

Field Description
version Auto-incrementing version number
valid_from Timestamp when this version became active
valid_to Timestamp when this version was superseded (NULL if current)

Entity Version Timeline

2024-01-15 09:00:00
Version 1 - User created with status: STAGED
2024-01-15 14:30:00
Version 2 - Status changed to ACTIVE, email verified
2024-03-20 11:00:00
Version 3 - Added to "Engineering" group
2024-06-01 16:45:00
Version 4 - Granted admin role
2024-09-15 08:00:00
Version 5 (Current) - Status changed to SUSPENDED after security incident

Time Travel Queries

Query entity state and relationships as they existed at any point in time using the GraphQL API.

Entity History

query {
  entityHistory(input: {
    entityType: "users",
    entityId: "00u24m2v4jOPwc106697"
  }) {
    versions {
      version
      validFrom
      validTo
      data
      changes {
        field
        oldValue
        newValue
      }
    }
  }
}

Relationships At Point In Time

query {
  entityRelationshipsAtTime(input: {
    entityType: "users",
    entityId: "00u24m2v4jOPwc106697",
    at: "2024-03-15T00:00:00Z"
  }) {
    relationships {
      relationshipType
      targetType
      targetName
      validFrom
      validTo
    }
  }
}

Common Time Travel Use Cases

Breach Timeline

Reconstruct what access a compromised account had during the breach window.

Compliance Audit

Prove access controls at audit date, even if they've changed since.

Change Tracking

Find what changed between two dates for forensic analysis.

Investigation: Excessive Access

Investigating Over-Privileged Users
A user reports they can access sensitive apps they shouldn't have access to
1
Identify all apps the user can access
SELECT ->member_of->groups->has_access->apps FROM users:'john@example.com'
2
Find which groups grant access to the sensitive app
SELECT <-has_access<-groups FROM apps:'AWS Console'
3
Check the user's group memberships
SELECT ->member_of->groups FROM users:'john@example.com'
4
Use temporal query to find when access was granted

Check the entity history to see when the user was added to the group that grants AWS Console access.

Access Path Analysis
Visualizing how a user gained unexpected access to AWS Console
john@example.com Engineering DevOps-Admin (unexpected) All Employees GitHub AWS Console Slack USER GROUPS APPS
User
Expected Group
Unexpected Access Path

Investigation: Breach Response

Compromised Account Investigation
Security team detects a compromised Okta account and needs to assess blast radius
1
Identify all current access for the compromised user
SELECT ->member_of->groups->has_access->apps FROM users:'compromised@example.com'
2
Check historical access during breach window

Use time travel queries to see what access existed during the suspected compromise period (e.g., last 30 days).

3
Find other users in the same groups (potential lateral movement)
SELECT <-member_of<-users FROM groups:'Admin-Access'
4
Identify policies that apply to the user
SELECT ->member_of->groups->governed_by->policies FROM users:'compromised@example.com'
Blast Radius Analysis
Mapping all systems and data a compromised account could access
compromised@ Engineering Admin-Access DevOps Database-Team All-Employees AWS Console Okta Admin GitHub Kubernetes Datadog PostgreSQL Slack Google Drive USER GROUPS APPS (BLAST RADIUS)
Critical / Admin Access
Standard Group
Standard App

Investigation: Compliance Audit

SOC 2 Access Review
Quarterly audit requiring evidence of access controls for sensitive systems
1
List all users with access to production systems
SELECT <-has_access<-groups<-member_of<-users FROM apps:'Production-Database'
2
Find users without MFA across all providers
SELECT * FROM users WHERE mfa_enabled = 'false' AND status = 'active'
3
Identify inactive users with active access
SELECT * FROM users WHERE last_login < '2024-07-01' AND status = 'ACTIVE'
4
Generate point-in-time access report

Use temporal queries to show access state at the audit date, even if it has changed since.

Policy to User Coverage
Visualizing which authentication policies govern which user groups
MFA Required Password Policy No MFA (legacy) Administrators Engineering Finance Contractors Support 5 users 42 users 12 users 8 users (no MFA!) 15 users POLICIES GROUPS USERS
Policy
Group
Users
Compliance Gap