Thought Leadership
Ein Projekt hat üblicherweise Anfang und Ende. Dazwischen liegen bestimmte, nach den Kriterien des Projektmanagements definierte Schritte bis zum Projektabschluss. Risikomanagement funktioniert an dieser Stelle grundlegend anders. Risiken gänzlich zu beseitigen ist unmöglich.
Vielmehr beginnt alles bei einem Verständnis der Assets eines Unternehmens, wo diese liegen und welchen Wert sie haben. Eine Schwachstelle in einer von 20 Mitarbeitern genutzten Datenbank ist nicht annähernd so wichtig wie eine Schwachstelle in einer öffentlich zugänglichen API. Jedes identifizierte Risiko wird anschließend einer Kosten-Nutzen-Analyse unterzogen. Dazu vergleicht man die potenzielle Gefährdung mit den Kosten, die anfallen um das Risiko zu beseitigen, und priorisiert danach die Risiken.
Risikobewertungen sind notwendiger Bestandteil jeder Risikomanagementstrategie. Allerdings braucht man ein klares und auch für die Entwickler nachvollziehbares Bewertungssystem. Was die als hoch bewerteten Risiken angeht, kommt man um eine Ursachenforschung nicht herum. Nur so findet man heraus, was zu dieser kritischen Schwachstelle geführt hat und wie man sie in Zukunft vermeiden kann.
Patch-Management an den üblichen Workflows ausrichten
Wenn man komplexe Softwaresysteme aufbaut sind Abhängigkeiten unvermeidlich. Die Geschäftstätigkeit einer Firma beruht vermutlich auf einem Mix interner Anwendungen gepaart mit Open Source-Komponenten und Lösungen von Drittanbietern. Allesamt brauchen sie ein gutes Patch-Management. Jeder Code ist abhängig von Open Source-Bibliotheken und Frameworks. Werden in diesen Frameworks Schwachstellen gefunden, sind sämtliche Anwendungen anfällig, die diese Frameworks nutzen. Es ist wichtig, Bibliotheken und Frameworks zügig zu aktualisieren, um die betreffenden Applikationen zu schützen. Nun schreiben Sie vielleicht fehlerfreien Code. Was aber ist mit dem Code, den die Entwickler dabei zugrunde gelegt haben? Sobald eine Schwachstelle öffentlich gemacht wird, versuchen Angreifer, sie zeitnah auszunutzen. Je länger man mit dem Patchen der Systeme wartet, desto mehr Zeit haben potenzielle Angreifer die Schwachstelle ausfindig zu machen. Patch-Management-Prozesse sind nicht immer ganz einfach aufzusetzen. Um sie nicht unnötig kompliziert zu machen, sollte man sich soweit möglich an den üblichen Workflows der Entwickler orientieren. Muss beispielsweise eine Open-Source-Bibliothek gepatcht werden, erstellt man besten eine Pull-Anforderung im Repo der Anwendung, sodass alle Entwickler informiert sind. In der Anforderung sollte man erläutern, was genau aktualisiert werden soll und die nötigen Bausteine zusammenführen. Dieses Vorgehen dient nicht nur der Sicherheit, es ist auch gut fürs Betriebsklima.
Lesen Sie auch die anderen Beiträge des dreiteiligen Leitfadens:
Teil 1: Was jeder IT-Security Chef wissen sollte: die ersten 90 Tage
Im ersten Teil des Leitfadens haben sich die Autoren damit beschäftigt wie ein Sicherheitschef am besten seine Rolle findet und welche Schritte er unternehmen sollte, um seine Strategie umzusetzen.
Teil 2: Was jeder IT-Security Chef wissen sollte: Risikomanagement ist nicht gleich Projektmanagement
Ein Projekt hat üblicherweise Anfang und Ende. Dazwischen liegen bestimmte, nach den Kriterien des Projektmanagements definierte Schritte bis zum Projektabschluss. Risikomanagement funktioniert an dieser Stelle grundlegend anders. Risiken gänzlich zu beseitigen ist unmöglich.
Teil 3: Was jeder IT-Security Chef wissen sollte: Keep up to date
Im dritten und letzten Teil des Leitfadens beschäftigen sich die Autoren damit wie man ein Sicherheitsprogramm am besten auf dem aktuellen Stand hält und „pflegt“.
Welche Art von Assessment für welche Aufgabenstellung?
Sicherheitsbewertungen sind notwendiger Bestandteil der Arbeit eines jeden Sicherheitsverantwortlichen oder von externen Partnern. Ehe man mit der eigentlich Planung für die Durchführung von Assessments beginnt, sollte man sich mit den unterschiedlichen Zielen der verschiedenen Methoden vertraut machen.
1) Black-Box- und White-Box-Tests
Sicherheitsbewertungen sind entweder White-Box- oder Black-Box-Bewertungen. Bei White-Box-Tests erhält der Tester Einblick in das Innenleben einer Anwendung. Er kann beispielsweise Code- oder Systemdiagramme sehen, um Probleme bei der Implementierung einer Anwendung zu erkennen. Bei einem Black-Box-Test wird eine Anwendung getestet ohne im Detail über deren Funktionsweise informiert zu sein. Solche Tests simulieren den Blickwinkel eines Angreifers, der lernt wie das System funktioniert indem er sich damit beschäftigt. Diese Art des Testens veranschaulicht deshalb besser, was ein Angreifer bewerkstelligen müsste, um ein System erfolgreich anzugreifen.
Ein gutes Beispiel um den methodischen Unterschied klar zu machen ist die Verwendung von Verschlüsselung. Ein Black-Box-Test greift das kryptografische System blindlings an und versucht, es zu knacken.
Gelingt das, weiß der Tester, dass es offensichtlich Form der Verschlüsselung nicht ausreicht, er weiß aber nicht genau, warum. Ein White-Box-Tester würde den Code lesen und genau sehen können, welcher Verschlüsselungsalgorithmus verwendet wird. Der Tester stellt fest, dass der Algorithmus minderwertig ist und rät zu einem stärkeren. Wenn ein Tester auf das Innenleben einer Anwendung zugreifen kann, hilft das unter Umständen, Schwachstellen genauer zu verstehen und zu beheben.
2) Bewertung von Schwachstellen
Bei Schwachstellenbewertungen handelt es sich um White-Box-Tests, bei denen so viele Schwachstellen wie möglich in einer Umgebung aufgedeckt werden sollen. Diese Tests geben gleichzeitig Orientierungshilfen wie diese Schwachstellen am besten zu beheben sind und mit welcher Priorität. Schwachstellenbewertungen sind nicht zu verwechseln mit Penetrationstests, auf die wir als Nächstes eingehen. Die Bewertung von Schwachstellen bietet einen umfassenden Überblick über sämtliche Systeme. Allerdings unter der Bedingung, dass der betreffende Tester auf das Innenleben der Anwendung zugreifen kann, also beispielsweise auf Code oder Diagramme. Schwachstellenbewertungen sind das Mittel der Wahl, wenn ein Unternehmen eine niedrige bis mittlere Sicherheitsreife aufweist. Ziel ist es, möglichst viele Schwachstellen in der Umgebung zu finden und je nach Priorität abzusichern.
3) Penetrationstests
Penetrationstests und Schwachstellenbewertungen werden manchmal durcheinander gebracht. Penetrationstests sind im Gegensatz zu Schwachstellenbewertungen fokussierte Black-Box-Tests, die auf bestimmte Funktionalitäten in einem System abzielen. Penetrationstests sollte man durchführen, wenn man die bestehenden Schwachstellen beseitigt hat und man der Sicherheit seiner Anwendungen einigermaßen vertraut. Penetrationstests verfolgen immer ein bestimmtes Ziel, etwa das Extrahieren von Daten oder das Erlangen von Administratorrechten für einen Server.
Man kann beispielsweise eine Schwachstellenbewertung für die Warenkorbfunktion durchführen, um häufige Konfigurations- und Codierungsfehler zu finden. Sobald alle Resultate dieser ersten Bewertung behoben sind, führt man einen Penetrationstest für das Warenkorbsystem durch, um sicherzustellen, dass es tatsächlich ausreichend geschützt ist. Bei dieser Reihenfolge stellt man sicher, dass Penetrationstests effektiv eingesetzt werden – und man auch schwerer zu erkennende Fehler aufdeckt, die ein Codescanner nicht finden würde.
4) Red-Team
Ein Red-Team im Unternehmen setzt sich aus hochqualifizierten und erfahrenen Fachleuten zusammen. Es hat die generelle Aufgabe den Status der Informationssicherheit eines Unternehmens zu verbessern. Dazu testet das Team Umgebung, Systeme und Anwendungen nicht nur einmalig, sondern immer wieder, um auch neue Schwachstellen aufzudecken. Dabei nutzen Red Teams reale Taktiken. Sie denken also wie ein Angreifer. Red Teams erfüllen einen ganz bestimmten Zweck, der über das Auffinden und Beseitigen von Schwachstellen hinausgeht. Sie sollen das „Blue Team“ dabei unterstützen, Angriffe zu erkennen und zeitnah einzugrenzen statt Beweise für eine Datenschutzverletzung erst dann zu finden, wenn der Schaden längst entstanden ist.
5) Audits
Für die meisten Unternehmen sind Audits ein notwendiges Übel, gerade für Firmen in stark regulierten Branchen. Ein Audit misst, wie gut die bestehenden Systeme einem ausgewählten Standard entsprechen. Selbst wenn bei einem Audit einige Schwachstellen gefunden werden, ist das nicht der Hauptzweck. Ein Standard, wie PCI-DSS, legt fest, dass Firmen innerhalb dieser Branche/n Kundendaten verschlüsseln müssen und zwar mit starker Verschlüsselung.
Möglicherweise existiert eine Liste akzeptabler Verschlüsselungsalgorithmen und das betreffende Unternehmen nutzt einen von ihnen. Bis dahin reicht das Audit. Ein Penetrationstest stellt dann vielleicht fest, dass die Schlüssel zusammen mit den Daten in ein und derselben Datenbank gespeichert werden. Der Angreifer könnte die Daten also problemlos entschlüsseln. Ein Unternehmen kann also durchaus standardkonform agieren und trotzdem unzureichend geschützt sein. Audits überprüfen nicht den Sicherheitsstatus, sondern lediglich die Konformität mit den erforderlichen Standards. Bestenfalls werden die Ergebnisse des Audits hinsichtlich dessen interpretiert wie der Sicherheitsstatus im Idealfall sein sollte. Unternehmen mit guten Sicherheitspraktiken sind sehr wahrscheinlich konform. Aber Compliance ist nicht automatisch gleich Sicherheit. Um dieses Manko auszugleichen kann man Hybridmodelle verwenden. Eine Bug-Bounty-Plattform wie HackerOne kombiniert dazu anreizgesteuerte Schwachstellentests mit gezielten Tests auf bestimmte Kategorien von Schwachstellen, beispielsweise den Top 10 des OWASP (Open Web Application Security Project). Firmen haben bei einem Test Zugriff auf Hunderte von Hackern mit einer entsprechend breit gefächerten Expertise. Mit realen Angriffsszenarien, modernen Tools und Techniken.
6) Externe Dritte und Lieferanten im Auge behalten
In unserer vernetzten Welt kommen wir ohne externe Partner nicht aus. Es macht Sinn eher unternehmensfremde Aufgaben an externe Dritte auszulagern. Warum ein eigenes HR-System oder eine eigene Warenkorbfunktion erstellen, wenn man dadurch keinen Mehrwert erzielt? Die Zusammenarbeit mit externen Dritten birgt aber naturgemäß eine Reihe von Sicherheitsrisiken, und etliche der schwerwiegenden Datenschutzverletzungen der letzten Jahre geht auf Schwachstellen bei eben diesen zurück.
Das Risiko beim Einsatz von Dritten erhöht sich auf drei Arten:
- Daten können von Dritten missbraucht werden
- Daten gelangen aufgrund unzureichender Sicherheitspraktiken ohne Ihr Wissen nach außen
- Die Angriffsfläche wird größer, wenn die Drittanwendung Schwachstellen enthält
Jedes Unternehmen ist nur so sicher wie das schwächste Glied in seiner Kette externer Dritter. Man kommt nicht umhin zu prüfen, ob ein Lieferant oder Partner mit den Sicherheitsrichtlinien des Unternehmens vertraut ist und ihnen entspricht.
Die Angriffsfläche verändert sich
Und darauf sollte man reagieren. DevOps-Praktiken ermutigen Entwicklerteams, Code herauszugeben und schnelles Feedback zu bekommen, wo immer das möglich ist. Opfern Sie Sicherheitsanforderungen nicht im Tausch gegen „besser, schneller, billiger“. Schnelllebige Entwicklungsumgebungen bringen das Risiko mit sich, dass Services und Anwendungen auch ohne Wissen der IT-Sicherheit bereitgestellt werden. Dies gilt insbesondere für Cloud-Umgebungen, in denen Entwickler jederzeit virtuelle Maschinen und Code bereitstellen können. Damit Administratoren wissen, was sie tun dürfen und was nicht, sind strenge Richtlinien nötig, die den Missbrauch von Cloud-Ressourcen verhindern. Richtlinien muss man allerdings durchsetzen. AWS, Azure und Google Cloud werden Administratoren und Entwickler nicht für Sie kontrollieren.
Die gute Nachricht: mithilfe von Automatisierung lassen sich auch Richtlinien durchsetzen. Mit AWS Lambda kann man beispielsweise Datei-Uploads in S3 Buckets in AWS scannen. Richtlinien verhindern, dass Entwickler mithilfe ihrer Konten neue virtuelle Maschinen erstellen. Eine gute Faustregel ist, eine Build-Pipeline zu verwenden, um alle die Infrastrukturen aufzubauen, die man für seine Applikationen braucht. So verhindert man, dass Menschen entscheiden, wie VMs erstellt und bereitgestellt werden. Das Sicherheitsteam sollte über sämtliche der neuen Anwendungen und deren Zweck informiert sein. In einer Microservice-Umgebung mag das einigermaßen abschreckend sein. Trotzdem ist es zwingend erforderlich. Der Sicherheitsverantwortliche muss wissen, wann neue Services erstellt und freigegeben werden und auch welche Service-Konten in der Cloud bestehen. Nur ein klar definiertes Verfahren zum Erstellen neuer Konten lässt sich auch in die Überwachung einbeziehen.
www.hackerone.com
