Blue Team

Overview

The Blue Team serves as the defensive backbone of the Prismatic Platform's six-team color-team security architecture. Through continuous monitoring, multi-domain signal aggregation, and four-type drift detection, Blue Team maintains the epistemic integrity of the platform's knowledge systems against both external adversarial pressure and internal degradation. While Red Team probes for vulnerabilities through offensive simulation, Blue Team builds and operates the defensive infrastructure that detects, contains, and responds to threats in real time.

The Blue Team's approach to defense is fundamentally evidence-based, grounded in the NABLA Infinity framework's requirement for signal plurality and contradiction preservation. Rather than operating on binary alert/no-alert logic, Blue produces structured defensive posture assessments that quantify confidence levels, track signal provenance, and preserve contradictory indicators for Purple Team synthesis. This evidence-centric approach distinguishes the platform's defensive posture from traditional SIEM-based security operations, which often reduce complex signal landscapes to binary classifications.

The defensive posture maintained by Blue Team spans four detection domains — behavioral drift, configuration drift, dependency drift, and performance drift — each with dedicated detection pipelines, baseline management, and response protocols. These four domains provide comprehensive coverage of the attack surface that Red Team tests through its five epistemic attack primitives, creating the adversarial-defensive feedback loop that Purple Team synthesizes into continuous improvement.

Mission and Doctrine

The Blue Team mission is to maintain a continuously accurate defensive posture assessment for the Prismatic Platform's epistemic systems, detecting and characterizing threats before they compromise knowledge integrity. This mission operates under the principle that defense is not a static state but a continuous process of observation, analysis, and adaptation.

Mission Principles

The NO MERCY, NO DOUBTS doctrine applies to Blue Team operations with emphasis on NO DOUBTS: every defensive assessment must be evidence-based, every signal must be traceable, and every conclusion must be supported by multiple independent sources. NO MERCY manifests in the zero-tolerance approach to detection gaps — if a Red Team simulation reveals a blind spot, Blue Team addresses it immediately.

Team Composition

The Blue Team comprises four specialized agents organized around the defensive lifecycle: command and synthesis, authentication monitoring, drift detection, and signal aggregation.

blue-commander

The Blue Commander operates at L3 strategic authority, synthesizing evidence streams from all three specialist agents into unified defensive posture assessments. The commander maintains the master posture state, coordinates response priorities, and manages the handoff of defensive findings to Purple Team for Red-Blue loop closure. The commander also manages detection threshold calibration, ensuring that sensitivity levels balance detection capability against false positive rates.

blue-auth-sentinel

The Auth Sentinel monitors authentication boundaries — the points where identity, authorization, and access control decisions are made. This agent detects anomalous authentication patterns including unusual login locations, abnormal session durations, privilege escalation attempts, and credential reuse indicators. The sentinel maintains behavioral baselines per user, per service, and per role, enabling detection of deviations that may indicate compromised credentials or insider threats.

blue-drift-detector

The Drift Detector operates across all four drift detection domains, maintaining baselines and detecting deviations that may indicate degradation, compromise, or unintended change. This is the broadest-scope specialist, responsible for the continuous comparison of current system state against established baselines with configurable drift thresholds per domain and metric type.

blue-signal-aggregator

The Signal Aggregator performs cross-domain correlation, combining signals from authentication events, drift detections, platform telemetry, external threat feeds, and agent reports into correlated intelligence products. The aggregator enforces NABLA signal plurality requirements, refusing to elevate any assessment that depends on a single signal source.

Defensive Domains

Four Drift Detection Types

Detection Architecture

defmodule PrismaticDark.BlueTeam.DriftDetector do
  @moduledoc """
  Four-domain drift detection with configurable thresholds.
  Maintains baselines and detects deviations across behavioral,
  configuration, dependency, and performance domains.
  """
  use GenServer

  @type drift_type :: :behavioral | :configuration | :dependency | :performance
  @type detection :: %{
    type: drift_type(),
    source: String.t(),
    baseline: term(),
    current: term(),
    deviation: float(),
    risk: :low | :medium | :high | :critical
  }

  @spec assess_drift(drift_type(), keyword()) :: {:ok, [detection()]}
  def assess_drift(domain, opts \\ []) do
    threshold = Keyword.get(opts, :threshold, default_threshold(domain))
    baseline = load_baseline(domain)
    current = sample_current(domain)

    detections =
      compare(baseline, current)
      |> Enum.filter(fn {_key, deviation} -> deviation > threshold end)
      |> Enum.map(&build_detection(domain, &1, baseline, current))

    :telemetry.execute(
      [:prismatic, :blue_team, :drift, :assessed],
      %{detection_count: length(detections), domain: domain},
      %{threshold: threshold}
    )

    {:ok, detections}
  end
end

Signal Aggregation Pipeline

flowchart TD
    Sources["Signal Sources<br/>App logs · Metrics · Security events · External feeds · Agent reports · Drift detections"]
    Corr["Correlation Engine<br/>Temporal · Spatial · Causal · NABLA plurality (≥2 sources)"]
    Posture["Defensive Posture Assessment<br/>Health score · Per-domain risk · Confidence (provenance) · Contradiction register"]
    Hand["Purple Team Handoff"]

    Sources --> Corr --> Posture --> Hand

    classDef source fill:#0f172a,stroke:#3b82f6,color:#fff
    classDef engine fill:#1e293b,stroke:#10b981,color:#fff
    classDef hand fill:#1e293b,stroke:#a855f7,color:#fff
    class Sources source
    class Corr,Posture engine
    class Hand hand

Technical Architecture

