5. Risk score calculation

Status	Stable
Version	2.0.0
Last updated	2026-01-31
Authors	OpenALBA Working Group

5.1 Overview

The Risk Score transforms the objective Anomaly Score into a context-aware measure of concern. Unlike the Anomaly Score, the Risk Score incorporates:

Entity criticality (how important is this user/service?)
Data sensitivity (what data classifications are involved?)
Environment (production vs. staging vs. development)
Consumer-specific weights (security vs. ops vs. engineering)
Time decay (how long has this been going on?)
Suppression rules (known patterns, change windows)

5.2 Risk score formula

Risk Score Formulapython

RiskScore = min(100, AnomalyScore × EntityMult × SensitivityMult ×
            EnvironmentMult × ConsumerWeight × TimeDecay × (1 - Suppression))

5.3 Entity criticality multiplier

Services

Service Criticalityyaml

payment-*, checkout-*: 2.0  # Revenue-critical
auth-*, api-gateway: 1.8     # Security-critical
user-*, order-*: 1.5         # Important
internal-*, admin-*: 1.0     # Standard
reporting-*: 0.8             # Lower priority
*-staging: 0.5               # Non-production
*-dev: 0.3

Users

User Criticalityyaml

super_admin: 2.5
admin: 2.0
service_account: 1.8
developer: 1.3
user: 1.0
guest: 0.8

# Additional modifiers (multiplicative)
has_pci_access: 1.5
has_pii_access: 1.3
resignation_submitted: 2.0  # Insider threat risk
recently_onboarded: 1.2

max_multiplier: 5.0  # Cap total

Endpoints

Endpoint Criticalityyaml

/api/admin/*: 2.0
/api/*/export: 1.8
/api/*/bulk*: 1.5
/api/payment/*: 2.0
/health, /metrics: 0.3

5.4 Data sensitivity multiplier

Data Sensitivity Multipliersyaml

restricted: 3.0   # Encryption keys, credentials
confidential: 2.0 # PII, PHI, PCI
internal: 1.2     # Business data
public: 1.0       # Marketing, static assets

5.5 Environment multiplier

Environment Multipliersyaml

production: 1.5
staging: 0.8
development: 0.3
local: 0.1

5.6 Consumer-specific weights

Different teams have different concerns. The same anomaly may be high priority for security but low priority for ops.

Security team profile

Security Team Weightsyaml

# High concern
geographic_anomaly: 2.5
impossible_travel: 3.0
credential_stuffing: 2.5
privilege_escalation: 2.5
data_exfiltration: 3.0
new_external_connection: 2.0

# Moderate concern
access_pattern_change: 1.5
after_hours_activity: 1.3

# Low concern (ops handles)
error_rate_spike: 0.5
latency_increase: 0.3

SRE/Ops team profile

SRE/Ops Team Weightsyaml

# High concern
error_rate_spike: 2.5
latency_increase: 2.0
dependency_failure: 2.0
capacity_threshold: 2.0

# Moderate concern
geographic_anomaly: 1.0
new_external_connection: 1.2

# Low concern (security handles)
credential_stuffing: 0.5
privilege_escalation: 0.5

Engineering team profile

Engineering Team Weightsyaml

# High concern
new_exception_type: 2.0
error_rate_spike: 1.8
api_contract_violation: 2.0
response_anomaly: 1.5

# Moderate concern
latency_increase: 1.3

# Low concern
geographic_anomaly: 0.5

5.7 Time decay

Risk scores decay over time if no new anomalous activity occurs:

Time Decay Formulapython

RiskScore(t) = RiskScore(0) × e^(-λt)

Half-life = ln(2) / λ ≈ 0.693 / λ

Decay rates by anomaly type:
    error_rate_spike: λ=0.5, half-life=1.4 days (fast - transient)
    latency_increase: λ=0.4, half-life=1.7 days
    traffic_pattern: λ=0.2, half-life=3.5 days
    auth_failure_pattern: λ=0.15, half-life=4.6 days
    geographic_anomaly: λ=0.1, half-life=6.9 days
    privilege_escalation: λ=0.07, half-life=9.9 days
    data_exfiltration: λ=0.02, half-life=34.7 days (slow - serious)

Reset conditions:
    - Anomaly score increases (new activity)
    - New related anomaly detected
    - Analyst flags for review

5.8 Suppression mechanisms

Change window suppression

Change Window Suppressionyaml

- name: "Weekly deployment"
  schedule: "Tuesdays 2-4 PM ET"
  services: ["api-*", "web-*"]
  anomaly_types: [error_rate, latency, traffic_pattern]
  suppression_factor: 0.8  # Reduce by 80%

Known pattern suppression

Known Pattern Suppressionyaml

- name: "Monthly billing batch"
  conditions:
    service: billing-processor
    day_of_month: [1, 2]
    hour_range: [0, 6]
  anomaly_types: [data_access_volume, traffic_pattern]
  suppression_factor: 1.0  # Full suppression

- name: "Known crawlers"
  conditions:
    client.address_in: [googlebot_cidrs, bingbot_cidrs]
  anomaly_types: [api_abuse, volumetric]
  suppression_factor: 0.9

Suppression application

Suppression Applicationpython

final_suppression = max(all matching suppression factors)
RiskScore = BaseScore × (1 - suppression_factor)

Example:
    BaseScore = 75
    Change window: 0.8
    Known pattern: 0.5

    Applied = max(0.8, 0.5) = 0.8
    FinalScore = 75 × (1 - 0.8) = 15

5.9 Complete example

Complete Risk Score Examplepython

Scenario: payment-api (production) connects to unknown external IP

Inputs:
    AnomalyScore = 72
    Entity: payment-api → criticality = 2.0
    Sensitivity: confidential → multiplier = 2.0
    Environment: production → multiplier = 1.5
    Anomaly: new_external_connection
    Time: just detected → decay = 1.0
    Suppression: none → factor = 0

Security Risk:
    consumer_weight = 2.0 (high concern)

    Risk = 72 × 2.0 × 2.0 × 1.5 × 2.0 × 1.0 × (1-0)
         = 72 × 12.0
         = 864 → capped at 100

    Alert: CRITICAL

Ops Risk:
    consumer_weight = 1.2 (moderate concern)

    Risk = 72 × 2.0 × 2.0 × 1.5 × 1.2 × 1.0 × 1.0
         = 72 × 7.2
         = 518.4 → capped at 100

    Alert: CRITICAL (but uncapped value shows lower relative priority)

5.10 Conformance

Implementations:

SHOULD implement entity criticality multipliers
SHOULD implement at least one consumer-specific weight profile
MAY implement time decay and suppression mechanisms
MUST cap risk scores at 100

Note

Continue to Section 6: Signal Definitions for OpenTelemetry attribute mappings.