SOC 2 und Penetrationstests: Was Auditoren wirklich erwarten

In jeder Audit-Saison landet dieselbe Nachricht in unserem Posteingang. Ein Gründer leitet die Notiz seines Auditors weiter, der einen “Nachweis über Penetrationstests” verlangt, das Audit-Fenster schließt in drei Wochen, und im Anhang liegt ein Schwachstellenscan aus dem letzten Quartal mit der Frage: zählt das? Nein. Und genau in dieser Lücke, zwischen dem, was ein Team für ausreichend hält, und dem, was ein Prüfer am Ende tatsächlich abzeichnet, gerät das SOC-2-Penetrationstesting leise ins Wanken.

Sagen wir zuerst das Unpopuläre. SOC 2 schreibt keinen Penetrationstest vor. Es gibt in den Trust Services Criteria keine Klausel, die lautet “du sollst jährlich pentesten”. Was der Rahmen verlangt, ist, dass Sie auf Schwachstellen überwachen und nachweisen, dass Ihre Sicherheitskontrollen tatsächlich wirken. Ein echter Pentest ist zufällig der sauberste Nachweis, den Sie einem Auditor für beides vorlegen können, und genau deshalb stützt sich fast jeder Type-II-Bericht, den wir begleiten, am Ende auf einen solchen.

Hören Sie also auf zu fragen “brauche ich für SOC 2 einen Pentest”. Stellen Sie die beiden Fragen, auf die es ankommt: was muss der Test beweisen, und was muss der Bericht aussagen.

Die wichtigsten Erkenntnisse

• SOC 2 nennt Penetrationstests nie ausdrücklich, verlangt aber die Überwachung von Schwachstellen und den Nachweis, dass Kontrollen wirken, und ein Pentest ist der stärkste Beleg für beides.
• Ein Pentest lässt sich am direktesten den Common Criteria zu Risikobewertung und Systembetrieb zuordnen, insbesondere CC7.1, mit Unterstützung durch CC3.2 und CC4.1.
• Auditoren erwarten einen Scope, der zur Grenze Ihres Produktivsystems passt, und den Nachweis, dass Findings verfolgt und behoben wurden, nicht eine hübsche Zusammenfassungsseite.
• Jährliches Testen ist der akzeptierte Standard, ergänzt um einen Retest nach wesentlichen Änderungen und nach der Behebung von hohen und kritischen Findings.
• Ein Schwachstellenscan ist kein Penetrationstest, und das eine als das andere auszugeben ist der häufigste Grund, warum Nachweise abgelehnt werden.

Was SOC 2 wirklich verlangt

SOC 2 baut auf den AICPA Trust Services Criteria auf. Die Kategorie Security, die Common Criteria, ist in jedem SOC-2-Bericht verpflichtend. Die Kriterien, die das Testen betreffen, finden sich in den Bereichen Risikobewertung und Systembetrieb.

CC7.1 sollten Sie sich merken. Es erwartet, dass Sie Erkennungs- und Überwachungsverfahren betreiben, die Konfigurationsänderungen mit neuen Schwachstellen sowie die Anfälligkeit für neu entdeckte Schwachstellen aufspüren. Ein Penetrationstest ist ein direkter, gut begründbarer Weg, um zu zeigen, dass Sie genau das gegen Ihre eigene Angriffsfläche tun, statt einfach anzunehmen, dass Ihre Abwehr hält. CC3.2 deckt das Erkennen und Analysieren von Risiken ab. CC4.1 deckt die laufende Bewertung ab, ob Kontrollen funktionieren. Ein gut aufgebauter Pentest-Bericht bedient alle drei auf einmal. Deshalb bekommen Prüfer einen solchen gern.

Und hier ist der Punkt, bei dem SOC 2 wirklich pingelig ist: die Wirksamkeit über die Zeit. In einem Type-II-Bericht, der einen Prüfzeitraum statt eines einzelnen Stichtags abdeckt, genügt es nicht zu sagen, dass eine Kontrolle existiert. Sie müssen zeigen, dass sie über das gesamte Zeitfenster ihre Aufgabe erfüllt hat. Ein Test, der echte Probleme zutage fördert, zusammen mit einer dokumentierten Behebung, die sie schließt, erzählt diese Geschichte weit besser, als es ein Richtlinien-PDF je könnte.

Wie sich ein Pentest den Common Criteria zuordnen lässt

Der wiederkehrende Fehler besteht darin, den Pentest als eigenständiges Artefakt zu behandeln, statt ihn mit konkreten Kriterien zu verknüpfen. Auditoren denken in Kontroll-Mappings. Also liefern Sie ihnen das Mapping.

