ISO 27001 zertifiziert und trotzdem angreifbar? Was ein Penetration Test wirklich findet

Welche Lücken in Schweizer Netzen immer wieder auftauchen, und welchen Teil des Anhang A ein Penetration Test belegt.

Der Realitätscheck: ein Penetration Test in der Praxis

Bei einem Schweizer Unternehmen lag die letzte Passwortänderung eines noch aktiven Domain-Admin-Kontos über zwei Jahrzehnte zurück. So lange öffnete dasselbe Passwort die gesamte Windows-Domäne.

Solche Lücken stehen in keiner Richtlinie und in keinem Zertifikat. Man findet sie nur, wenn jemand das Netzwerk so angreift, wie es ein echter Angreifer täte.

Genau das leistet ein Penetration Test. Ein Penetration Test ist ein kontrollierter, autorisierter Angriff auf ein Netzwerk oder eine Applikation. Anders als ein automatisierter Scan verkettet er einzelne Schwächen von Hand zu realen Angriffspfaden.

Das Wichtigste in Kürze

Eine ISO-27001-Zertifizierung belegt ein Managementsystem, nicht die technische Belastbarkeit Ihres Netzes.
In Schweizer Netzen sind es immer wieder dieselben Lücken, und sie liegen fast alle im selben Teil des Anhang A: bei den technologischen Massnahmen.
Umgekehrt gilt genauso: Ein Penetration Test belegt nur diesen einen Teil. Über organisatorische, personenbezogene und physische Massnahmen sagt er nichts.
Für die meisten Unternehmen passt ein jährlicher Grey-Box-Pentest, plus Tests nach jeder grösseren Änderung.
Die Schweizer Regulierung (revDSG, für Finanzdienstleister die FINMA) verlangt zusätzlich technischen Nachweis.

Dieser Artikel zeigt aus der Praxis, was eine ISO-27001-Zertifizierung beweist und was nicht, welche typischen Schwachstellen ein Penetration Test in Schweizer Netzen findet, welchen Teil des Anhang A er damit belegt, welcher Test-Typ und welches Intervall passen und was die Schweizer Regulierung zusätzlich verlangt.

Was eine ISO-27001-Zertifizierung beweist, und was nicht

Eine ISO-27001-Zertifizierung belegt ein funktionierendes Informationssicherheits-Managementsystem. Sie zeigt, dass Sicherheit in Ihrem Unternehmen organisiert und gesteuert ist: Verantwortlichkeiten sind geklärt, Risiken bewertet, Massnahmen festgelegt und überprüft.

Was das Zertifikat nicht beweist: dass Ihre Technik einem realen Angriff standhält. Ein Managementsystem ist ein Nachweis auf der Steuerungsebene, kein Nachweis technischer Belastbarkeit. Beides hängt zusammen, ist aber nicht dasselbe.

Deshalb erwartet die Norm faktisch einen technischen Schwachstellen-Nachweis. Der Anhang A, der normative Massnahmen-Katalog der ISO 27001, verlangt unter den technologischen Massnahmen einen geregelten Umgang mit technischen Schwachstellen. Den Begriff „Penetration Test“ schreibt die Norm nirgends vor, die Funktion erwartet sie aber. Der Test ist der pragmatische Weg, diesen Nachweis zu erbringen.

Ehrlich gesagt testen unsere Kunden selten allein wegen des Audits. Sie testen, weil sie wissen wollen, ob ihre Technik einem echten Angriff standhält.

Dieser Wert hängt nicht an einem Zertifikat. Ein Penetration Test lohnt sich unabhängig von Grösse, Branche und ISO-Status: Wer digital arbeitet, hat eine Angriffsfläche, und die will man kennen, bevor es ein anderer tut. ISO 27001 ist in diesem Artikel der rote Faden, weil die Norm den technischen Nachweis strukturiert einfordert. Die Logik dahinter gilt aber genauso für Unternehmen, die nie ein Audit anstreben.

Was ein Penetration Test in Schweizer Netzen immer wieder findet

Über unsere Tests hinweg sind es dieselben Muster. Zero-Days findet man selten. Meistens sind es Konfigurations- und Hygiene-Lücken, die organisatorisch längst abgehakt schienen.

