Geïsoleerde alerts zijn een ticketmachine. De werkelijke dreiging zit in de combinatie. Zo verbindt monsys CVE-scanning, honeypots, capacity en process DNA via SMART correlaties.

Een monitoring-platform dat alleen alerts gooit is een ticketmachine. Elke pijplijn — CVE-matching, honeypots, capacity, kernel-tracker, integrity — produceert zijn eigen signalen, maar de werkelijke dreiging zit bijna altijd in de combinatie.

Dit is hoe monsys die pijplijnen verbindt via SMART correlaties.

Het probleem met geïsoleerde pijplijnen

Stel: je hebt drie events op dezelfde server binnen tien minuten:

Een CVE van severity Medium op een npm-package (axios@0.27.2, GHSA-2025-xxxx)
Een disk-capaciteitsalert: 89% vol, verwachte vollooptijd 4 uur
Een process DNA-afwijking: /usr/bin/node heeft een onbekende hash

Op zichzelf: CVE Medium is low-priority. Disk vol is operationeel. Process DNA is verdacht maar misschien een auto-update.

Samen: een node-binary die stilletjes vervangen is, gecombineerd met abnormale diskactiviteit en een kwetsbare dependency in hetzelfde proces, is een actief incident.

SMART correlaties bouwen die verbanden automatisch.

Architectuur: één signal_streams tabel

Alle pijplijnen schrijven naar dezelfde hypertable via een uniforme Go interface:

emitter.Emit(ctx, tenantID, signals.Signal{
    Source:      "process_dna",          // of "cve_match", "honeypot", "capacity", ...
    SubjectType: "agent",
    SubjectID:   agentID,
    Key:         "binary.hash_mismatch",
    Value:       map[string]any{
        "exe_path":      "/usr/bin/node",
        "baseline_hash": "a3f2c1...",
        "observed_hash": "b7e4d2...",
    },
    Severity:    signals.SeverityCritical,
    ObservedAt:  time.Now().UTC(),
})

Elke worker die een nieuwe correlation-type wil toevoegen, hoeft alleen SourceToCategory te updaten en één Emit()-call te plaatsen. De rest van de infrastructure (dashboards, Trust Score, evidence packs, alerts) pikt het automatisch op.

De negen correlatie-workers

1. Blast-radius CVE prioritering

Niet elke CVE is even urgent. Een Critical op een server die nergens aan gekoppeld is, is minder acuut dan een Medium op een load balancer waarachter 40 production-services hangen.

De CapacityPredictorWorker (1u cadence) doet een Breadth-First Search over de topology-graph om de hop-afstand van elke node tot het dichtstbijzijnde internet-toegangspunt te berekenen:

GET /api/v1/topology/exposure?map_id=<id>

Response:
{
  "nodes": [
    { "agent_id": "web-edge-01", "internet_hops": 0, "exposure_score": 1.0 },
    { "agent_id": "api-server-03", "internet_hops": 1, "exposure_score": 0.7 },
    { "agent_id": "db-primary", "internet_hops": 2, "exposure_score": 0.4 }
  ]
}

CVE-aanbevelingen worden gehersorteerd op cvss_base × exposure_score × epss_probability. Een CVSS 7.5 op de database-server met EPSS 0.02 scoort lager dan een CVSS 5.5 op de edge-server met EPSS 0.34.

2. Capacity-als-CVE

Disk vol klinkt operationeel, niet security. Maar een server met 100% volle disk kan geen logs meer schrijven, geen core dumps aanmaken, en geen security-tools starten. Dat is een security-conditie.

De worker fit een lineaire regressie via Postgres:

SELECT
    regr_slope(disk_used_pct, EXTRACT(EPOCH FROM observed_at)) AS slope,
    regr_intercept(disk_used_pct, EXTRACT(EPOCH FROM observed_at)) AS intercept,
    regr_r2(disk_used_pct, EXTRACT(EPOCH FROM observed_at)) AS r2
FROM agent_metrics
WHERE agent_id = $1
  AND mount_point = $2
  AND observed_at > NOW() - INTERVAL '30 days'

Op basis van slope en intercept wordt berekend wanneer de disk 100% bereikt. Dit wordt als capacity.disk_full-finding geëmit, behandeld als een vulnerability met een deadline.

3. Lateral-movement detectie

Dit is de correlatie die het vaakst verrast in demos:

-- LateralMovementWorker, cadence 60s
SELECT
    hp.agent_id      AS source_agent,
    hp.canary_path,
    ae.target_agent_id,
    ae.auth_user,
    ae.src_ip,
    ae.observed_at
FROM honeypot_events hp
JOIN auth_events ae
    ON ae.src_ip IN (
        SELECT ip_address FROM agent_ips WHERE agent_id = hp.agent_id
    )
    AND ae.observed_at BETWEEN hp.observed_at - INTERVAL '5 min'
                            AND hp.observed_at + INTERVAL '5 min'
    AND ae.success = true
    AND ae.auth_type = 'ssh'
WHERE hp.tenant_id = $1
  AND hp.observed_at > NOW() - INTERVAL '70 seconds'

Een honeypot-trigger op server A gevolgd door een succesvolle SSH-login van server A naar server B genereert een lateral_movement_suspected-event met MITRE-tags T1021 (Remote Services) en T1078 (Valid Accounts). Beide events zijn gelinkt in het detection-record — de forensische trail zit al klaar.

4. Compliance-erosion alerts

Compliance is geen statisch punt — het erodeert stilletjes als workers crashen, keys verlopen, of evidence-generatie faalt.