Konkret: Der Abschnitt zu Scope und Methodik unterstützt CC3.2, das Erkennen und Analysieren von Risiken. Die Findings selbst sind Nachweise für CC7.1, die Erkennung von Schwachstellen. Die Behebungs- und Retest-Aktivität unterstützt CC7.4, das Reagieren auf und Beheben von erkannten Sicherheitsproblemen. Strukturieren Sie den Bericht so, dass ein Prüfer auf ein Finding zeigen kann, dann auf das Ticket, das es behoben hat, dann auf den Retest, der die Behebung bestätigt hat, und schon haben Sie das abgedeckt, woran die meisten Unternehmen scheitern: nachzuweisen, dass die Kontrolle gewirkt hat, und nicht nur, dass sie auf dem Papier existierte.

Der Bericht, den ein Auditor liebt, ist langweilig im besten Sinne. Klarer Scope, echte Findings, nachverfolgte Behebung, bestätigter Retest. Kein Drama, volle Nachvollziehbarkeit.

Welchen Scope sollte ein SOC-2-Pentest abdecken?

Der Scope sollte die Systemgrenze widerspiegeln, die in Ihrem SOC-2-Bericht beschrieben ist. In der Praxis heißt das: Ihre Produktivanwendung und die Infrastruktur dahinter. Wenn Ihre SaaS-Plattform, deren API und die tragende Cloud-Umgebung im Bericht genannt werden, gehören sie in den Test. Ein Pentest, der ausgerechnet das ausklammert, worin sich Ihre Kunden jeden Tag einloggen, ist ein Warnsignal, und ein erfahrener Prüfer erkennt das.

Für die meisten SaaS-Unternehmen auf dem Weg zu SOC 2 zerfällt das in eine Handvoll konkreter Arbeitspakete. Ein Test der Webanwendung über die authentifizierte wie die nicht authentifizierte Oberfläche, denn Broken Access Control und Autorisierungsfehler sind das, was wir bei diesen Engagements am häufigsten melden. Ein API-Test, da sich heute so viel der echten Angriffsfläche in undokumentierten oder unzureichend getesteten Endpunkten verbirgt. Und, wo es zutrifft, ein externer Netzwerktest der im Scope liegenden, aus dem Internet erreichbaren Dienste.

Wir legen die Grenze schriftlich fest, bevor auch nur eine einzige Anfrage rausgeht. Die mit Abstand häufigste Ursache für einen späteren Streit über Nachweise ist eine unscharfe Scope-Beschreibung, bei der niemand sagen kann, ob eine Komponente drin oder draußen war. Legen Sie es fest. Listen Sie die im Scope liegenden Hosts und Anwendungen auf. Vermerken Sie jede Ausklammerung und den jeweiligen Grund dafür.

Wie wir ihn durchführen, und was im Bericht auftaucht

Ein auf SOC 2 ausgerichteter Test läuft trotzdem wie ein echter Pentest ab, nicht wie ein Compliance-Ritual. Wir arbeiten nach etablierter Methodik, den OWASP-Testleitfäden für Web und API sowie einer standardisierten Netzwerkmethodik für Infrastruktur, kombinieren automatisierte Werkzeuge mit manueller Verifikation und bestätigen jedes Finding von Hand. Burp Suite für die interaktive Arbeit, ffuf für die Content- und Parameter-Discovery, nuclei, um bekannte Probleme in großem Umfang abzugrasen. Die sorgen für Abdeckung. Die kritischen Findings kommen fast immer aus der manuellen Ebene: das Verketten einer Autorisierungslücke bis hinein in die Daten eines anderen Mandanten, oder das Verwandeln eines gesprächigen Stacktraces in ein Informationsleck, das den nächsten Schritt füttert.

Genau diese manuelle Arbeit ist es, worauf SOC 2 abzielt. Ein Auditor will wissen, ob Ihre Kontrollen gegen einen motivierten Angreifer standhalten. Ein Scanner, der eine schwache TLS-Cipher markiert, beantwortet das nicht. Ein Tester, der zeigt, dass ein Konto mit niedrigen Rechten eine reine Admin-Funktion erreichen kann, schon.

Nehmen wir an, ein Testkonto ist auf die Account-ID 1042 beschränkt, und wir zählen den Objektbezeichner von Hand durch:

$ curl -s https://app.acme-corp.example.com/api/v2/accounts/1043/invoices \
    -H "Authorization: Bearer <low-priv-user-token>"

