1. Overview
| Status | Stable |
| Version | 2.0.0 |
| Last updated | 2026-01-31 |
| Authors | OpenALBA Working Group |
1.1 Abstract
This specification defines the OpenALBA (Application-Layer Behavioral Analytics) framework for detecting behavioral anomalies in distributed systems using observability data. Unlike perimeter security tools (WAF, bot detection) or endpoint tools (EDR), OpenALBA operates at the application layer where it can observe how users interact with applications, how services communicate, how data flows through systems, and how external dependencies behave.
OpenALBA answers the fundamental question: “Is this behavior different from what we normally see?”
1.2 Status of this document
This document specifies a stable version of the OpenALBA framework. Distribution of this document is unlimited.
Component maturity
OpenALBA components follow a maturity lifecycle: Draft (under design), Experimental (available for testing), Stable (production-ready, backward compatible), Deprecated (scheduled for removal).
| Component | Status | Since | Notes |
|---|---|---|---|
| Anomaly Score Calculation | Stable | v2.0 | Core scoring algorithm |
| Risk Score Calculation | Stable | v2.0 | Context-aware scoring |
| Statistical Baselines (Z-score, MAD, EWMA) | Stable | v2.0 | Foundation methods |
| ML Baselines (Isolation Forest) | Stable | v2.0 | Multivariate detection |
| ML Baselines (Autoencoder) | Experimental | v2.0 | Complex pattern learning |
| Cold Start Handling | Stable | v2.0 | Peer group fallbacks |
| Detection Patterns (15 patterns) | Stable | v2.0 | MITRE ATT&CK mapped |
| Alert Framework | Stable | v2.0 | Tier-based routing |
| Graph-based Entity Relationships | Draft | — | Planned for v2.1 |
| Federated Baseline Sharing | Draft | — | Under discussion |
1.3 Conformance requirements
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
Implementations that claim conformance to this specification:
- MUST implement the anomaly score calculation as defined in Section 4
- MUST implement at least one baseline methodology from Section 3
- SHOULD implement risk score calculation as defined in Section 5
- MAY implement additional detection patterns beyond those specified
1.4 Document conventions
- Code examples are provided in YAML and Python pseudocode
- Mathematical formulas use standard notation
- All time values are in UTC unless otherwise specified
- Score values are in the range [0, 100] unless otherwise specified
1.5 Dual-score architecture
OpenALBA separates detection from interpretation through two distinct scores:
| 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 implications for different teams. For example, a backend service suddenly calling an IP in a new geographic region may score 85 for anomaly (equally unusual in all contexts), but the security risk score would be 95 for a PCI data service while only 5 for a known ops migration.
1.6 Anomaly categories
OpenALBA detects anomalies across multiple operational domains:
- Security indicators: Account takeover, insider threat, API abuse, privilege escalation, lateral movement, data exfiltration
- Reliability/Operations indicators: Service degradation, dependency failures, capacity exhaustion, deployment regressions
- Software quality indicators: New exceptions, error patterns, response anomalies
- External dependency changes: Third-party migrations, CDN changes, certificate issues
- Business logic indicators: Funnel breakage, conversion anomalies
1.7 References
Normative references
- [RFC 2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
- [OpenTelemetry] OpenTelemetry Semantic Conventions, https://opentelemetry.io/docs/specs/semconv/
Informative references
- [MITRE ATT&CK] MITRE ATT&CK Framework, https://attack.mitre.org/
- [NIST SP 800-53] Security and Privacy Controls for Information Systems and Organizations
- [Chandola 2009] Chandola, V., Banerjee, A., & Kumar, V. (2009). “Anomaly Detection: A Survey.” ACM Computing Surveys, 41(3), 1-58.
1.8 Security practices
The OpenALBA project follows security best practices aligned with OpenSSF guidelines:
- Signed commits required for specification changes
- Security vulnerabilities reported via security@openalba.org
- Coordinated disclosure process with 90-day timeline
- Dependencies reviewed and pinned in reference implementations
OpenSSF Best Practices badge: In progress
Note
Continue to Section 2: Core Architecture for details on system components and entity models.