Die wiederkehrende Handvoll:

Standard- und Default-Zugangsdaten, die nie geändert wurden, etwa auf Konsolen, USV-Anlagen, Druckern oder Monitoring-Systemen.
Klartextpasswörter, die in Skripten und Konfigurationsdateien liegen.
Fehlkonfigurierte Active-Directory-Zertifikatsvorlagen, über die sich Rechte ausweiten lassen.
Ungenügend geschützte privilegierte Administrationskonten: keine Rotation, keine saubere Trennung, teils Passwörter, die seit über zwei Jahrzehnten unverändert sind.
Passwörter, die in Gruppenrichtlinien hinterlegt sind.
Veraltete, ungepatchte Systeme.
Fehlende Netzwerksegmentierung, sodass nach einem Einstieg alles offensteht.

Das Domain-Admin-Konto vom Anfang ist kein Einzelfall, sondern ein Sinnbild. Ein Unternehmen kann seine Prozesse auf dem Papier im Griff haben und im Netz trotzdem weit offen sein.

Wir nennen hier bewusst keine Fallzahl. Die reine Anzahl Befunde sagt für sich genommen wenig, sie hängt komplett an Umfang und Tiefe des jeweiligen Tests. Aussagekräftig ist etwas anderes: dass es immer wieder dieselben Lücken sind.

Was ein Penetration Test im Anhang A belegt, und was nicht

Hier lohnt sich der genaue Blick, denn er entscheidet, wofür Sie den Test überhaupt als Nachweis heranziehen können.

Der Anhang A der ISO/IEC 27001 fasst die Massnahmen in vier Themen zusammen: organisatorische, personenbezogene, physische und technologische. Ein Penetration Test liefert Evidenz zu genau einem davon.

Thema im Anhang A	Was ein Penetration Test dazu belegt
Organisatorische Massnahmen	Nichts unmittelbar. Ob Richtlinien existieren und gesteuert werden, zeigt das Audit. Der Test zeigt nur, ob sie im Netz angekommen sind.
Personenbezogene Massnahmen	Nichts. Schulung, Sensibilisierung und Verantwortlichkeiten liegen ausserhalb unseres Scopes.
Physische Massnahmen	Nichts. Zutritt, Verkabelung und Standortsicherheit sind nicht Teil eines Netzwerk- oder Web-Pentests.
Technologische Massnahmen	Hier liegt die Evidenz, und auch hier nur für den Teil, der sich aktiv angreifen lässt.

Daraus folgen zwei Dinge, und zwar in beide Richtungen.

Erstens: Ein Zertifikat ersetzt den Test nicht. Die organisatorische Ebene kann vollständig sein, während die technologische im Netz nicht hält. Genau diese Differenz misst der Penetration Test.

Zweitens, und das wird selten erwähnt: Ein Test ersetzt das Managementsystem nicht. Drei der vier Themen berührt er gar nicht. Wer einen Pentest-Bericht als Sicherheitsnachweis präsentiert, belegt damit ein Viertel des Bildes.

Welche Felder der technologischen Massnahmen die typischen Funde berühren

Innerhalb der technologischen Massnahmen fallen die Befunde immer wieder in dieselben Felder. Die folgende Einordnung stammt aus der Testpraxis und ist kein Audit-Urteil: Welche Massnahme im Einzelfall greift, hängt vom Geltungsbereich und der Risikobewertung Ihres Managementsystems ab.

Typischer Fund	Berührtes Feld der technologischen Massnahmen	Warum das Audit es nicht sieht
Standard- und Default-Zugangsdaten	sichere Authentisierung	Die Richtlinie verlangt starke Authentisierung; ob sie überall umgesetzt ist, zeigt erst der Test
Klartextpasswörter in Dateien	Zugangsbeschränkung zu Informationen	Ablagen werden im Audit stichprobenartig, nicht flächendeckend geprüft
Fehlkonfigurierte AD-Zertifikatsvorlagen	privilegierte Zugriffsrechte, Konfigurationsmanagement	Konfigurations-Detailtiefe, die kein Dokumenten-Review erreicht
Ungeschützte privilegierte Konten	privilegierte Zugriffsrechte	„Rotation geregelt“ auf dem Papier ist nicht „Rotation gelebt“ im Verzeichnis
Passwörter in Gruppenrichtlinien	Zugangsbeschränkung, Konfigurationsmanagement	technische Altlast, die selten dokumentiert ist
Ungepatchte Systeme	Umgang mit technischen Schwachstellen	Der Patch-Prozess existiert, Ausnahmen häufen sich unbemerkt
Fehlende Segmentierung	Netzwerksicherheit	Der Netzplan sieht segmentiert aus, real ist er flach

