Zum Hauptinhalt springen
davque

Ablauf

So arbeiten wir

Wie ein Auftrag abläuft, was jede Seite beiträgt und welche Regeln während des Tests gelten.

Ablauf

Sechs Phasen

  1. Erstgespräch und Scoping

    Woche 0

    30 Minuten, unverbindlich. Wir klären, was getestet wird, ob der Durchgang Whitebox (mit Quellcode-Zugriff) oder Blackbox (nur Außensicht) ist, welche Umgebungen es gibt und was nicht zum Scope gehört. Ergebnis ist ein schriftlicher Scope mit Aufwand und Preis, oder die Empfehlung für einen anderen Zuschnitt.

  2. Vertrag und Autorisierung

    vor jedem Test

    Rahmenvertrag, NDA und die Testautorisierung: ein Dokument, das Prüfgegenstand, Domains und IP-Bereiche, Testzeitfenster, erlaubte und ausgeschlossene Techniken und einen Notfallkontakt benennt. Werden personenbezogene Daten verarbeitet, kommt ein Auftragsverarbeitungsvertrag dazu. Liegt Ihr System bei einem Hoster, prüfen wir gemeinsam, ob dessen Freigabe nötig ist.

  3. CVE-Scan und Pentest-Modelle

    Phase 1 des Tests

    Im Whitebox-Durchgang werden Codebasis und Abhängigkeiten zuerst auf bekannte CVEs gescannt. Unsere Pentest-Modelle, betrieben auf eigener Hardware, kartieren dann die Angriffsfläche und testen sie; im Blackbox-Durchgang starten sie von außen, nur mit dem Scope. Ergebnis ist eine Kandidatenliste, noch keine Findings.

  4. Manuelle Verifikation

    Phase 2 des Tests

    Ein Analyst reproduziert jeden Kandidaten und bewertet ihn im Kontext. Nicht ausnutzbare Kandidaten werden verworfen und dokumentiert. Parallel testen Analysten von Hand, was Automatisierung nicht abdeckt: Rechtemodelle, Business-Logik und Angriffsketten.

  5. Report

    Abschluss

    Eine Executive Summary und ein technischer Teil. Findings sind nach CWE klassifiziert, und der Report listet die getesteten CVEs und was wir sonst getan haben. Jedes Finding hat Nachweis, Reproduktionsschritte, Auswirkung und Empfehlung.

  6. Abschlussgespräch und Retest

    nach dem Fix

    Wir gehen den Report mit Ihrem Team durch. Nach dem Fix prüfen wir die betroffenen Findings erneut und dokumentieren das Ergebnis.

Rules of Engagement

Regeln während des Tests

Diese Punkte sind Teil jeder Testautorisierung.

Abbruchkriterien

Bei drohender Beeinträchtigung des Produktivbetriebs brechen wir ab und eskalieren an den Notfallkontakt. Verfügbarkeitstests nur, wenn ausdrücklich beauftragt.

Datensparsamkeit

Wir extrahieren nur so viele Daten wie zum Nachweis nötig. Echte personenbezogene Daten werden nicht exportiert, sondern maskiert dokumentiert.

Keine Weitergabe

Findings bleiben zwischen Ihnen und uns. Veröffentlichungen, auch anonymisiert, nur mit Ihrer schriftlichen Zustimmung.

Ohne unterzeichnete Autorisierung findet kein Test statt. Das gilt auch für kurze Vorab-Prüfungen und für Systeme, die Ihnen offensichtlich gehören. Unautorisierte Zugriffe auf fremde Systeme sind nach § 202a–c StGB strafbar. Mehr dazu unter Sicherheit und Vertrauen.

Hintergrund

Warum regelmäßig testen

Eine einzelne Prüfung pro Jahr deckt die Releases dazwischen nicht ab. Neue Endpunkte und Abhängigkeiten können jederzeit Schwachstellen einführen.

Punktuell

Eine Prüfung pro Jahr deckt den Rest des Jahres nicht ab.

Kosten pro Durchlauf

Tagessätze machen häufiges Testen teuer, deshalb wird seltener getestet als sinnvoll.

Scanner-Rauschen

Reine Tool-Reports listen hunderte Treffer ohne Kontext.

Quellcode

Viele Unternehmen dürfen Quellcode nicht an einen Cloud-Dienst geben.

FAQ

Häufige Fragen

Verlässt unser Quellcode das Haus?

Er verlässt Ihre Umgebung, weil Sie ihn uns übergeben. Er geht nicht an Cloud-KI-Anbieter. Quellcode analysieren wir in einer isolierten Offline-Umgebung auf Hardware, die wir selbst betreiben.

Ist das ein echter Pentest oder nur ein Scanner?

Beides, in Schichten. Ein CVE-Scan Ihrer Codebasis ist die Grundlage. Obendrauf testen unsere Pentest-Modelle und Analysten, was in keiner CVE-Liste steht: Business-Logik, Rechtemodelle und Angriffsketten. Jedes Finding im Report wurde von einer Person reproduziert.

Was ist der Unterschied zwischen Whitebox und Blackbox?

Im Whitebox-Durchgang geben Sie uns Quellcode-Zugriff, idealerweise mit Architekturnotizen und Testumgebung. Wir scannen die Codebasis auf bekannte CVEs, testen sie mit unseren eigenen Modellen und greifen die laufende Anwendung mit dem Wissen aus dem Code an. Im Blackbox-Durchgang bekommen wir nur Ziel und Scope und arbeiten wie ein externer Angreifer. Wir empfehlen im Scoping einen Modus. Beide lassen sich kombinieren.

Testet ihr auch Systeme, die online sind?

Ja. Bei Blackbox-Durchgängen gegen Online-Systeme kommt unser Testverkehr aus unserer eigenen Infrastruktur über das Internet und berührt nur die Ziele in Ihrem unterzeichneten Scope, innerhalb des vereinbarten Zeitfensters.

Wie viele False Positives enthält der Report?

Keine. Eine Person reproduziert jedes Finding, bevor es in den Report kommt. Auf Wunsch listen wir verworfene Kandidaten in einem Anhang auf.

Was braucht ihr von uns, bevor ihr testen dürft?

Eine unterzeichnete Testautorisierung mit definiertem Scope, Testzeitfenster und Notfallkontakt, dazu Rahmenvertrag und NDA. Ohne diese Dokumente starten wir nicht. Liegt das System bei einem Hoster, brauchen wir eventuell zusätzlich dessen Freigabe.

Können wir den Report für Audits nach ISO 27001, SOC 2 oder NIS2 nutzen?

Der Report dokumentiert Scope, Zeitraum, Prüfer, Findings nach CWE, die getesteten CVEs und den Retest. Er kann als Nachweis technischer Prüfung dienen. Wir sind keine Zertifizierungsstelle und stellen keine Zertifikate aus.

Was kostet das?

Preise auf Anfrage. Siehe Preise.

Erstgespräch buchen

30 Minuten, unverbindlich. Wir klären Scope, Testmodus und Preis.

  • Kein Test ohne schriftliche Autorisierung und definierten Scope.
  • Quellcode und Testdaten gehen nie an Cloud-KI-Anbieter.
  • Jedes Finding wird vor Auslieferung von einer Person verifiziert.