Schwachstellen-Scan im Kleinunternehmen: Welche Tools wählen und wie Berichte ohne IT-Kenntnisse lesen?

Wenn für die Website ein Standard-CMS genutzt wird, trennt den Scan am besten in Port-Scan und Webanwendungs-Scan. Steht im Bericht, dass Datenbank- oder Management-Ports nach außen offen sind, sperrt diese in der Firewall einfach für alle außer eure eigene Büro-IP – zack, Problem gelöst.

Wir hatten in unserem Lager in Bologna genau dieselbe Prüfung. Um keine 2.500 EUR zu verpulvern, haben wir einen Cloud-Scanner für 80 EUR im Monat gebucht. Erster Bericht: 42 Lücken. Ein Bekannter aus der IT hat drübergeschaut: 39 davon waren Kinkerlitzchen wie "Server-Versionsnummer wird öffentlich angezeigt". Die 3 echten Lücken zu fixen hat 2 Stunden gedauert.

Automatische Scans werden bei Konzern-Audits nicht immer akzeptiert. Fragt lieber genau nach: Wollen die einen echten offiziellen Penetrationstest oder reicht ein normaler Schwachstellen-Scan? Wenn die Vorgaben unklar sind, weisen die den 100-EUR-Scan am Ende zurück und bestehen auf einen Bericht von akkreditierten Testern.

Bevor ihr Geld für Tools ausgebt: Macht ein Ticket beim aktuellen Webhoster auf. Viele gute Anbieter haben im Kundenpanel schon kostenlose Basis-Sicherheits- und Portscans integriert. Dieses Dokument reicht Auditoren erstaunlich oft als erster Nachweis.

Besteht bei solchen Scans eigentlich die Gefahr, dass die Website abschmiert oder Bestellungen in der Datenbank flöten gehen? Wenn der Shop live läuft, traut man sich den Scan kaum zu starten.

keine Sorge, reine Schwachstellen-Scanner greifen das System nicht aktiv an, die rütteln quasi nur an den Türklinken um zu sehen ob offen ist... trotzdem: Um die Banbreite nicht zu belasten den Scan am besten nachts außerhalb der Geschäftszeiten anwerfen.

Ohne IT-Fachwissen den Bericht einfach in 3 Schritten abarbeiten: 1) Alles rausfiltern, was nicht als Critical oder High markiert ist. 2) Zeilen markieren, bei denen "Exploit verfügbar" steht. 3) Diese Liste 1:1 an den Support des Hosters schicken mit der Bitte, die Ports dichtzumachen oder Updates einzuspielen.

Korrektur: Ich hatte die Zahl falsch im Kopf, sie war etwas niedriger.

Verbratet bloß keine 2.000 EUR an Berater; zieht euch den Bericht aus einem Cloud-Tool und leitet die roten Warnungen direkt an den Hoster weiter.

ich fasse kurz zusammen was bisher gesagt wurde. änderungen an Zahlungsdaten werden niemals über den Kaal bestätigt, über den sie eingehen.

ich hoffe das hilft dir weiter.

Genau so, und das ist zudem kaum bekannt. Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.

Wenn deine Situation anders ist, ändert sich das natürlich.

Man sollte der Reihe nach vorgehen. Entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht.

Wie habt ihr das Problem gelöst? Ein automatisierter Scan-Report ist kein Penetrationstest.

Ich hoffe das hilft dir weiter.

Wenn ich dich richtig verstehe meinst du Folgendes: Das allein zu versuchen, ist der teuerste Weg.

Das war's, entschuldige, wenn ich zu lang war.

Dieses Thema ist archiviert. Die Antwort hängt stark von der Branche ab, es gibt keine allgemeine Regel.

Ich probiere es aus.

Der billige Weg stellt sich oft im Nachhinein als teuer heraus. Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.

Korrigiert mich, falls ich falsch liege.

Ich spreche mal aus der Gegenperspektive, ich bin auf der Lieferantenseite. Verlasst euch nicht auf eine einzige Maßnahme; geht schichtweise vor.