Nach unserer Erfahrung ist die Segmentierung der wirksamste einzelne Hebel. Wo sie fehlt, wird aus einem kompromittierten Arbeitsplatz schnell ein kompromittiertes Unternehmen.

Welcher Pentest-Typ passt zu ISO 27001, und wo unsere Grenze liegt

Für die meisten Schweizer Unternehmen ist ein Grey-Box-Pentest auf Netzwerk und Web der pragmatische Standard, also ein Test, bei dem der Prüfer mit Basisinformationen startet. Entscheidend ist dabei der Scope, nicht die Box-Variante: Er muss die relevanten Risiken sinnvoll validieren.

Die drei Varianten kurz:

Black Box: Der Tester arbeitet ohne Vorwissen, wie ein externer Angreifer.
White Box: Der Tester hat vollen Einblick in Architektur und Konfiguration.
Grey Box: Der Tester startet mit Basisinformationen. Meist der beste Schnitt, weil die Testzeit stärker in reale Angriffspfade fliesst statt in das Wiederbeschaffen von Wissen.

Welcher Test-Typ zu Ihnen passt, hängt an Ihrer Umgebung. Für die allermeisten Schweizer Unternehmen deckt ein Penetration Test von interner und externer Infrastruktur, Cloud-Infrastruktur und Web-Applikationen den ISO-Bedarf ab.

Brauchen Sie für ISO 27001 mehr als einen Penetration Test?

Für die allermeisten Unternehmen nicht. Ein sauber geschnittener Penetration Test erbringt den technischen Nachweis, den die Norm erwartet. Aufwändigere, zielbasierte Formate wie Red Teaming prüfen etwas anderes, nämlich die Erkennungs- und Reaktionsfähigkeit auf hohem Reifegrad, und beantworten die ISO-Frage nicht.

Wie oft sollten Sie für ISO 27001 testen?

Einmal jährlich, plus nach jeder grösseren Änderung. Die Norm schreibt kein starres Intervall vor, sie verlangt regelmässige Überprüfung. In der Praxis läuft das auf einen jährlichen Rhythmus hinaus, gekoppelt an den Audit-Zyklus.

Wichtiger als der Kalender sind die Auslöser dazwischen: neue oder stark veränderte Systeme, eine Cloud-Migration, eine Fusion oder Übernahme. Jede grössere Änderung kann Angriffsflächen schaffen, die der letzte Test noch gar nicht kannte.

Zur Einordnung: Regulierte Finanzdienstleister kennen strengere Vorgaben mit eigenen, mehrjährigen Test-Zyklen. Für ein ISO-27001-getriebenes Unternehmen ausserhalb des Finanzsektors ist das aber nicht der Massstab. Hier zählt der jährliche Rhythmus plus die änderungsbasierten Trigger.

Was die Schweizer Regulierung zusätzlich verlangt

Wer in der Schweiz testet, hat mehr als nur ISO im Blick. Das ist der Punkt, den rein deutsche Ratgeber nicht abdecken.

Das revidierte Datenschutzgesetz (revDSG) verlangt für besonders schützenswerte Personendaten erhöhte Sorgfalt. Ein Teil der Umgebungen, die wir testen, verarbeitet genau solche Daten, etwa im Gesundheitsbereich, bei Ausgleichskassen oder in Laboren. Dort ist der technische Nachweis, dass Zugriffe wirklich kontrolliert sind, zugleich eine Datenschutz-Pflicht.

Für regulierte Finanzdienstleister kommen die Erwartungen der FINMA (Eidgenössische Finanzmarktaufsicht) hinzu. Das betrifft einen kleineren Kreis, gehört aber zum vollständigen Schweizer Bild dazu.

