Tierney - stock.adobe.com
Wie man Sicherheit messen und darstellen kann
Es genügt nicht mehr, den Zustand der IT-Sicherheit zu bestimmten Terminen zu erheben. Firmen benötigen beim Messen der Security einen kontinuierlichen Einblick in die Situation.
Immer mehr Unternehmen verlagern Anwendungen in die Cloud. Solche Cloud-nativen Anwendungen bringen jedoch neue Herausforderungen beim Thema Sicherheit – und besonders auch bei der Frage, wie diese Sicherheit eigentlich konkret messbar ist. Ein Cloud-nativer-Ansatz erfordert auch generell eine neue Herangehensweise: DevSecOps. Bei diesem Konzept wird das Thema Sicherheit von Anfang an in die Anwendungsentwicklung integriert, und Entwickler-, Sicherheits- und Betriebsteams sind dafür gemeinsam verantwortlich.
Früher wurde der aktuelle Zustand der IT-Sicherheit in vielen Unternehmen durchaus regelmäßig, aber nur zu bestimmten, festgelegten Zeitpunkten gemessen. Ein durchgehendes Monitoring fand eher selten statt. In modernen, Cloud-nativen Umgebungen und bei einem DevSevOps-Ansatz ändert sich jedoch vieles, und das teilweise sehr schnell.
Das gleiche gilt, wenn regelmäßig Apps bereitgestellt und alle Phasen der Anwendungsentwicklung automatisiert werden (CI/CD). Viele Anwendungen werden in nur einem Tag bereitgestellt – und die Sicherheitslage von Unternehmen kann sich daher in kurzer Zeit entscheidend verändern. Sicherheitsmessungen, die nur zu einem bestimmten Zeitpunkt vorgenommen werden, können deshalb sehr schnell veraltet sein. „Die Umgebungen sind dafür heutzutage einfach zu dynamisch“, sagt Alyssa Miller, BISO bei einer großen Finanz-Rating-Agentur. „Es funktioniert heute nicht mehr, beispielsweise nur alle 90 Tage einen Test durchzuführen. Eine solcher Test liefert keine aussagekräftigen Informationen. “
Zahlen können manchmal täuschen
Darüber hinaus sind die Messungen, die zur Beurteilung von Sicherheit verwendet werden, manchmal trügerisch. Ein Beispiel hierfür ist die Gesamtzahl an offenen Schwachstellen in Anwendungen oder in bestimmten Teilen einer Anwendung.
Auf den ersten Blick scheint das zwar ein vernünftiges, objektives Maß für die Anwendungssicherheit zu sein. Aber diese Metrik ist nicht immer zielführend. Ein Team meldet dann zum Beispiel 400 offene Schwachstellen in seiner Anwendung, während ein anderes Team vielleicht nur 20 Schwachstellen in seinem Projekt hat. Welches Team macht dann die bessere Arbeit? Für einen Laien liegt es klar auf der Hand: Das zweite Team scheint in punkto Sicherheit besser aufgestellt. Aber das kann ein Trugschluss sein. Vielleicht war das eine Team bei seinen Tests einfach gründlicher, und hat deshalb wesentlich mehr Schwachstellen entdeckt?
Und es gibt noch eine zweite Herausforderung: Nicht alle Schwachstellen wiegen gleich schwer. Theoretisch könnten es auch 400 eher unbedeutende Schwachstellen sein. Hacker würden dann keinen Zugriff auf sensible Daten erhalten, selbst wenn sie diese Schwachstellen ausnutzen. Im Gegenzug können es auch 20 kritische Schwachstellen sein – und wenn diese ausgenutzt werden, könnte es ernsthafte Probleme für ein Unternehmen bringen.
Dies zeigt, dass solche scheinbar konkreten Zahlen für ein Sicherheits-Monitoring manchmal nicht sehr aussagekräftig sind. Kritische Schwachstellen müssen viel höher gewichtet werden als solche, die eher oberflächlicher Natur sind.
Eine weitere scheinbar nützliche Kennzahl ist die Zeit, die zur Behebung von Schwachstellen benötigt wird. Ein Vorteil ist auch, dass dabei die von den entsprechenden Teams geleistete Arbeit berücksichtigt wird. Aber auch hier ist Vorsicht geboten: Einige Schwachstellen lassen sich sehr schnell beheben – zum Beispiel durch ein Update auf die neueste Version eines Softwarepakets.
Andere Probleme können sehr viel mehr Arbeit erfordern, zum Beispiel wenn eine Funktion neu erstellt werden muss, damit sie nicht auf eine bestimmte Bibliothek angewiesen ist. Während also ein Entwickler vielleicht 20 Schwachstellen an einem einzigen Vormittag behebt, hat ein anderer vielleicht in der gleichen Zeit nur eine behoben – aber dieser zweite Entwickler hatte auch eine viel schwierigere Aufgabe. Auch hier gilt es, die Hintergründe zu berücksichtigen.
Es gibt also einige Herausforderungen beim Messen von Sicherheit. Dennoch benötigt ein Unternehmen unbedingt genaue Einblicke in seine Anwendungssicherheit. Nur so können die Mitarbeiter datengestützte Entscheidungen treffen, und erkennen, wo es gut läuft, und wo es Verbesserungsbedarf gibt (siehe auch Für die Geschäftsführung wichtige Security-Metriken).
Wie man reale Bedingungen misst und abbildet
Softwareentwicklung ist heutzutage sehr dynamisch und schnell. Deshalb sind Echtzeit-Datenvisualisierungen statt Momentaufnahmen nötig. Die entsprechenden Teams sollten vielfältige Metriken prüfen und die Beziehung zwischen diesen Zahlen auch verstehen.
Schwachstellen auf niedriger Ebene können durchaus Probleme auf höherer Ebene hervorrufen, und somit auch die insgesamte Anzahl an Schwachstellen beeinflussen. Ein umfassendes Sicherheits-Monitoring sollte deshalb alle relevanten Zahlen beinhalten sowie Erkenntnisse aus SAST- und DAST-Tools (Static Application Security Testing und Dynamic Application Security Testing) und anderen Quellen.
„Die Messung der IT-Sicherheit ist das eine. Mindestens genauso wichtig ist aber, dass die Verantwortlichen im Unternehmen die verschiedenen Aspekte auch verstehen.“
Simon Maple, Snyk
Beziehungen zwischen Zahlen können mit Hilfe eines Tools in einem Kausalschleifendiagramm dargestellt werden. Eine solche Darstellung ist aus zwei Gründen ideal für diesen Zweck: Kausalschleifendiagramme zeigen nicht nur linear und einseitig Ursache und Wirkung, sondern visualisieren vielmehr die dynamischen Aspekte der visualisierten Daten.
Bei Sicherheits-Metriken muss berücksichtigt werden, dass sich veränderte Datenelemente auch langfristig gegenseitig beeinflussen. Darüber hinaus können Kausalschleifendiagramme fortlaufend aktualisiert werden. Man kann problemlos neue Knoten und Schleifen hinzufügen – schließlich generieren Cloud-native Technologien auch fortlaufend neue Daten. Deshalb ist diese Darstellungsweise so geeignet.
Wenn man alle relevanten Informationen auf diese Weise abgebildet, sind auch die notwendigen Maßnahmen leichter zu erkennen. Man kann Duplikate identifizieren und dann nach Knoten im Diagramm suchen, die nur eingehende Kausalbeziehungen, aber keine oder kaum ausgehende Kausalität haben.
Dies ist ein starker Indikator dafür, dass es sich bei diesem Knoten um ein Datenelement der obersten Ebene handelt. Zum Beispiel könnte das Anwendungsrisiko ein Knoten sein. Aber das Anwendungsrisiko wirkt sich nicht auf die quantifizierten Datenelemente aus; es ist eine Korrelation der verschiedenen Datenbeziehungen. Daher kann dies eine aussagekräftige Top-Level-Metrik sein, wenn man sie erfolgreich quantifizieren kann.
In nächsten Schritt wird der Wert der wichtigsten Elemente gewichtet, um zu einer Gesamtbewertung zu gelangen. Diese kann dann als Trendlinie dargestellt werden. Leider gibt es hier keine allgemeingültige Formel. Die Darstellung ist für jedes Unternehmen individuell, etwa hinsichtlich der unterschiedlichen Risikobereitschaft, des individuellen Sicherheitsansatzes und der spezifischen Umgebungsbedingungen.
In welche Richtung entwickelt sich die IT-Sicherheit im Unternehmen?
Die Messung der IT-Sicherheit ist das eine. Mindestens genauso wichtig ist aber, dass die Verantwortlichen im Unternehmen die verschiedenen Aspekte auch verstehen – und diese sind durchaus komplex. Dennoch ist gerade diese Komplexität nötig, um Abweichungen zu erkennen, und neue Komponenten auf optimale Weise hinzuzufügen.
Und zum Schluss noch ein wichtiger Punkt: Es kommt nicht darauf an, eine bestimmte Punktzahl zu erreichen (oder darunter zu bleiben). Sicherheit ist schließlich ein dynamischer Prozess. Deshalb sollte der Fokus darauf liegen, langfristig bessere Ergebnisse zu erzielen und sicherzustellen, dass sich die Punktzahl in die „richtige Richtung“ bewegt.
Dabei gibt es keine endgültige Punktzahl, die dann für alle Zeiten ausreichend ist. Wie Alyssa Miller anmerkt: „Kein Entwickler wird die Aussage treffen, dass eine Anwendung jetzt vollständig sicher ist. Man arbeitet vielmehr ständig daran, die Sicherheit fortlaufend zu verbessern. Schließlich ändert sich auch die Bedrohungslage permanent.“
Über den Autor:
Simon Maple ist Field CTO bei Snyk.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
