VAPT erklärt: Vulnerability Assessment und Penetrationstest

In Indien ist „VAPT“ der gängige Begriff für Sicherheitstests. Kunden, Partner, Prüfer und regulierte Gegenparteien verlangen häufig einen „VAPT-Bericht“, bevor sie einen Vertrag unterschreiben, eine Integration anbinden oder einen Launch freigeben. Der Begriff vereint zwei Tätigkeiten: Vulnerability Assessment (Schwachstellenbewertung), die breit nach bekannten Schwachstellen sucht, und Penetrationstests, die in der Tiefe untersuchen, ob sich diese Schwachstellen ausnutzen lassen. Dieser Leitfaden erklärt, was ein VAPT-Auftrag üblicherweise umfasst, wie Sie den Scope sinnvoll festlegen und was Sie prüfen sollten, bevor Sie das Ergebnis teilen.

Was es ist

Der Teil Vulnerability Assessment (VA) ist breit angelegt. Er kombiniert automatisierte Scans mit einer Prüfung, um fehlende Patches, veraltete Komponenten, offen erreichbare Dienste, schwache Konfigurationen und gängige Webprobleme in vereinbarten Assets zu erkennen. Der Teil Penetrationstest (PT) geht in die Tiefe. Ein Tester arbeitet manuell an ausgewählten Zielen, typischerweise Webanwendungen, APIs und mobilen Apps, validiert Befunde und testet Authentifizierung, Session-Handling, Zugriffskontrolle zwischen Rollen, Datenexposition und Geschäftslogik. Zusammen liefert VA die Abdeckung und PT die Sicherheit darüber, was tatsächlich ausnutzbar ist. Ein VAPT-Auftrag sollte mit einem schriftlichen Bericht enden, der Scope, Methode, nach Schweregrad bewertete Befunde mit Nachweisen, Hinweise zur Behebung und, sofern vereinbart, das Ergebnis eines Nachtests nach den Korrekturen festhält. Anfragen verweisen mitunter auf Rahmenwerke wie die OWASP Top 10 oder die OWASP-Leitlinien zur Sicherheit mobiler Anwendungen; diese sind nützliche Bezugspunkte dafür, was Tester betrachten.

Für wen es gedacht ist

VAPT wird häufig verlangt von oder für:

SaaS-, Fintech- und E-Commerce-Teams, deren Unternehmenskunden im Einkaufsprozess einen aktuellen VAPT-Bericht verlangen
Unternehmen, die sich an einen Partner, eine Bank oder einen Zahlungsanbieter anbinden, der vor der Integration Nachweise über Sicherheitstests verlangt
Produktteams, die den öffentlichen Launch einer Web- oder Mobilanwendung vorbereiten
Organisationen, die Hosting, Authentifizierung oder Zahlungsabläufe geändert haben und eine unabhängige Prüfung wünschen

Was es zu klären hilft

Ein gut abgegrenzter VAPT hilft zu klären:

welche Anwendungen, APIs und Umgebungen der Anfragende tatsächlich getestet sehen möchte
ob die Anforderung eine bestimmte Art von Prüfer oder Akkreditierung nennt, die vor der Wahl eines Anbieters bestätigt werden muss
welche Befunde validierte Risiken und welche Scanner-Beobachtungen sind
welche Behebung erfolgen muss, bevor ein Bericht mit gutem Gewissen geteilt werden kann

Was ist enthalten

Die genaue Anforderung schriftlich vom Anfragenden einholen: Assets, Tiefe, Berichtsformat und etwaige Kriterien für Anbieter
Ziele auflisten: Domains, Anwendungs-URLs, API-Basispfade, Builds mobiler Apps und Umgebungen (Staging oder Produktion)
Testkonten für jede Benutzerrolle vorbereiten, damit Tests der Zugriffskontrolle aussagekräftig sind
Schriftliche Autorisierung, Testzeitraum, benannte Ansprechpartner und Abbruchbedingungen bestätigen
Hosting-, CDN- oder WAF-Anbieter informieren, wenn deren Bedingungen dies verlangen
Schweregradbewertung, Berichtsformat und die Art der Weitergabe von Nachweisen vereinbaren
Zeit für die Behebung von Befunden einplanen und einen Nachtest vereinbarter Punkte anfordern

Was nicht enthalten ist

Eine Aussage, dass ein VAPT eine Anwendung sicher oder konform macht
Eine Behauptung, dass ein Anbieter eine bestimmte Akkreditierungs- oder Listungsanforderung erfüllt, ohne dies anhand dieser Anforderung zu prüfen
Tests von Systemen Dritter ohne Erlaubnis des Eigentümers
Rechtliche oder regulatorische Beratung dazu, was eine bestimmte Vorschrift verlangt

Wann man es wählt

Beauftragen Sie einen VAPT, wenn eine benannte Gegenpartei einen verlangt, vor einem bedeutenden Launch oder nach größeren Änderungen daran, wie Nutzer sich anmelden, bezahlen oder auf Daten zugreifen. Wenn die Anfrage aus einer regulierten Geschäftsbeziehung stammt, lesen Sie die Anforderung genau: Manche schreiben einen akkreditierten oder gelisteten Prüfer vor (in Indien verweisen einige Aufsichtsbehörden und Gegenparteien auf von CERT-In gelistete Prüfer), einen bestimmten Scope oder einen festen Testzyklus. Klären Sie diese Details zuerst mit dem Anfragenden, denn ein Bericht, der nicht zur Anforderung passt, muss womöglich wiederholt werden. Dieser Artikel dient der allgemeinen Information und ist keine rechtliche oder regulatorische Beratung.

Unser Ansatz

Nehmen Sie die Checkliste des Anfragenden als Ausgangspunkt und ergänzen Sie die Systeme, die für Ihr Unternehmen das größte Risiko tragen, auch wenn niemand danach gefragt hat. Testen Sie nach Möglichkeit in einer Staging-Umgebung, die der Produktion entspricht, und vereinbaren Sie vorab, wie mit Tests in der Produktion umgegangen wird, falls diese erforderlich sind. Unser Application Security Review umfasst Tests von Webanwendungen und APIs mit schriftlichen, nach Schweregrad gestuften Befunden und Hinweisen zur Behebung; breitere Scopes über mehrere Umgebungen oder Netzwerke werden über unseren Service Penetration Testing abgedeckt. In beiden Fällen werden Scope, Autorisierung und Berichterstattung vor Arbeitsbeginn schriftlich bestätigt. Beheben Sie nach der Lieferung zuerst die hohen und kritischen Befunde, dokumentieren Sie Entscheidungen zu akzeptierten Risiken und fordern Sie einen Nachtest an. Teilen Sie anschließend eine Management Summary oder ein Schreiben zum Behebungsstatus statt des vollständigen technischen Berichts, es sei denn, der Anfragende benötigt ausdrücklich diesen Detaillierungsgrad und verfügt über einen sicheren Weg, ihn zu empfangen.

Application Security Review

Zur Seite des Service Application Security Review