Kriterien · Nachweise · Preis

SOC-2-Penetrationstest-Kosten

SOC 2 enthält keine Kontrolle, die "führe einen Penetrationstest durch" sagt. Auditoren erwarten trotzdem einen, und die meisten Readiness-Anbieter bestehen darauf. Zu verstehen warum, erklärt, was der Test liefern muss - und damit, was Sie tatsächlich kaufen sollten.

Warum ein Framework, das Tests nie erwähnt, sie trotzdem verlangt

SOC 2 beruht auf den Trust Services Criteria, die als Ergebnisse formuliert sind und nicht als Checkliste von Tätigkeiten. Es gibt keine Kontrolle mit der Nummer "Penetrationstest". Das verleitet zu einem von zwei Fehlern: anzunehmen, es brauche keinen Test, oder einen großen zu kaufen, weil ein Readiness-Anbieter das gesagt hat.

Nützlicher ist die Sichtweise, dass ein Penetrationstest ein Nachweis ist und keine Anforderung. Er ist für die meisten Organisationen der praktikabelste Weg, zwei Dinge zu belegen:

  • CC4.1 - dass Sie Bewertungen durchführen, um festzustellen, ob Ihre Kontrollen tatsächlich vorhanden sind und funktionieren. Ein unabhängiger Test ist eine direkte, datierte, extern erstellte Bewertung, also genau das, worauf dieses Kriterium zielt.
  • CC7.1 - dass Sie Schwachstellen und unautorisierte Konfigurationsänderungen erkennen. Scanning deckt einen Teil davon fortlaufend ab; ein Test deckt den Teil ab, den Scanning nicht erreicht.

Weil es eine Nachweisfrage und kein Compliance-Häkchen ist, zählt die Einschätzung Ihres Auditors. Fragen Sie konkret und schriftlich, was akzeptiert wird, bevor Sie etwas scopen. Auditoren unterscheiden sich, und dieser Unterschied ist manchmal mehrere Tausend Dollar an Scope wert.

Wie die Nachweise aussehen müssen

Ein Bericht allein ist der häufigste Weg, auf dem diese Kontrolle trotzdem beanstandet wird. Die vollständige Nachweiskette hat vier Teile, und die Lücken liegen fast immer in den letzten beiden.

  • Scope. Der getestete Scope muss erkennbar das System sein, das Ihr SOC-2-Bericht beschreibt. Beschreibt Ihre Systembeschreibung eine mandantenfähige SaaS-Plattform und der Test deckte eine unauthentifizierte Marketing-Seite ab, fällt die Diskrepanz sofort auf.
  • Befunde. Nach Schwere bewertet, mit begründeter Einstufung statt einer unerklärten Farbe, und mit Reproduktionsschritten.
  • Behebung. Dokumentiert, mit Daten, und mit festgehaltener Entscheidung für alles, was akzeptiert statt behoben wurde. Risikoakzeptanz ist zulässig; Schweigen nicht.
  • Verifikation. Nachweis, dass Korrekturen nachgetestet und bestätigt wurden. Dieser Teil fehlt am häufigsten, und er ist der Teil, der aus einem Bericht einen Beleg für eine funktionierende Kontrolle macht.

Ein Attestierungsschreiben, das benennt, was wann von wem mit welchem Ergebnis getestet wurde, verbindet das für den Auditor - und es ist das, wonach Ihre Kunden später fragen. Es sollte Teil des Auftrags sein und kein separater Kauf.

Timing gegenüber Ihrem Beobachtungsfenster

Für Typ I, der die Gestaltung zu einem Stichtag bewertet, genügen meist ein aktueller Test und ein glaubwürdiger Behebungsplan. Für Typ II, der die Wirksamkeit über typischerweise drei bis zwölf Monate bewertet, müssen Test, Behebung und Nachtest in dieses Fenster fallen. Einen Test drei Wochen vor Fensterschluss zu buchen lässt keinen Raum für den Zyklus aus Beheben und Nachtesten und ist der häufigste Planungsfehler.

Rückwärts gerechnet: drei bis fünf Arbeitstage Testen für eine kleine Anwendung, ein bis drei Wochen für Ihre Entwickler zur Behebung des Wesentlichen und einige Tage für den Nachtest. Ein Monat innerhalb des Fensters ist komfortabel. Eine Woche nicht.

Für SOC 2 scopen, ohne zu viel zu kaufen

Der Scope sollte das System Ihrer Systembeschreibung sein, bei den meisten SaaS-Unternehmen also das Produkt und die Infrastruktur, auf der es läuft. Praktisch heißt das: die authentifizierte Anwendung mit allen Benutzerrollen, die Grenze zwischen Kundenmandanten, die API und die Cloud-Umgebung, die das Ganze hostet.

