VECTORIO
DE
EnglishDeutsch

„Preise pro Gigabyte zwingen Sie, zwischen Kosten und Abdeckung zu wählen“

SIEM-Ingest senken, jedes Log behalten.

Logs vor dem SIEM vorfiltern, aggregieren und anreichern; günstige Aufbewahrung in voller Detailtiefe und Backtesting auf einer Maschine

Das Problem
  • Ich zahle pro Gigabyte und verwerfe deshalb Logs, die ich nach einem Sicherheitsvorfall brauchen könnte.
  • NIS2 verlangt Vorfallnachweise binnen 24 Stunden, aber meine Logs sind nur stichprobenartig vorhanden oder gelöscht.
  • Erkennungs-Pipelines sind nicht reproduzierbar, also kann ich eine neue Regel nicht rückwirkend an den Daten des Vorjahres testen.
Mit PROTOR
  • Logs vor dem SIEM vorfiltern, aggregieren und anreichern; günstige Aufbewahrung in voller Detailtiefe und Backtesting auf einer Maschine
  • Erkennungsregeln reproduzierbar auf historischen Daten erneut ausführen
  • Regulierte SOCs halten Logdaten im eigenen Rechtsraum

Von heute zum ersten Ergebnis.

Was Sie heute tun

ein SIEM mit Abrechnung pro Gigabyte

Logs, die nach einem Einbruch wichtig sein könnten, werden aus Kostengründen verworfen, und NIS2 verlangt Vorfall-Nachweise innerhalb von 24 Stunden (72 Stunden für die Meldung, ein Monat für den Abschlussbericht).

Mit PROTOR

Logs werden vor dem SIEM lokal gefiltert, aggregiert und angereichert: 1 Mrd. Zeilen in 32,1 ms. Alles bleibt für Wiederholung und Rückwärtstests verfügbar.

Ihr erster Schritt

Schalten Sie PROTOR für eine laute Logquelle vor das SIEM und vergleichen Sie das Ingest-Volumen.

eine Logquelle
So läuft es

Transaktionen, bewertet gegen jeden einzelnen Kunden. Schritt für Schritt.

Jede Transaktion wird mit dem üblichen Verhalten des Kunden verglichen; riskante werden gestoppt, als kritischer Alarm gemeldet und als Fall abgelegt.

PROTOR · Transaktionen, bewertet gegen jeden einzelnen Kundenläuft
KundenprofileZufallsdatenTransaktionsstromZufallsdatenKunde nachschlagenAbgleichRisikowert berechnenFelder berechnenBetrugsprüfungQualitätsprüfungFreigegebene ZahlungenCSV-AusgabeBetrugsalarmAlarmBetrugsfälle (CSV)CSV-Ausgabe
  1. Kundenprofile · TransaktionsstromZufallsdaten · Zufallsdaten
  2. Kunde nachschlagenAbgleich
  3. Risikowert berechnenFelder berechnen
  4. BetrugsprüfungQualitätsprüfung
  5. Freigegebene Zahlungen · BetrugsalarmCSV-Ausgabe · Alarm
  6. Betrugsfälle (CSV)CSV-Ausgabe
Knoten
customer-profiles → Generators.Random
tx-gen → Generators.Random
profile-lookup → ETL.Lookup
risk-compute → ETL.Compute
fraud-gate → Sync.QualityGate
approved-csv → CSV.Publisher
fraud-alert → ETL.Alert
fraud-csv → CSV.Publisher
ProfilabgleichRisikowertkritischer Alarm je Fall
  1. KundenprofileLädt die Kundenreferenztabelle (Durchschnittsbetrag, Häufigkeit, Risikostufe).
  2. Kunde nachschlagenWartet, bis die Profile bereit sind, und ordnet dann jeder Transaktion ihr Kundenprofil zu.
  3. Risikowert berechnenBerechnet einen Risikowert aus dem Betrag im Verhältnis zur Norm des Kunden.
  4. BetrugsprüfungLeitet alles mit einem Risiko ab 3,0 in eine Dead-Letter-Tabelle.
  5. Freigegebene ZahlungenSchreibt freigegebene Transaktionen.
  6. BetrugsalarmLöst für jede ausgeleitete Zeile einen kritischen FraudDetected-Alarm aus.

Ein echter Workflow aus unserer End-to-End-Testsuite; die Designer-Ansicht ist illustriert.

Das erhalten Sie. Ab dem ersten Pilotprojekt.

Logs vor dem SIEM vorfiltern, aggregieren und anreichern; günstige Aufbewahrung in voller Detailtiefe und Backtesting auf einer Maschine

Erkennungsregeln reproduzierbar auf historischen Daten erneut ausführen

Regulierte SOCs halten Logdaten im eigenen Rechtsraum

Warum Ihre Werkzeuge an Grenzen stoßen.

×

SIEMs mit Volumenpreisen bestrafen lange Aufbewahrung und breite Abdeckung.

×

Log-Stacks auf Basis von JVM/Elastic/Spark brauchen große Cluster und laufendes Tuning.

×

Cloud-SIEMs stehen im Konflikt mit Datensouveränität und Air-Gap-Anforderungen.

Was den Druck erzeugt
  • NIS2 Art. 21 (Risikomanagement einschließlich Vorfallbehandlung) und Art. 23 (Meldung)
  • NIST SP 800-53 AU-2 / SI-4: Kontrollen für Protokollierung und Überwachung
  • DORA für Finanzunternehmen

Ihr Pilotprojekt. Drei Schritte.

1

Ihre Daten und Ihr Ziel

Sagen Sie uns, welche Daten Sie haben, wo sie liegen und welches Ergebnis Sie brauchen.

2

Ein klar abgegrenzter Pilot

Auf Ihren Daten und Ihrer Hardware, mit vorab festgehaltenem Erfolgsmaßstab.

3

Eine klare Entscheidung

Sie sehen das Ergebnis an diesem Maßstab – und behalten jeden Workflow und jeden Datensatz.

Beta · Design-Partner gesucht

Zeigen Sie uns Ihr schwierigstes Datenproblem. Wir lösen es gemeinsam.

Ein kurzes Pilotprojekt mit Ihren Daten auf Ihrer Hardware. Was Erfolg bedeutet, legen wir vorher gemeinsam fest.