Custom Detections

Your environment is unique, and your detections should be too. Ember's detection engineering builds custom detections that map directly to your infrastructure, workflows, and threat model, and adapts them at machine speed.

How It Works

1. Discovery: Your FDE and Ember review your environment, tooling, and existing coverage gaps
2. Design: Your FDE shapes detections around your specific threat scenarios and business logic
3. Build: Detection rules are written, tested, and deployed to your Zaun instance
4. Tune: Detections are refined over time to reduce noise and improve signal
5. Document: Every detection ships with a runbook covering investigation and response steps

What Makes Custom Detections Different

Unlike off-the-shelf rules, custom detections are:

• Environment-aware: built with knowledge of your infrastructure, naming conventions, and expected behavior
• Business-logic driven: they encode your organization's policies, not generic best practices
• Continuously updated: Ember ships new and improved detections as threats and your environment change
• Fully documented: every detection has a runbook explaining what fired, why it matters, and what to do

Example Use Cases

Insider Threat Detection

• Mass download detection: An employee downloads 500+ files from Google Drive or SharePoint in a single session, especially during their notice period. Ember builds detections against Google Workspace Admin Logs and Microsoft 365 Unified Audit Log with thresholds tuned to your organization's normal download volume.
• Off-hours access to sensitive systems: An engineer accesses AWS production databases via DataGrip or pgAdmin at 2 AM on a Saturday. Ember flags this based on your team's on-call schedule and normal access patterns, pulling from AWS CloudTrail and Okta login events.
• Privilege escalation in Okta: A user assigns themselves the Admin role in Okta or adds themselves to a privileged Google Workspace group. Ember maps your RBAC model and builds detections for any role change that crosses a privilege boundary.

Compliance Monitoring

• SOC 2 access review anomalies: Detections that flag when a user retains access to AWS, GCP, or GitHub after changing roles, based on your HR system (Workday, BambooHR, Rippling) reporting a title or department change.
• PCI-DSS cardholder data exposure: Custom detections for when files containing cardholder data patterns are shared externally via Google Drive, Slack, or OneDrive, using DLP signals from Microsoft Purview or Google Workspace DLP.
• HIPAA audit log gaps: Detections that flag when AWS CloudTrail or GCP Audit Logs are disabled or have gaps in coverage for accounts hosting PHI workloads.

Application-Specific Threats

• API abuse detection: Your product's REST API sees a single user making 10,000+ requests to the /export endpoint. Ember builds detections against your Datadog or CloudWatch API metrics, tuned to tell the difference between legitimate power users and data scraping.
• Custom SSO bypass: An attacker accesses your application directly, bypassing your Okta or Entra ID SSO flow. Ember detects direct authentication that skips the expected SAML/OIDC redirect.
• Webhook tampering: Someone modifies outgoing webhook configurations in Slack, GitHub, or PagerDuty to exfiltrate data to an external endpoint. Custom detections flag webhook URL changes to domains not on your approved list.

Cloud Infrastructure Threats

• Crypto-mining detection: An attacker spins up GPU instances in AWS or GCP using compromised credentials. Ember builds detections for unusual instance types (p3.xlarge, a2-highgpu) in regions your organization doesn't normally use.
• Backdoor IAM user creation: A compromised admin creates a new IAM user in AWS with AdministratorAccess and static access keys. Custom detections flag new IAM users created outside your standard provisioning process (Terraform, CloudFormation, or Pulumi).
• DNS exfiltration: An attacker uses DNS tunneling to exfiltrate data through long, encoded subdomains. Ember detects high-entropy DNS queries in CrowdStrike or Cloudflare Gateway telemetry that exceed normal query length.

Integrations That Power Custom Detections

Custom detections can be built on any data source Zaun ingests. Common sources include:

Delivery Cadence

Ember delivers detections continuously, not on a fixed release schedule:

• Day one: An initial detection set based on discovery findings
• Ongoing: New detections as emerging threats, environment changes, and coverage gaps appear
• On-demand: Rapid detection development in response to incidents or new threat intelligence

Requesting and Reviewing Detections

Detection development is transparent and collaborative. You work directly with your Forward Deployed Engineer (FDE), who scopes, builds, and tunes detections with full visibility for your team:

• Request detections: Submit specific detection ideas and your FDE scopes and builds them
• Review what ships: See every detection, its logic, and its runbook before and after it deploys
• Tune in the open: Adjust thresholds and exceptions with full visibility into what changes
• Incident response: Stand up new detections rapidly in response to active incidents

Next Steps

• Getting Started - Begin your onboarding
• Platform Overview - How Reagent and Ember fit together
• Integrations - Connect the data sources that power your detections