Was häufig in den SOC-2-Scope verkauft wird und selten hineingehört: Ihre Laptop-Flotte, wenn sie außerhalb der Systembeschreibung liegt; eine vollständige Active-Directory-Bewertung, wenn Sie keine Unternehmensdomäne haben; und ein Red-Team-Einsatz, der eine ganz andere Frage beantwortet als die, die CC4.1 stellt. Hat ein Readiness-Anbieter Ihnen all das angeboten, fragen Sie, welches Kriterium jeder einzelne Punkt belegt.

Was es kostet

SOC 2 ändert nicht die Kosten des Testens, nur die Dokumentation, die Sie daraus brauchen. Für ein typisches SaaS-Produkt beginnt ein Anwendungs-Scope bei 500 $ und deckt das authentifizierte Produkt, Rollen, Mandantentrennung und die API ab. Sobald Cloud-Infrastruktur oder ein Unternehmensnetzwerk wirklich innerhalb der Systembeschreibung liegt, wird daraus ein Infrastruktur-Scope ab 1.500 $.

Remediation-Unterstützung, Nachtest und Attestierungsschreiben sind enthalten statt separat berechnet, was hier mehr zählt als bei den meisten Aufträgen - denn genau diese Artefakte wird der Auditor verlangen. Die Serviceseite zu SOC-2-Penetrationstests behandelt das Testen selbst ausführlicher, Penetrationstest-Kosten erklärt das allgemeine Modell, und der Musterbericht zeigt das Format, das ein Auditor erhält.

Unterliegen Sie zusätzlich PCI DSS, lassen sich beide häufig in einem Auftrag abdecken, auch wenn die Nachweisanforderungen abweichen. Siehe PCI-DSS-Penetrationstest-Kosten oder compliance-getriebenes Testen zur Behandlung überlappender Frameworks.

Fragen zu SOC-2-Tests

Nicht namentlich. Die Trust Services Criteria sind bewusst als Ergebnisse und nicht als vorgeschriebene Tätigkeiten formuliert, und kein Kriterium enthält die Worte "Penetrationstest". In der Praxis ist ein Test der übliche Weg, CC4.1 nachzuweisen, das Bewertungen dazu verlangt, ob Kontrollen funktionieren, und er stützt CC7.1 zur Erkennung von Schwachstellen und Konfigurationsänderungen. Was genügt, entscheidet Ihr Auditor, also kommt die definitive Antwort von dort. Fragen Sie früh, denn die Antwort bestimmt Scope und Zeitplan.
Es ändert eher das Timing als den Test. Typ I prüft, ob Kontrollen zu einem Stichtag angemessen gestaltet sind, daher genügen meist ein aktueller Test und ein Behebungsplan. Typ II prüft die Wirksamkeit über einen Zeitraum von typischerweise drei bis zwölf Monaten, daher will der Auditor Test, Behebung und Nachtest innerhalb dieses Beobachtungsfensters sehen. Einen Test zu spät im Typ-II-Fenster anzusetzen ist ein verbreiteter und teurer Fehler.
Meist vier Dinge: einen definierten Scope, der plausibel das System Ihrer SOC-2-Beschreibung abdeckt, Befunde mit Schwere und begründeter Bewertung, dokumentierte Behebung mit Daten und Nachweise, dass die Korrekturen überprüft wurden. Ein Attestierungsschreiben mit Angabe von Scope und Zeitpunkt verbindet das Ganze. Ein Bericht allein, ohne Behebungsspur, ist der häufigste Grund, warum diese Kontrolle beanstandet wird.
Das Framework verändert nicht die Kosten des Testens, sondern nur die benötigten Nachweise. Für ein typisches SaaS-Produkt heißt das ein Anwendungs-Scope ab 500 $ oder ab 1.500 $, sobald Cloud-Infrastruktur oder ein Unternehmensnetzwerk wirklich im Scope liegt. Anbieter, die ein eigenes "SOC-2-Pentest"-Produkt vermarkten, verkaufen meist denselben Test mit anders verpackter Dokumentation.
Jährliches Testen ist die übliche Grundlinie, die Auditoren akzeptieren, zuzüglich eines Tests nach wesentlichen Architekturänderungen. Weil Typ II einen Zeitraum statt eines Stichtags betrachtet, lautet die praktische Anforderung, dass innerhalb jedes Beobachtungsfensters Nachweise über Test und Behebung existieren - nicht, dass ein Test an einem bestimmten Datum stattfindet.

Test für ein SOC-2-Fenster zu scopen?

Bringen Sie die Anforderung Ihres Auditors und Ihr Beobachtungsfenster mit, und ich scope vom Datum rückwärts.

Kontakt