Welche Prozesse und Nachweise verlangt das ISO 27001-Audit konkret beim Schwachstellenmanagement?

Teilt das Ganze pragmatisch in zwei Bereiche: Infrastruktur und Code. Auf der Infrastruktur-Seite lasst ihr monatlich einen Open-Source-Scanner über eure Server-IPs laufen und exportiert den Report. Auf der Code-Seite baut ihr einen Dependency-Check fest in die CI/CD-Pipeline ein; wenn eine Library mit bekannter kritischer Lücke gefunden wird, schlägt der Build fehl. Genau diese Pipeline-Logs lieben Auditoren als technischen Nachweis.

Wir haben uns bei unserem Audit letztes Jahr realistische Fristen gesetzt: Kritisch 7 Tage, Hoch 30 Tage, Mittel 90 Tage. Der Auditor fand bei der Stichprobe 4 noch offene 'High'-Schwachstellen. Da wir aber für jede einzelne eine fundierte Risikoakzeptanz mit Business-Begründung vorlegen konnten, gab es nicht mal eine Abweichung, sondern direkt die Freigabe.

Folgende vier Dinge gehören zwingend in den Audit-Ordner: 1) Freigegebene Schwachstellen-Policy samt SLA-Tabelle, 2) Datierte Scan-Zusammenfassungen der letzten drei Monate, 3) Ticket-Logs behobener Schwachstellen aus dem Trackingsystem, 4) Unterzeichnete Risikoakzeptanz-Formulare für Lücken, die aus technischen oder betrieblichen Gründen offenbleiben müssen.

sagt dem auditor bloß nicht „bei uns gibt es gar keine schwachstellen“, dann werden die direkt misstrauisch und bohren erst recht nach. am besten zeigt man immer eine transparente tracking-liste die belegt dass lücken auftauchen, nach schweregrad priorisiert und dann behboen werden.

Edit: Ich habe vom Handy geschrieben, entschuldigt die Tippfehler.

akzeptiert der ISO-Auditor denn Berichte von kostenlosen Open-Source-Scannern als offizielle Nachweise, oder müssen es zwingend lizenzierte Reports von teurer Enterprise-Security-Software sein?

Welches Tool man nutzt, interessiert den Auditor nicht es geht um die Methodik. Lasst einfach mit einem kostenlosen Tool alle externen IPs scannen, packt die gefundenen Lücken in eine Tabelle, weist sie den zuständigen Entwicklern zu und dokumentiert das Schließungsdatum. Wenn ihr diesen Zyklus für zwei Monate nachweisen könnt, kommt ihr locker durchs Audit.

Berater machen oft gerne Panik um einem teure Scanning-Software aufzuschwatzen. Dabei verlangt der Standard keine Perfektion sondern einen klar definierten Kontrollmechanismus. Selbst ein eigenes, simples Automatisierungsskript und saubere Ticket-Logs reichen völlig fürs Audit aus, solange das Ganze Hand und Fuß hat.

Ich probiere es aus.

Lasst uns die Begriffe trennen, sie werden oft verwechselt. Wenn die Zwei-Faktor-Authentifizierung aktiv ist, reicht ein gestohlenes Passwort allein nicht aus.

Wenn es jemand anders macht, würde mich das auch interessieren.

In der Theorie stimmt das, in der Praxis läuft es nicht so. Die Antwort hängt stark von der Branche ab, es gibt keine allgemeine Regel.

Viel Erfolg.

so klar geschriebene Texte sind selten.

Ich stimme zu, möchte das sogar besonders betonen. Wenn du zu einem Thema drei verschiedene Antworten bekommst, war die Frage falsch gestellt.

Viel Erfolg.

Hier lauert eine Falle, die ich nicht unerwähnt lassen möchte. Beginnt mit einem kleinen Test, bindet nicht gleich alles fest.

Wenn es jemand anders macht, würde mich das auch interessieren.

Beim Umsetzen gibt es drei Dinge zu beachten. Fehler auf der Schwachstellenmanagement-Seite sind meist rückgängig zu machen, aber teuer.

Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.

Ich würde sagen, lass uns nichts überstürzen. Menschen verteidigen nicht den Prozess, sondern die Gewohnheit. Der Widerstand kommt daher.

Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.

gespeichert.

Das hatte ich auch schon überlegt. Schaut zuerst, welche Daten ihr bei der Entscheidungsfindung zur Hand habt.

In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf. An deiner Stelle würde ich so vorgehen.

Notiert, danke.