{"account_id":1043,"invoices":[ ... another tenant's billing data ... ]}

Eine solche Insecure Direct Object Reference, CWE-639, liest sich für einen Auditor weit überzeugender als eine Seite voller Scanner-Ausgaben. Sie zeigt, dass eine Kontrolle, die hätte existieren müssen, schlicht nicht vorhanden war.

Der Bericht braucht ein paar konkrete Dinge, um die Audit-Prüfung zu überstehen. Eine klare Angabe zu Scope und Systemgrenze. Eine Beschreibung der Methodik. Nach Schweregrad bewertete Findings, mit genug technischem Detail, um sie zu reproduzieren und zu belegen, dass sie real sind und nicht theoretisch. Behebungsempfehlungen je Finding. Testdaten, die innerhalb des Prüfzeitraums oder sinnvoll davor liegen. Und, im Idealfall, eine Retest-Bestätigung, die belegt, dass die hohen und kritischen Punkte geschlossen wurden. Genau dieses letzte Stück verwandelt “wir haben Probleme gefunden” in “unsere Kontrolle hat gewirkt und wir haben die Lücke geschlossen”. Dieser Satz ist die gesamte SOC-2-Erzählung.

Wie oft müssen Sie für SOC 2 testen?

Jährlich ist der akzeptierte Standard, und das ist es, was die meisten Auditoren für einen wiederkehrenden Type-II-Bericht erwarten. Über den Jahresrhythmus hinaus: testen Sie nach jeder wesentlichen Änderung am im Scope liegenden System erneut, und testen Sie erneut, um die Behebung hoher und kritischer Findings zu bestätigen. Bringen Sie mitten im Jahr größere Funktionalität heraus, und ein Test von vor dieser Freigabe wird zu einem schwächeren Nachweis für den aktuellen Zeitraum. Ein scharfsichtiger Prüfer wird die Diskrepanz bemängeln.

Bei einem erstmaligen SOC 2 testen Sie während der Readiness-Phase, bevor das Beobachtungsfenster beginnt. So gewinnen Sie Zeit, um Findings zu beheben und eine saubere Behebungsdokumentation aufzubauen, statt kritische Punkte in Hektik zu schließen, während der Auditor schon zusieht.

Wie CyberXplore hilft

Wir führen SOC-2-Penetrationstests durch, die direkt zu Ihrem Auditor gehen können. Ein auf Ihre Systemgrenze abgestimmter Scope, manuell geführtes Testen, das aufspürt, was Scanner übersehen, Findings, die den passenden Common Criteria zugeordnet sind, und ein Retest, der den Kreis bei hohen und kritischen Punkten schließt. Wenn Sie sich auf einen Type I oder Type II vorbereiten, übernimmt unser SOC-2-Readiness-Service das Testen und das Aufbereiten der Nachweise zusammen, damit Sie nicht selbst einen rohen Pentest-Bericht in Audit-Sprache übersetzen müssen. Wenn Sie so weit sind, den Scope festzulegen, fordern Sie ein Angebot an, und wir richten das Engagement an Ihrer Berichtsgrenze und Ihrem Audit-Zeitplan aus.

FAQ

Verlangt SOC 2 einen Penetrationstest?

Nicht namentlich. SOC 2 verlangt, dass Sie auf Schwachstellen überwachen und nachweisen, dass Ihre Kontrollen wirksam arbeiten, vor allem über die Common Criteria wie CC7.1. Ein Penetrationstest ist der direkteste und breit akzeptierte Weg, diesen Nachweis zu erzeugen, weshalb sich die meisten SOC-2-Berichte auf einen stützen, auch wenn der Standard genau diese Formulierung nie verwendet.

Reicht ein Schwachstellenscan für SOC 2?

Nein, und das ist der häufigste Grund, warum Nachweise zurückgewiesen werden. Ein Scan listet bekannte Probleme aus einer Signaturdatenbank auf. Ein Penetrationstest ergänzt manuelles Testen, Exploitation und eine Analyse der Geschäftslogik, die ein Scanner nicht leisten kann. Auditoren kennen den Unterschied zunehmend und fragen nach, ob manuelles Testen Teil der Arbeit war.

Wie oft sollten wir einen SOC-2-Penetrationstest durchführen?

Jährlich ist der Standard, ergänzt um einen Retest nach wesentlichen Systemänderungen und nach der Behebung hoher oder kritischer Findings. Für ein erstes Audit testen Sie während der Readiness-Phase, damit Sie Zeit haben, Probleme zu beheben, bevor das Beobachtungsfenster beginnt.

Was sollte der Pentest-Bericht für den Auditor enthalten?

Einen definierten Scope und eine Systemgrenze, eine Beschreibung der Methodik, nach Schweregrad bewertete Findings mit Reproduktionsdetails, Behebungsempfehlungen, Testdaten innerhalb oder vor dem Prüfzeitraum und im Idealfall eine Retest-Bestätigung. Der Behebungs- und Retest-Nachweis ist das, was belegt, dass die Kontrolle tatsächlich gewirkt hat, und das ist der Kern eines Type-II-Berichts.

Wer legt den Scope fest, wir oder der Auditor?

Sie und Ihr Testpartner legen ihn fest, aber er muss zur Systemgrenze in Ihrem SOC-2-Bericht passen. Wenn das Audit Ihre Produktivanwendung, die API und die tragende Infrastruktur abdeckt, sollte der Test dasselbe abdecken. Einen schmaleren Ausschnitt zu testen als der Bericht beschreibt, ist die klassische Scope-Diskrepanz, die später zu Streit führt.