Blue Team operations are implemented as an OTP application within the PrismaticDark umbrella, with dedicated GenServer processes for each detection domain and a supervisor managing the detection lifecycle.

System Architecture

flowchart TD
    Cmd["Blue Commander (L3)"]
    Cmd --> PSyn["Posture Synthesizer"]
    Cmd --> Det["Detection Pipeline"]
    Cmd --> Resp["Response Coordinator"]

    PSyn --> P1["Evidence Aggregator"]
    PSyn --> P2["Confidence Calculator"]
    PSyn --> P3["Contradiction Register"]

    Det --> Auth["Auth Sentinel"]
    Det --> Drift["Drift Detector"]
    Det --> Sig["Signal Aggregator"]

    Auth --> A1["Login Pattern Analyzer"]
    Auth --> A2["Privilege Monitor"]
    Auth --> A3["Session Tracker"]

    Drift --> D1["Behavioral Baseline Mgr"]
    Drift --> D2["Config Snapshot Compar."]
    Drift --> D3["Dependency Ver. Tracker"]
    Drift --> D4["Performance Baseline Mon."]

    Sig --> S1["Temporal Correlator"]
    Sig --> S2["Spatial Correlator"]
    Sig --> S3["Causal Chain Builder"]
    Sig --> S4["Plurality Enforcer"]

    Resp --> R1["Alert Router"]
    Resp --> R2["Auto-Remediation Engine"]
    Resp --> R3["Purple Team Emitter"]

    classDef tier fill:#1e293b,stroke:#3b82f6,color:#fff
    classDef sub fill:#1e293b,stroke:#0ea5e9,color:#fff
    classDef leaf fill:#0f172a,stroke:#64748b,color:#e2e8f0
    class Cmd,PSyn,Det,Resp tier
    class Auth,Drift,Sig sub
    class P1,P2,P3,A1,A2,A3,D1,D2,D3,D4,S1,S2,S3,S4,R1,R2,R3 leaf

Authentication Boundary Monitoring

defmodule PrismaticDark.BlueTeam.AuthSentinel do
  @moduledoc """
  Authentication boundary monitoring with behavioral baselines.
  Detects anomalous patterns in login, session, and privilege events.
  """
  use GenServer

  @anomaly_types [:unusual_location, :abnormal_time, :rapid_succession,
                  :privilege_escalation, :credential_reuse, :session_hijack]

  @spec analyze_auth_event(map()) :: {:ok, :normal} | {:alert, map()}
  def analyze_auth_event(event) do
    baseline = get_user_baseline(event.user_id)

    anomalies =
      @anomaly_types
      |> Enum.map(&check_anomaly(&1, event, baseline))
      |> Enum.reject(&is_nil/1)

    case anomalies do
      [] -> {:ok, :normal}
      findings ->
        :telemetry.execute(
          [:prismatic, :blue_team, :auth, :anomaly],
          %{anomaly_count: length(findings)},
          %{user_id: event.user_id, types: Enum.map(findings, & &1.type)}
        )
        {:alert, %{anomalies: findings, event: event, baseline: baseline}}
    end
  end
end

Telemetry Events

NABLA Compliance

Blue Team is the primary enforcement arm for NABLA axioms in the defensive domain. The Signal Aggregator explicitly enforces signal plurality, and the Posture Synthesizer preserves contradictions rather than resolving them.

Plurality Enforcement Example

defmodule PrismaticDark.BlueTeam.PluralityEnforcer do
  @moduledoc """
  Enforces NABLA Axiom 1: minimum 2 independent signals for any belief.
  """

  @spec validate_assessment(map()) :: {:ok, map()} | {:error, :insufficient_plurality}
  def validate_assessment(%{signals: signals} = assessment) do
    independent_sources =
      signals
      |> Enum.map(& &1.source)
      |> Enum.uniq()
      |> length()

    if independent_sources >= 2 do
      {:ok, Map.put(assessment, :plurality_verified, true)}
    else
      {:error, :insufficient_plurality}
    end
  end
end

Performance Metrics

Integration Points

Signal Flow

flowchart LR
    Gray["Gray Team Findings<br/>(boundary seeds)"]
    Red["Red Team Attack Results<br/>(vulnerability data)"]
    Tel["Platform Telemetry<br/>(runtime events)"]
    Feed["External Threat Feeds<br/>(intelligence data)"]
    Agent["Agent Reports<br/>(cross-team signals)"]
    Blue["Blue Team"]
    Purple["Purple Team<br/>(Synthesis &amp; Closure)"]

    Gray --> Blue
    Red --> Blue
    Tel --> Blue
    Feed --> Blue
    Agent --> Blue
    Blue --> Purple

    classDef input fill:#0f172a,stroke:#475569,color:#e2e8f0
    classDef blue fill:#1e293b,stroke:#3b82f6,color:#fff
    classDef purple fill:#1e293b,stroke:#a855f7,color:#fff
    class Gray,Red,Tel,Feed,Agent input
    class Blue blue
    class Purple purple

Outputs

Related Resources

• Red Team — Adversarial simulation that drives Blue defensive development
• Purple Team — Synthesis hub that closes the Red-Blue feedback loop
• Gray Team — Boundary exploration that surfaces defensive gaps
• White Team — Formal verification of Blue defensive implementations
• Black Team — Theoretical threat models informing defensive strategy
• Telemetry Integration — Foundational signal source for all detection
• Real-Time Monitoring — Monitoring infrastructure Blue Team operates within
• Quality Gates — Deployment gates incorporating Blue posture assessments

Connect & Contribute

Created by Tomáš Korcak (korczis) | Open Source under GHL

• GitHub | GitLab | LinkedIn | Contact
• Developer Portal | Architecture | Meet the Creator