Kurz gesagt: Schwachstellenmanagement im Mittelstand und in KMU ist ein schlanker, wiederkehrender Kreislauf: Systeme kennen, Meldungen gezielt verfolgen, nach Risiko bewerten, entscheiden, umsetzen und nachweisen. Entscheidend sind nicht teure Werkzeuge, sondern klare Zuständigkeiten und eine Priorisierung, die Erreichbarkeit, Daten und Angriffslage berücksichtigt. PHP2Shell ist ein gutes Übungsbeispiel, weil alle Schritte darin vorkommen.
Hunderte Meldungen, wenig Personal
Jede Woche werden neue Sicherheitslücken veröffentlicht, in Betriebssystemen, Programmiersprachen, Anwendungen und Plugins. Ein Konzern hat dafür ein Team. Ein Mittelständler hat oft eine IT-Leitung, ein, zwei Admins und mehrere externe Dienstleister. Niemand kann jede Meldung lesen, und das muss auch niemand.
Was es braucht, ist ein Filter: Welche Meldungen betreffen unsere Systeme, welche davon sind dringend, und wer kümmert sich darum? Fehlt dieser Filter, passiert eines von zwei Dingen. Entweder wird alles ignoriert, bis etwas passiert, oder jede Meldung löst Aufregung aus, und die wirklich kritische geht im Rauschen unter.
Der Kreislauf des Schwachstellenmanagements
Ein tragfähiger Ablauf für KMU lässt sich in sechs Schritten beschreiben:
- Erfassen, was läuft. Ohne Inventar kein Abgleich. Welche Websites, Server, PHP-Versionen und Anwendungen betreiben Sie, und wo? Wie das gelingt, zeigt Wissen, was läuft: Inventar aller Websites und Server.
- Meldungen verfolgen. Wenige, verlässliche Quellen abonnieren: Warnungen des BSI, Meldungen der Hersteller Ihrer Software, die Sicherheitsseiten Ihrer Linux-Distribution, bei PHP die Startseite von php.net.
- Bewerten. Betrifft die Meldung uns? Wenn ja, wie dringend? Dazu unten mehr.
- Entscheiden. Beheben, vorübergehend absichern, System isolieren oder Risiko bewusst tragen. Wer darf was entscheiden?
- Umsetzen. Update einspielen, Übergangsmaßnahme setzen, Dienstleister beauftragen.
- Nachweisen und nachhalten. Ist die Lücke wirklich geschlossen? Wann wird eine Übergangslösung abgelöst?
Der Kreislauf beginnt danach von vorn. Neue Systeme kommen hinzu, alte fallen weg, und neue Meldungen erscheinen.
Bei Schritt 2 hilft eine einfache Regel: lieber wenige Quellen regelmäßig lesen als viele gelegentlich. Für ein typisches mittelständisches Webumfeld genügen meist die Warnmeldungen von CERT-Bund beim BSI, die Sicherheitsmeldungen der eingesetzten Linux-Distribution, die Seiten der CMS- und Shop-Hersteller und die Startseite von php.net. Legen Sie fest, wer diese Quellen liest, und richten Sie dafür ein gemeinsames Postfach oder einen Kanal ein, der nicht an einer einzelnen Person hängt.
Ergänzend lohnt ein Blick von außen. Ein regelmäßiger Schwachstellenscan der öffentlich erreichbaren Systeme zeigt, ob veraltete Software oder unnötig offene Dienste sichtbar sind. Er ersetzt weder Inventar noch Updates, deckt aber Systeme auf, die in keiner Liste stehen.
Bewerten: Was zuerst drankommt
Der CVSS-Wert, eine standardisierte Einstufung des Schweregrads, ist ein guter Ausgangspunkt. Für die Reihenfolge im eigenen Haus reicht er aber nicht. Drei weitere Fragen entscheiden:
| Frage | Erhöht die Dringlichkeit | Senkt die Dringlichkeit |
|---|---|---|
| Ist das System aus dem Internet erreichbar? | öffentliche Website, Shop, Portal | nur intern, hinter VPN |
| Ist eine Anmeldung nötig, um die Lücke auszunutzen? | nein, unauthentifiziert | ja, nur für Administratoren |
| Welche Daten verarbeitet das System? | Kundendaten, Zahlungen, Zugänge | öffentliche Inhalte ohne Konten |
| Gibt es Berichte über Angriffe? | Angriffsversuche gemeldet | keine bekannten Versuche |
| Gibt es eine Übergangsmaßnahme? | nein | ja, mit belegter Wirkung |
PHP2Shell zeigt, wie das zusammenspielt. Beide Lücken haben einen CVSS-v4.0-Wert von 9.2, erlauben Codeausführung ohne Anmeldung und betreffen öffentlich erreichbare Webserver. Cloudflare und Patchstack berichteten laut Medien von Angriffsversuchen, das BSI stufte die Lage als Warnstufe 3 ein. Die Übergangsmaßnahmen von php.net bieten ausdrücklich keinen vollständigen Schutz. Alle Fragen zeigen in dieselbe Richtung: sofort handeln. Was das BSI konkret empfahl, steht unter Was das BSI zu PHP2Shell empfiehlt.
Entscheiden und dokumentieren
Nicht jede Lücke lässt sich sofort schließen. Ein Altsystem läuft auf PHP 8.1, für das es keine offiziellen Updates mehr gibt (siehe PHP 8.1 und älter: Was jetzt gilt), eine Fachanwendung verträgt das Update noch nicht. Dann braucht es eine Entscheidung, und die gehört nicht allein in die Technik.
Eine gute Entscheidungsnotiz enthält das betroffene System, die Lücke, die Bewertung, die gewählte Option, Übergangsmaßnahmen, die verantwortliche Person und einen Termin zur erneuten Prüfung. Wird ein Risiko bewusst getragen, entscheidet die Leitung und nicht der Admin allein. Das OWASP Cheat Sheet zum Umgang mit verwundbaren Abhängigkeiten empfiehlt ebenfalls, Risikoakzeptanz ausdrücklich auf Leitungsebene zu verankern.
Führen Sie eine einzige Liste offener Schwachstellen mit Status, Verantwortlichem und Termin. Eine Tabelle genügt. Wichtig ist, dass sie regelmäßig, etwa in der monatlichen Runde mit der Geschäftsführung, durchgesehen wird.
Was NIS2 und Dienstleister damit zu tun haben
Für Unternehmen, die unter NIS2 fallen, ist der Umgang mit Schwachstellen Teil der Pflichten zum Risikomanagement. Die Einzelheiten beschreibt NIS2 und Webserver-Sicherheit. Aber auch ohne gesetzliche Pflicht ist ein dokumentierter Ablauf ein Vorteil, etwa gegenüber Kunden, Versicherern und der eigenen Geschäftsführung.
Viele Schritte lassen sich auslagern, etwa das Verfolgen von Meldungen oder das Einspielen von Updates. Die Entscheidung über Risiken und die Gesamtübersicht sollten aber im Haus bleiben. Wer den Kreislauf vollständig an einen Dienstleister abgibt, weiß im Ernstfall nicht mehr, welche Systeme er überhaupt hat. Wie die Umsetzung als Routine organisiert wird, beschreibt Patch-Management als Prozess statt Feuerwehr.
Wie hilft PHP SOS konkret?
- Wir erstellen mit Ihnen das Inventar Ihrer Websites und Server als Grundlage für jeden Abgleich.
- Wir verfolgen für Ihre Systeme die relevanten Meldungen und liefern eine Bewertung in klaren Worten mit Empfehlung.
- Wir bereiten Entscheidungsnotizen für Fälle vor, in denen ein Update nicht sofort möglich ist.
- Über Security-Monitoring prüfen wir laufend, ob Systeme auffällig werden, während eine Lücke noch offen ist.
Fazit: Schwachstellenmanagement im Mittelstand muss nicht groß sein, aber verbindlich. Wer seine Systeme kennt, wenige gute Quellen liest und Entscheidungen festhält, reagiert bei der nächsten kritischen Meldung schnell und richtig.
Häufige Fragen
Was ist Schwachstellenmanagement?
Ein wiederkehrender Ablauf, mit dem ein Unternehmen Sicherheitslücken in seinen Systemen erfährt, bewertet, behebt oder bewusst akzeptiert und das Ergebnis festhält. Es geht nicht um ein Werkzeug, sondern um Zuständigkeiten und Entscheidungen.
Reicht der CVSS-Wert zur Priorisierung?
Er ist ein guter Ausgangspunkt, aber nicht genug. Entscheidend ist zusätzlich, ob das betroffene System aus dem Internet erreichbar ist, welche Daten es verarbeitet und ob Angriffe bereits beobachtet werden. Eine Lücke mit hohem Wert auf einem internen Testsystem kann warten, eine auf dem Shop nicht.
Braucht ein kleines Unternehmen dafür ein eigenes Werkzeug?
Für den Anfang nicht. Eine gepflegte Liste der Systeme, abonnierte Sicherheitsmeldungen und eine Tabelle mit offenen Punkten genügen. Schwachstellenscanner lohnen sich, wenn die Zahl der Systeme wächst oder Prüfungen regelmäßig belegt werden müssen.
Darf man eine Schwachstelle bewusst nicht beheben?
Ja, wenn das Risiko bewertet, die Entscheidung von der zuständigen Leitung getroffen und schriftlich festgehalten wird, idealerweise mit Übergangsmaßnahmen und einem Termin zur erneuten Prüfung.