# OPS-22 Umgang mit Schwachstellen, Vorfällen und Abstürzen - Penetrationstests - Bereich: OPS – Regelbetrieb - Gegenüber C5:2020: geändert (vorher OPS-19) - Webseite: https://c5.patrickscheid.de/ops-22/ **Ergänzende Information:** Siehe Abschnitt „1.2 Definitionen“ für die Begriffe „Penetrationstest“ und „wesentliche Änderung“. Im Gegensatz zu Schwachstellenscans, die Code analysieren, zielen Penetrationstests im Sinne dieses Kriteriums hauptsächlich darauf ab, das Live-System zu untersuchen, um reale Schwachstellen oder Schwächen aufzudecken, die sich nur im tatsächlichen Betrieb des Cloud-Dienstes zeigen, und stellen so den Bezug zum Kriterium OPS-18 her. Es gibt drei Arten von Penetrationstests: 1. Black-Box-Tests: Tests, die ohne vorherige Kenntnis der internen Struktur/des Designs/der Implementierung des zu testenden Objekts durchgeführt werden; 2. Grey-Box-Tests: Tests, die mit teilweiser Kenntnis der internen Struktur/des Designs/der Implementierung des zu testenden Objekts durchgeführt werden; und 3. White-Box-Tests: Tests werden mit Kenntnis der internen Struktur/des Designs/der Implementierung des zu testenden Objekts durchgeführt. Es kann weiter unterschieden werden zwischen 1. Pre-Launch-Penetrationstests: Tests, die bereits im Rahmen des Softwareentwicklungsprozesses während der Testphase des Cloud-Dienstes durchgeführt werden (vgl. DEV-07); und 2. Post-Launch-Penetrationstests: Tests, die während des regulären Betriebs des Cloud-Dienstes durchgeführt werden. Zu den wesentlichen Änderungen können unter anderem die folgenden Ereignisse gehören: 1. Ersetzen zentraler Cloud-Infrastrukturtechnologien oder Durchführen größerer Versions-Upgrades; 2. Wechsel zwischen Service-Organisationen, z. B. Wechsel zu einem neuen IaaS- oder Rechenzentrumsanbieter; 3. Wesentliche Änderungen in der Art und Weise, wie Cloud-Kundendaten verarbeitet und aufbewahrt werden, wie z. B. neue Datensicherungstechniken oder neue Regionen, von denen aus der Dienst betrieben wird; 4. Ersetzen oder Durchführen größerer Upgrades von Sicherheitstechnologien wie Authentisierungsworkflows, Netzsicherheitsmechanismen oder Überwachungsmechanismen; und 5. Wesentliche Änderungen am Cloud-Servicemodell oder an der Funktionalität, die dem Cloud-Kunden zur Verfügung gestellt wird. ## Basiskriterium ### OPS-22.01B Der Cloud-Anbieter führt mindestens jährlich und bei wesentlichen Änderungen am Cloud-Dienst gemäß den Richtlinien zum Schwachstellenmanagement (vgl. OPS-18) Penetrationstests durch qualifiziertes internes Personal oder externe Penetrationstester durch. **Ergänzende Information (zu 01B, 01AS):** Die Qualifikation und Kompetenz des Personals für Penetrationstests kann anhand professioneller Zertifizierungen, z.B. als BSI-zertifizierter IS-Penetrationstester oder CREST-zertifizierter Cyber Security Professional, nachgewiesen werden. ### OPS-22.02B Penetrationstests werden gemäß eines dokumentierten Rahmenwerks für Penetrationstests durchgeführt, das die Anzahl und Art der durchzuführenden Penetrationstests sowie die Anforderungen an die Qualifikation und Kompetenz des Personals zur Durchführung solcher Tests umreißt. Die Anzahl und Art der durchzuführenden Penetrationstests werden auf Basis einer Risikobeurteilung festgelegt (vgl. OIS-07). **Ergänzende Information (zu 02B, 02AS):** Wie viele Penetrationstests innerhalb eines Jahres durchgeführt werden sollten, hängt von Faktoren wie der Größe und Komplexität des bereitgestellten Cloud-Dienstes ab. Wenn Penetrationstests mehrjährigen Testplänen folgen, sollten diese bei der Festlegung der Anzahl und Art der innerhalb eines Jahres durchzuführenden Penetrationstests berücksichtigt werden. ### OPS-22.03B Penetrationstests zielen auf die für die Bereitstellung des Cloud-Dienstes relevanten Systemkomponenten im Verantwortungsbereich des Cloud-Anbieters ab. In einer Risikobeurteilung werden die anzugreifenden Systemkomponenten identifiziert. **Ergänzende Information (zu 03B, 03AS):** Mithilfe der Risikobeurteilung sollen die Systemkomponenten identifiziert werden, die für die Bereitstellung des Cloud-Dienstes am kritischsten bzw. für Penetrationstests am relevantesten sind. **Ergänzende Information (zu 03B, 05B):** Für die Bereitstellung des Cloud-Dienstes relevante Systemkomponenten im Verantwortungsbereich des Cloud-Anbieters können solche Systemkomponenten sein, die am externen Perimeter des Netzes exponiert sind, oder Komponenten, die nur von innerhalb des Netzes zugänglich sind. ### OPS-22.04B Penetrationstests werden in Übereinstimmung mit Testplänen durchgeführt, die alle relevanten Systemkomponenten abdecken und festlegen, welche Systemkomponenten getestet werden sollen. ### OPS-22.05B Erfolgen Penetrationstests in Übereinstimmung mit mehrjährigen Testplänen, wird jede relevante Systemkomponente innerhalb eines Zeitraums von maximal drei Jahren mindestens einem Penetrationstest unterzogen. ### OPS-22.06B Der Cloud-Anbieter beurteilt den Schweregrad der identifizierten Schwachstellen nach dem Common Vulnerability Scoring System (CVSS) in der zum Zeitpunkt der Beurteilung aktuellen Fassung. ### OPS-22.07B Maßnahmen zur Behebung oder Mitigation werden in Übereinstimmung mit den Zeitrahmen ergriffen, die in den Richtlinien für den Umgang mit Schwachstellen definiert sind (vgl. OPS-18). ### OPS-22.08B Die durch Penetrationstests entdeckten Schwachstellen werden einer Ursachenanalyse unterzogen. Die Ursachenanalyse ermöglicht eine Einschätzung, inwieweit ähnliche Schwachstellen im Cloud-Dienst vorhanden sein können. ## Zusatzkriterium ### OPS-22.01AS (Zusatz, verschärft 01B) Der Cloud-Anbieter führt mindestens alle sechs Monate und bei wesentlichen Änderungen am Cloud-Dienst gemäß den Richtlinien zum Schwachstellenmanagement (vgl. OPS-18) Penetrationstests durch unabhängige externe Penetrationstester durch. Der Einsatz externer Penetrationstester erfolgt nur dann, wenn das für die Durchführung des Tests vorgesehene Personal nachweislich die Qualifikations- und Kompetenzanforderungen des Cloud-Anbieters erfüllt. Internes Personal für Penetrationstests kann das externe Personal unterstützen. ### OPS-22.02AS (Zusatz, verschärft 02B) Pre-Launch- und Post-Launch-Penetrationstests werden gemäß eines dokumentierten Rahmenwerks für Penetrationstests durchgeführt, der die Anzahl und Art der durchzuführenden Penetrationstests sowie die Anforderungen an die Qualifikation und Kompetenz des Personals zur Durchführung solcher Tests umreißt. Die Anzahl und Art der durchzuführenden Penetrationstests werden auf Basis einer Risikobeurteilung festgelegt (vgl. OIS-07). ### OPS-22.03AS (Zusatz, verschärft 03B) Penetrationstests zielen auf für die Bereitstellung des Cloud-Dienstes relevante Systemkomponenten im Verantwortungsbereich des Cloud-Anbieters ab. In einer Risikobeurteilung, gegebenenfalls unter Einbeziehung einer Bedrohungsmodellierung, werden die anzugreifenden Systemkomponenten identifiziert. ### OPS-22.01AC (Zusatz, erweiternd) Penetrationstests werden auf der Grundlage von Überprüfungen der Architektur und Konfiguration der Systemkomponenten sowie des Quellcodes des Cloud-Anbieters durchgeführt. ### OPS-22.02AC (Zusatz, erweiternd) Der Cloud-Anbieter entwirft einen mehrjährigen Testplan für seine Penetrationstestaktivitäten. ### OPS-22.03AC (Zusatz, erweiternd) Der Cloud-Anbieter überprüft die Wirksamkeit von Penetrationstests an Systemkomponenten mindestens jährlich und bei wesentlichen Änderungen am Cloud-Dienst. ### OPS-22.04AC (Zusatz, erweiternd) Der Cloud-Anbieter verwendet den Bedrohungsmodellierungsprozess, um Systemkomponenten mit der höchsten Risikoexposition für Penetrationstests zu priorisieren, indem er Cloud-Komponenten, Dienste, Datenflüsse, Trust Boundaries und für den Cloud-Dienst kritische Assets systematisch analysiert, um potenzielle Bedrohungen, Schwachstellen und Angriffsvektoren aufzulisten. **Ergänzende Information:** Dieses Unterkriterium ist nur anwendbar, wenn auch das Unterkriterium OPS-22.03AS angewendet wird. Das risikobasierte Scoping stellt sicher, dass sich Penetrationstests auf die Bereiche konzentrieren, die am anfälligsten für Sicherheitsbedrohungen sind, verbessert die geschäftliche Ausrichtung und Zusammenarbeit und liefert klare technische Erkenntnisse darüber, welche Komponenten Tests erfordern, die über die standardmäßige Risikobeurteilung hinausgehen. Für den Bedrohungsmodellierungsprozess können ein strukturierter Bedrohungsmodellierungsansatz wie STRIDE, DREAD, PASTA oder hybride Methoden verwendet werden, die auf Cloud-Umgebungen zugeschnitten sind. ### OPS-22.05AC (Zusatz, erweiternd) Der Cloud-Anbieter korreliert die möglichen Ausnutzungen entdeckter Schwachstellen mit früheren Informationssicherheitsvorfällen, um festzustellen, ob die Schwachstelle möglicherweise bereits vor ihrer Entdeckung ausgenutzt wurde. ## Änderungen gegenüber C5:2020 Aus der BSI C5:2026 Änderungshistorie, die das BSI bisher nur auf Englisch veröffentlicht. **Basiskriterium:** Modified requirement regarding the frequency of performed penetration tests to include in case of significant changes as well. Modified requirement regarding the documented penetration concept to also define the number and types of tests to be performed. Added requirements regarding the selection of system components to be tested and the implementation of (multi-year) test plans. Supplement requirements regarding the severity assessment with reference to CVSS. Linked this criterion to the policy for managing vulnerabilities. Added requirement for performing root cause analyses on found vulnerabilities. **Zusatzkriterium:** Sharpened the basic criterion by further requiring the engagement of external penetraion testers, test plans to include pre-launch and post-launch penetration tests, and the selection og system components to be tested to include threat modelling. Added requirement regarding the use of architecture and configuration reviews for performing penetration tests. Added requirement regarding the review of the penetration test's effectiveness. Further qualified the use of threat modelling for prioritising system components to test. Added requirement regarding the correlation of possible exploits and identified vulnerabilities with past incidents. --- Quelle: BSI C5:2026, maschinenlesbare Fassung v1.1.0, © Bundesamt für Sicherheit in der Informationstechnik (BSI) 2026, unverändert wiedergegeben unter CC BY-ND 4.0 (https://creativecommons.org/licenses/by-nd/4.0/deed.de). Änderungshinweise: BSI C5:2026 Änderungshistorie, © BSI 2026, CC BY-ND 4.0. Inoffizielle Darstellung, ohne Verbindung zum BSI.