Signal Taxonomy & Architecture

Overview

Humifortis uses a unified signal naming convention to provide clarity on how evidence flows through the risk engine. All signals are named using a consistent prefix system that indicates their layer and controllability level.

1. Naming Convention

AUTH_ — Controllable Feature Signals

Signals that are:

✅ Feature-computed (derived from FeatureSet state, device baseline, context)
✅ Visible to operators (exposed in UI dashboards)
✅ Playbook-addressable (operators write explicit rules targeting them)
✅ First-class risk layer (direct impact on risk score)

Examples:

AUTH_BRUTE_FORCE — multiple failed logins in short time
AUTH_KNOWN_BAD_ACTOR — entity matches threat intelligence
AUTH_NEW_DEVICE — device not seen in last 30 days
AUTH_ANOMALOUS_HOURS — login outside user's typical hours
AUTH_DEVICE_COUNTRY_MISMATCH — device country differs from login country
AUTH_ANONYMOUS_NETWORK — VPN/Tor/proxy detected
AUTH_OFF_HOURS_ADMIN — privileged action outside business hours
AUTH_IMPOSSIBLE_TRAVEL — geographic impossible travel

Usage in Playbooks:

rules:
  - priority: 90
    name: impossible_travel_mfa
    derived_signals:
      - AUTH_IMPOSSIBLE_TRAVEL
    actions:
      - CHALLENGE_MFA
      - NOTIFY_SOC

FEAT_ — Internal Feature Detectors

Signals that are:

✅ Feature-computed (low-level technical detectors)
❌ NOT directly visible to operators (aggregated into AUTH_ signals)
❌ NOT playbook-addressable
✅ Support signals (used for noise filtering, baseline updates)

Examples:

FEAT_BOT_USER_AGENT — suspicious automation signatures
FEAT_PRIVILEGED_OFF_HOURS — low-level privilege baseline anomaly
FEAT_SESSION_ANOMALY — session duration or concurrency anomaly
FEAT_IDP_SWITCH — identity provider changed between events
FEAT_ANOMALOUS_HOUR — baseline hour deviation
FEAT_NO_MFA_AMPLIFIER — MFA not used in high-risk context

These are aggregated or filtered before reaching the playbook layer.

2. Signal Flow Architecture

┌──────────────────────────────────────────────────┐
│                 Playbook Engine                  │
│         (AUTH_ signals only)                    │
└──────────────────────┬───────────────────────────┘
                       │
┌──────────────────────▼───────────────────────────┐
│            Risk Calculation Layer                │
│        (final risk score: 0–100)                │
└──────────────────────┬───────────────────────────┘
                       │ aggregates
             ┌─────────┴──────────┐
             ▼                    ▼
        AUTH_ signals        FEAT_ signals
        (visible)            (internal)
             │                    │
             └─────────┬──────────┘
                       │ derived from
               ┌───────▼───────┐
               │  Raw events   │
               │  (ingested)   │
               └───────────────┘

The key principle: operators only interact with AUTH_ signals in playbooks. FEAT_ signals are engine-internal. This separation keeps the policy layer clean and deterministic.

3. Why This Matters

Without taxonomy	With taxonomy
"What signal fired?" is unclear	Signal name immediately identifies layer and intent
Playbook rules are fragile	Only AUTH_ signals are playbook-addressable — no surprises
Double-counting risk	FEAT* signals feed AUTH* signals — no double-counting
Debugging is hard	Clear prefix → clear ownership → easier root cause analysis

Overview​

1. Naming Convention​

AUTH_ — Controllable Feature Signals​

FEAT_ — Internal Feature Detectors​

2. Signal Flow Architecture​

3. Why This Matters​

See Also​