Schwachstellenscan oder Penetrationstest?

Worin unterscheiden sich die beiden?

In dem, wonach sie suchen. Ein Scan gleicht Ihre Systeme, Geräte, Anwendungen und Dienste mit Datenbanken bekannter Schwachstellen ab, sucht also nach dem, was schon jemand beschrieben hat. Ein Penetrationstest ist dagegen manuelle und automatisierte Arbeit an einer konkreten Anwendung, die ausprobiert, was sich mit ihr anstellen lässt, und er findet auch Fehler, die in keiner Datenbank stehen, weil sie erst in Ihrer eigenen Logik entstanden sind.

Daraus ergibt sich der zweite Unterschied: Ein Scan geht in die Breite und wird wiederholt, ein Test geht in die Tiefe und wird gezielt durchgeführt. Es sind also nicht zwei Stufen derselben Sache, bei denen die teurere die günstigere ersetzen würde. Es sind zwei verschiedene Fragen.

Was findet ein Scan, und was entgeht ihm?

Er findet nicht aktualisierte Systeme, bekannte Fehler in Komponenten und nach außen offene Dienste, von denen im Unternehmen oft niemand weiß. Die Befunde erhalten einen CVSS (öffnet sich in einem neuen Fenster)-Score und eine Priorität, sodass nach Schweregrad behoben wird und nicht nach dem, was gerade zur Hand ist. Die Datenbank bekannter Schwachstellen ist CVE (öffnet sich in einem neuen Fenster), ein Werkzeug dafür ist etwa der Greenbone Vulnerability Manager, und für den Blick von außen gibt es Shodan, das zeigt, was aus dem Internet sichtbar ist.

Was ihm entgeht, ist alles, was kein Fehler einer Komponente ist, sondern ein Fehler Ihrer Anwendung. Dass die Bestellung eines fremden Kunden angezeigt wird, sobald man eine Zahl in der Adresse ändert, dass sich eine Zahlung zweimal bestätigen lässt oder dass eine Administratorfunktion direkt aufgerufen werden kann, ohne dass jemand nach der Rolle fragt. Ein Scanner sieht solche Dinge nicht, weil die Anwendung aus seiner Sicht korrekt antwortet.

Was tut ein Tester, was ein Scanner nicht kann?

Er prüft die Anwendung so, wie es ein Angreifer tun würde, und folgt dabei einer Methodik, damit nichts vergessen wird: OWASP Top 10 (öffnet sich in einem neuen Fenster) und dem OWASP Testing Guide bei Webanwendungen, MASVS (öffnet sich in einem neuen Fenster) bei mobilen Anwendungen. Getestet werden Authentifizierung, Autorisierung, Eingabevalidierung, Anwendungslogik und Datenschutz, einschließlich Angriffen wie SQL-Injection, XSS, CSRF, IDOR, SSRF und RCE.

Das Ergebnis ist keine Liste von Ports, sondern ein Bericht, der die Befunde nach Risiko kategorisiert. Und weil eine Behebung eine Schwachstelle auch nur scheinbar beseitigen kann, folgt danach ein Retest. Diese Frage stellt sich beim Scan nicht: Dort startet man einfach den nächsten Durchlauf.

Wie oft wird was durchgeführt?

Ein Scan ist als regelmäßige Routine sinnvoll, nicht als einmalige Aktion: Für die Produktivumgebung wird ein monatlicher Rhythmus empfohlen, externe Scans lassen sich wöchentlich automatisieren, und nach größeren Änderungen wird ad hoc gescannt. Der Grund ist einfach: Eine Schwachstelle in Ihrem System kann entstehen, ohne dass Sie irgendetwas tun. Es genügt, dass jemand sie in einer Komponente entdeckt, die Sie verwenden.

Ein Penetrationstest ist dagegen an ein Ereignis gebunden. Eine neue Anwendung, eine grundlegende Änderung, eine neue Integration oder ein System, das neuerdings mit Geld oder personenbezogenen Daten arbeitet. Jeden Monat dasselbe zu testen, ist nicht sinnvoll, wenn sich nichts geändert hat.

Worauf sollten Sie bei der Beauftragung eines Tests achten?

Auf den Umfang, denn er entscheidet über den Preis und darüber, was überhaupt gefunden werden kann. Ein Test einer öffentlichen Anwendung sagt nichts über das interne Netz aus, und ein Test ohne Zugangsdaten sagt nichts darüber, was ein angemeldeter Benutzer mit fremden Daten tun kann. Beides ist ein legitimer Auftrag, man darf es nur nicht mit einer Aussage über die Sicherheit des Unternehmens als Ganzes verwechseln.

Der zweite Punkt ist, was im Bericht stehen soll: neben den Befunden und ihrem Schweregrad auch der Weg, auf dem der Tester zu ihnen gelangt ist. Ohne ihn beheben die Entwickler die Beschreibung, nicht den Fehler, und niemand überprüft, ob die Behebung gewirkt hat. Deshalb folgt auf die Behebungen ein Retest, und deshalb ist es sinnvoll, ihn zu vereinbaren, bevor der Test beginnt.

Womit sollten Sie anfangen?

Mit einem Scan, und zwar aus zwei Gründen. Er ist günstiger, lässt sich also sofort starten, und vor allem zeigt er Ihnen, wie groß das Problem eigentlich ist: wie viele Systeme das Unternehmen betreibt, wie viele davon niemand aktualisiert und was aus dem Internet sichtbar ist. Erst auf dieser Grundlage lässt sich entscheiden, welche Anwendung einen Test verdient, denn alles zu testen, bezahlt niemand.

Beides ist zugleich eine gute Grundlage für das Risikomanagement, das das tschechische Cybersicherheitsgesetz von Unternehmen in regulierten Diensten verlangt; ob es Sie betrifft und in welchem Regime, erläutert ein eigener Artikel. Scans und Tests liefert Securent, das in der Kategorie Cybersicherheit neben den ICT-Dienstleistungen steht.