Warum ein Penetration Test allein nicht reicht

Ein Test zeigt die Lücke. Schliessen und überwachen muss man sie trotzdem.

Und er ist eine Momentaufnahme. Er sagt, wie es an einem Stichtag aussieht, nicht, was zwischen zwei Tests passiert. Dort entsteht das Risiko: eine neue Fehlkonfiguration, ein frisch eingeschleppter Zugang oder eine Schwachstelle, die erst morgen bekannt wird.

Wie einer unserer Offensive-Security-Spezialisten es ausdrückt: eine moderne Endpoint-Schutzlösung flächendeckend auszurollen reicht nicht. Werkzeug allein schliesst keine Fehlkonfiguration. Was die Lücke zwischen zwei Tests schliesst, ist laufende Erkennung und Reaktion. Eine solche Managed Detection and Response ist ein Dienst, der Angriffe rund um die Uhr erkennt und stoppt, wie ihn ein Cyber Defence Center betreibt. Wie sich ein klassisches SOC davon unterscheidet, lesen Sie im Beitrag SOC ist nicht Managed Detection and Response.

Fazit

Ein Zertifikat sagt, dass Sie es richtig aufgesetzt haben. Ein Penetration Test sagt, ob es auch hält.

Ohne Test bleibt offen, ob die Technik einem Angriff standhält. Ohne Managementsystem deckt der Test nur eines der vier Anhang-A-Themen ab. Erst zusammen ergeben sie das ganze Bild.

Den Angriff können wir nicht verhindern. Die Frage ist, wie schnell Sie ihn sehen und wie schnell Sie wieder stehen.

Möchten Sie wissen, was ein Penetration Test in Ihrer Umgebung findet? Fragen Sie einen Penetration Test an oder laden Sie unser Whitepaper zum Penetration Testing herunter.

Verfasser

Andreas Renold

Head of Cyber Defence bei der Netcloud AG. Er verantwortet das Cyber Defence Center der Netcloud und begleitet Schweizer Mittelstand-Kunden bei Architektur und Betrieb integrierter Security-Services. Den fachlichen Input zu diesem Artikel liefert das Offensive-Security-Team des Cyber Defence Center.

‍

Nicht ausdrücklich. Die Norm nennt den Penetration Test nirgends als Pflicht, erwartet über den geregelten Umgang mit technischen Schwachstellen im Anhang A aber faktisch einen technischen Nachweis. Unabhängig vom Zertifikat ist ein Test sinnvoll, weil das Zertifikat keine technische Belastbarkeit beweist.

Eine Zertifizierung beweist, dass Ihre Sicherheit organisiert und gesteuert ist, nicht, dass Ihre Technik einem konkreten Angriff standhält. Ob ein Angreifer trotz Zertifikat hineinkommt, zeigt erst ein praktischer Test im Netz.

Der Anhang A der Norm gliedert die Massnahmen in vier Themen: organisatorische, personenbezogene, physische und technologische. Ein Penetration Test liefert Evidenz zu den technologischen Massnahmen, und dort zu dem Teil, der sich aktiv angreifen lässt. Die übrigen drei Themen prüft er nicht.

Beides hat seinen Platz. Ein Scan ist automatisiert und findet bekannte Schwachstellen in der Breite. Ein Penetration Test ist manuell und tiefer: Er verkettet Schwachstellen zu realen Angriffspfaden, die ein Scanner nicht sieht.

Einmal jährlich, plus nach jeder grösseren Änderung. Ein starres Intervall schreibt die Norm nicht vor, ein jährlicher Rhythmus gekoppelt an den Audit-Zyklus hat sich in der Praxis bewährt.

Der Aufwand richtet sich nach Scope und Komplexität der Umgebung. Ein interner Netzwerktest hat einen anderen Umfang als eine grosse Web-Applikation. Sinnvoll ist, den Scope an den tatsächlichen Risiken auszurichten statt an einem Pauschalpreis.

No items found.

Zwei Geschäftspersonen diskutieren vor einem Laptop, während eine dritte Person im Vordergrund Notizen macht.

Lassen Sie uns Ihre Erfolgsgeschichte starten

Zum Kontaktformular