Application-Layer Behavioral Analytics Specification
Portable anomaly detection for the application layer
An open specification for behavioral anomaly detection in distributed systems. OpenALBA defines how to establish baselines from observability data, calculate anomaly scores (objective, mathematical), and compute risk scores (contextual, team-specific) so the same detection pipeline can serve security, SRE, and engineering teams.
The problem OpenALBA addresses
Behavioral anomaly detection is a solved problem. Organizations have been building baselines and detecting deviations for years using statistical methods and machine learning. The challenge is standardization:
- •Every vendor implements scoring differently, making detection logic non-portable
- •Anomaly scores conflate "how unusual" with "how risky," limiting reuse across teams
- •Security-focused tools ignore reliability and software quality use cases
- •Organizations rebuild the same baseline and scoring logic repeatedly
OpenALBA provides a vendor-neutral specification that separates objective anomaly detection from contextual risk interpretation. Implement it with any stack. Use it for security, reliability, or both.
How the specification structures detection
Observability Data
OTel traces, metrics, logs
Baselines
Per-entity behavioral profiles
Anomaly Score
Objective (0-100)
Risk Scores
Per-consumer (0-100)
Alerts
Routed by team
What OpenALBA is and isn't
OpenALBA is
- •A specification for implementing behavioral anomaly detection
- •Built on observability data you already collect (OpenTelemetry compatible)
- •Separates anomaly detection (math) from risk scoring (contextual)
- •Multi-consumer: same detection serves security, SRE, and engineering
- •Vendor-neutral, open source (Apache 2.0), implement with any stack
OpenALBA is not
- •A replacement for WAF, EDR, or perimeter security
- •Proprietary to any vendor or product
- •Limited to security use cases only
- •Dependent on a specific storage or infrastructure
- •A magic box (it requires configuration and tuning)
Beyond UEBA: application-layer analytics
Traditional User and Entity Behavior Analytics (UEBA) focuses on detecting insider threats and account compromise, which are security use cases only. OpenALBA operates at the application layer, profiling how services communicate, how data flows through your system, and how external dependencies behave. The same anomaly data serves security, reliability, and software quality use cases.
| Aspect | Traditional UEBA | OpenALBA |
|---|---|---|
| Data source | Dedicated agents, log collectors, separate data pipeline | OpenTelemetry traces and metrics you already collect |
| Consumers | Security team only | Security, SRE, and engineering with team-specific risk weights |
| Scoring | Single opaque risk score | Separate anomaly score (objective) and risk score (contextual) |
| Detection scope | User behavior for insider threat/account takeover | Users, services, endpoints, sessions, dependencies |
| Vendor lock-in | Proprietary to each vendor | Open specification, implement with any stack |
| Cold start | Weeks of data collection before useful | Peer group and population fallbacks from day one |
What the specification defines
OpenALBA doesn't prescribe tools or infrastructure. It defines how to structure your behavioral analytics so your detection logic is portable, your scoring is transparent, and your outputs serve multiple teams.
Entity profiling
Build behavioral baselines for users, services, endpoints, sessions, and dependencies using statistical and ML methods.
Objective anomaly scoring
Calculate how unusual something is using deviation, rarity, velocity, and persistence. Mathematical, not subjective.
Contextual risk scoring
Apply entity criticality, data sensitivity, and team-specific weights to turn anomalies into prioritized, actionable alerts.
Multi-domain insights
Security threats, service degradation, software defects, and business logic issues, all from the same detection pipeline.
Dual-score architecture
OpenALBA separates detection from interpretation through two distinct scores, enabling the same anomaly data to serve different operational teams with different priorities.
| Score | Purpose | Characteristics |
|---|---|---|
| Anomaly Score (0-100) | How unusual is this? | Objective, mathematical, deterministic |
| Risk Score (0-100) | How concerning is this? | Contextual, configurable, consumer-specific |
The same anomaly may have different risk implications for security, SRE, and engineering teams based on entity criticality, data sensitivity, and team-specific weights. A backend service connecting to a new IP might score 85 for anomaly but 95 for security risk (unknown destination) while only 15 for ops risk (if it's a known migration).
Standards alignment
OpenALBA aligns with established security and observability standards to ensure interoperability and compliance.
| Standard | Version | Integration |
|---|---|---|
| OpenTelemetry | 1.24 | Native semantic conventions |
| MITRE ATT&CK | v14.0 | Detection pattern mappings |
| NIST SP 800-53 | Rev. 5 | SI-4 control alignment |
| NIST CSF | 2.0 | DE.AE function coverage |
| ISO/IEC 27001 | 2022 | A.12.4 monitoring controls |
Reference implementation
The reference implementation uses open-source tools (ClickHouse, OpenTelemetry, Grafana) to demonstrate the specification. You are not required to use these tools. OpenALBA works with any stack that can collect and query observability data.
Coming soon
Reference implementations in Python, Go, and TypeScript are in development. Interested in contributing or early access? Get involved
Media & recognition
OpenALBA is a new specification. As adoption grows, we'll share conference talks, blog posts, and industry recognition here.
Conference talks
Interested in having OpenALBA presented at your event? Contact us
Blog posts & articles
Written about OpenALBA? We'd love to feature your content. Let us know
Industry recognition
Pursuing alignment with CNCF, OpenSSF, and other foundations.