-- ComplianceErosionWorker, cadence 24u
INSERT INTO compliance_evidence_history (tenant_id, control_id, evidence_count, snapshot_date)
SELECT tenant_id, control_id, COUNT(*), CURRENT_DATE
FROM compliance_evidence
GROUP BY tenant_id, control_id;

-- Alert bij >50% verlies vs 7 dagen geleden
SELECT
    h1.control_id,
    h1.evidence_count AS current_count,
    h7.evidence_count AS week_ago_count,
    (1.0 - h1.evidence_count::float / NULLIF(h7.evidence_count, 0)) AS loss_rate
FROM compliance_evidence_history h1
JOIN compliance_evidence_history h7
    ON h1.control_id = h7.control_id
    AND h7.snapshot_date = CURRENT_DATE - INTERVAL '7 days'
WHERE h1.snapshot_date = CURRENT_DATE
  AND (1.0 - h1.evidence_count::float / NULLIF(h7.evidence_count, 0)) > 0.5

Dit vangt situaties die geen alerts genereren maar wel een compliance-probleem zijn: een backup-worker die stilletjes gestopt is, een certificate-scanner die faalt, een log-pipeline die leegloopt.

5. Centrality-gewogen Trust Score

De Trust Score (0-100) is een gewogen gemiddelde over 8 compliance-categorieën. Maar niet elke agent weegt gelijk. Een chokepoint-server (load balancer, VPN-gateway, database) die faalt heeft een groter impact dan een leaf-node.

CentralityRefreshWorker (uurlijks):
→ Bereken betweenness centrality (Brandes-algoritme) over topology_edges
→ Sla op in topology_node_centrality
→ Trust Score weegt elke agent met (1 + centrality)
   → max centrality ≈ 1.0 → chokepoint telt tot 2× zo zwaar

Een server met centrality 0.8 die een failing compliance-control heeft, drukt de Trust Score harder dan dezelfde failing control op een leaf-node. SPOFs worden automatisch zwaarder gewogen.

6. False-positive learning

Elke detectie-regel die meer dan 50% van de tijd binnen 5 minuten geacknowledged wordt, is waarschijnlijk te agressief ingesteld.

GET /api/v1/detection/rules/flake-stats

Response:
[
  {
    "rule_id": "cpu_threshold_prod",
    "fires_30d": 84,
    "quick_ack_30d": 52,
    "flake_rate": 0.619,
    "opinion": "Verhoog threshold van 85% naar 92%, of voeg duration-filter toe: CPU>85% voor >15min"
  }
]

Dit is operator-gestuurd: de suggestie wordt getoond, maar nooit automatisch toegepast. Auditors willen herhaalbare, menselijk-goedgekeurde regels — geen systeem dat zichzelf aanpast.

7. Time-machine diff

Forensisch onderzoek begint bijna altijd met: "wat veranderde er tussen maandag en vrijdag?"

GET /api/v1/time-machine/diff?agent_id=web-edge-01&from=2026-05-19T00:00:00Z&to=2026-05-23T23:59:59Z

Response:
{
  "packages": {
    "added":   ["libssl3 3.0.15-1"],
    "removed": [],
    "upgraded": [
      { "name": "openssl", "from": "3.0.13-1", "to": "3.0.15-1" }
    ]
  },
  "services": {
    "added":   ["monsys-agent"],
    "removed": ["rsync"]
  },
  "kernel":   { "from": "6.8.0-51", "to": "6.8.0-55" },
  "open_ports": {
    "added":   [{ "port": 9100, "process": "node_exporter" }],
    "removed": []
  }
}

Eén API-call geeft een forensische tijdlijn van alle inventory-wijzigingen. Geen manuele vergelijking van logbestanden.

Hoe de correlaties de Trust Score beïnvloeden

De Trust Score (0-100) reflecteert de gecombineerde output van alle pijplijnen. Een paar voorbeelden van hoe correlaties de score beïnvloeden:

Event	Score-impact
Lateral movement detected (unacknowledged)	-15 tot -25 punten (afhankelijk van betrokken node-centraliteit)
Compliance erosion >50% op ISO 27001 A.8.7	-8 punten per failing control
CVE Critical op internet-facing node (EPSS > 0.1)	-12 punten
Process DNA mismatch unresolved > 24u	-10 punten
Alle honeypot canaries intact	+5 punten (positief signaal)

De score is reproduceerbaar via inputs_hash in het evidence pack — een auditor kan berekenen waarom de score op een specifieke dag X was.

Operationele implicaties

De correlatie-workers voegen enige load toe aan de hub-database. Operationele notities:

LateralMovementWorker (60s) is de zwaarste: JOIN over twee tabellen met time-window. Geoptimaliseerd via composite index op (tenant_id, src_ip, observed_at) op auth_events.
Alle workers zijn idempotent: ze kunnen opnieuw draaien zonder dubbele events te genereren.
Cold-start delay van 2-5 minuten na hub-restart voorkomt dat zware queries vuren terwijl de database nog aan het opwarmen is.

Wat dit in de praktijk betekent

Zonder correlaties: drie aparte alerts, elk triageert een analist apart, conclusie onzeker.

Met correlaties: één detection-event lateral_movement_suspected met de volledige forensische context — welke honeypot getriggerd werd, welke SSH-login volgde, op welke servers, met welke user. De analist hoeft niet te correleren — het systeem doet het.

Dat is het verschil tussen een ticketmachine en een monitoring-platform.

SMART correlaties zijn gedocumenteerd in docs.monsys.ai/nl/security/smart-correlations. Eerste vijf servers gratis: monsys.ai/nl/signup.

SMART correlaties: hoe 15 onafhankelijke pijplijnen één geprioriteerde view worden