Thought Leadership
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“.
Jeder Sicherheitschef ist verantwortlich für ein Umfeld, das die grundsätzliche Sicherheitslage stärkt und alltägliche Vorkehrungen möglichst vereinfacht. Wie gewährleistet man beispielsweise DevOps-Geschwindigkeiten ohne die Sicherheitsmaßnahmen aufzuweichen? Wie verhindert man, dass Programmierfehler größere Schäden anrichten oder wie kann man solchen Fehlern sogar vorbeugen?
„Continuous Security“ mag zunächst ein ungewohnter Begriff sein. 100-prozentige Sicherheit gibt es nicht. Und sie ist auch nicht das Ziel. Continuous Security ist vielmehr ein klar definierter Prozess, der Transparenz schafft für alles, was in einer Umgebung passiert, um möglichst schnell darauf reagieren zu können. Intelligente Automatisierungstechnologien helfen dabei, einen durchgängigen Sicherheitsstandard einzuziehen. Sicherheit wird dadurch ein wesentlicher Bestandteil sämtlicher Anwendungen, gleichzeitig werden aber auch die Anforderungen der Entwicklungsteams berücksichtigt. Trotzdem gilt es hinsichtlich der konkreten Umgebung und Einsatzszenarien eine Fülle von Entscheidungen zu treffen. Die beste Orientierungshilfe geben die eigenen Kunden. Ziel muss sein, als Unternehmen so vertrauenswürdig wie möglich zu sein und dies über die Produkte und Lösungen zu kommunizieren.
Bausteine einer Sicherheitskultur
Die Sicherheitskultur ist so etwas wie die Persönlichkeit eines Unternehmens. Zu ihr zählen das Geschäftsumfeld der Firma, ihre Werte, ihre Haltung und natürlich die Mitarbeiter. Sicherheit ist dabei oft ein Prozess im Hintergrund. Etwa in Form von Scans oder Assessments. Nur: das reicht längst nicht mehr aus. Entwickler sollten grundlegende Prinzipien der Anwendungssicherheit verstehen und wissen, welche Prozesse existieren und warum. Dazu sollten sie die Perspektive der IT-Sicherheit einnehmen können.
Geben Sie Entwicklern neben Schulungen auch die Freiheit zu experimentieren. Vertrauen Sie darauf, dass sie das Richtige tun wollen, und überprüfen Sie es erst danach. Wenn Fehler auftreten, helfen Sie, das Problem zu lösen, ohne Schuld zuzuweisen. Korrigieren Sie stattdessen die Funktionsweisen der betreffenden Systeme, damit derselbe Fehler nicht erneut passiert. Ein guter Weg ist es, „Fireside Bug Bounty“-Reports an Entwickler und andere Interessierte zu schicken, wenn eine Schwachstelle gefunden wurde. Jede Mitteilung beschreibt um welche Schwachstelle es sich handelt, wie sie ausgenutzt werden kann, wer sie behoben hat und wie man ähnlich gelagerte Schwachstellen im gesamten System am besten beseitigt.
Nicht für alle Unternehmen ein gangbarer Weg, aber manchmal ist es durchaus sinnvoll Sicherheitsbewusstsein auch intern mit Fehlerprämien zu honorieren. Stellen Sie bei allen Aktivitäten vor allem den Kunden in den Mittelpunkt. Die Sicherheitskultur eines Unternehmens sollte die Voraussetzung für bestmögliche Services schaffen und gleichzeitig einen vertrauenswürdigen Umgang mit Daten gewährleisten. Zusätzlich zu diesen Maßnahmen werden Bug-Bounty-Programme zusehends beliebter.
Bug-Bounty-Programme wann und wie?
In einem Bug-Bounty-Programm machen Sie sich die Expertise einer großen Hacker-Community zunutze. Sie beauftragen Hacker damit, Schwachstellen zu finden, wenn Sie selbst nicht die nötigen Ressourcen haben oder existierende Sicherheitsmaßnahmen um eine weitere Komponente ergänzen wollen. Hacker melden Fehler und Schwachstellen, legen diese vertrauensvoll offen und werden je nach Schwere- und Auswirkungsgrad des Bugs entsprechend entlohnt. Bug-Bounty-Programme bieten etliche Vorteile. So greifen Sie beispielsweise sofort auf einen Pool erfahrener Experten mit Spezial-Know-how zu. Man sollte aber einige grundlegende Komponenten beachten, wenn das Programm erfolgreich sein soll.
Schritt 1: Eine Richtlinie zur Veröffentlichung von Schwachstellen – eine sogenannte Vulnerability Disclosure Policy (VDP) – ist der erste Schritt. VDPs formalisieren die Methode wie genau die Schwachstellen an ein Unternehmen gemeldet werden. Eine für beide Seiten unerlässliche Voraussetzung. Das betreffende Unternehmen definiert Regeln, welche Anwendungen von Hackern getestet werden sollen, wie die Schwachstelle/n gemeldet werden soll/en und wie das Unternehmen anschließend mit diesen Berichten umgeht. Dazu enthalten VDPs üblicherweise Passagen, die Hackern zusichern, dass sie für ihr Tun nicht juristisch und strafrechtlich belangt werden, solange sie sich an die Richtlinien halten.
Schritt 2: Sobald eine VDP eingerichtet ist, braucht man einen Mechanismus wie man die Schwachstellenmeldungen entgegennimmt. Man kann dazu eine E-Mail-Adresse in der typischen Form verwenden wie security@<yourcompanynamehere>.com. Wer sich scheut gleich ein umfassendes und kontinuierliches Bug-Bounty-Programm einzuziehen, der kann sich auf Hacker-powered-Penetrationstests beschränken. Sie bieten für diesen Fall das Beste aus zwei Welten, indem sie den Umfang begrenzen, aber dennoch auf das Wissen und Know how von Hackern zurückgreifen. Solche Pentests sind nicht nur begrenzt was den Umfang anbelangt, sie sind auch zeitlich limitiert. Das Unternehmen kontrolliert vollständig was getestet wird, bekommt aber in aller Regel dennoch einen guten Einblick in die Leistungsfähigkeit des Bug-Bounty-Ansatzes. Eintägige „Challenges“ auszuschreiben leistet ähnlich gute Dienste. Und man kommt mit Hackern in Kontakt, die man gegebenenfalls zu einem späteren Zeitpunkt wieder für ein potenzielles Bug-Bounty-Programm ansprechen kann.
Gerade was die Vielzahl der Schwachstellen anbelangt, die im Rahmen eines solchen Programms gemeldet werden sind viele Unternehmen zunächst mit dem neuen Wissen überfordert. Bei privaten Bug-Bounty-Programmen laden Sie zunächst nur einige Hacker zur Teilnahme ein. Die Hacker melden nicht nur Schwachstellen sondern helfen dabei, ineffiziente Prozesse auszumerzen und die Sicherheit der Systeme zu verbessern. Ein privates Bug-Bounty-Programm ist ein guter Einstieg in die Materie und übt gleichzeitig wie man am besten mit Hackern kommuniziert. Wenn Sie dann gut funktionierende Prozesse definiert und eingezogen haben, können Sie das Programm öffentlich machen. Damit steigt die Zahl der Bug Reports stark an. Man braucht also deutlich mehr Ressourcen um sie zu bewältigen. Allerdings gewinnen Sie dadurch die Möglichkeit, selbst schwer auffindbare Schwachstellen offenzulegen. Das sind oft solche, die anderen Testmethoden erfolgreich widerstanden haben.
Wissen teilen
Bis vor nicht allzu langer Zeit hatte Sicherheit viel mit Geheimniskrämerei oder Geheimhaltung zu tun. Wenn niemand weiß, wie etwas funktioniert, macht man sich auch nicht angreifbar. Gibt man dieses Wissen aber weiter, macht man sich zusätzlich angreifbar. So die These. Diese Haltung bröckelt inzwischen. Eine offene Zusammenarbeit zwischen verschiedenen Sicherheitsexperten wird immer mehr zur Norm. Von dieser neu gewonnenen Offenheit profitiert dann wieder die Community. Das Internet wird insgesamt sicherer, wenn Verantwortliche zusammenarbeiten, um Informationen auszutauschen – so die Motivation. Wenn ein Sicherheitsprogramm sich bewährt hat und entsprechende Erfolge zeitigt, teilen Sie dieses Wissen mit anderen.
Professionelle Organisationen wie ISC2 und SANS unterstützen ihrerseits den Austausch von Sicherheitswissen. Auch Konferenzen sind eine großartige Gelegenheit, Wissen zu teilen und in die Community weiterzutragen. Nutzen Sie die Gelegenheit, zu lehren und zu lernen.
Zum Abschluss haben wir Ihnen noch ein Mal die wichtigsten Komponenten zusammengestellt, wenn Sie als Sicherheitsverantwortlicher erfolgreich tätig sein wollen:
- Sammeln Sie alle Basisdaten zum aktuellen Sicherheitsstatus
- Betrachten Sie das Thema Sicherheit aus dem Blickwinkel des Benutzers
- Erstellen Sie Bedrohungsmodelle für sämtliche Anwendungen
- Konzentrieren Sie sich auf das Risikomanagement statt darauf sämtliche Risiken beseitigen zu wollen
- Ziehen Sie klare Patch-/Update-Richtlinien ein
- Verwenden Sie Security-/und Risk Assessments, um Schwachstellen aus unterschiedlichen Blickwinkeln zu finden
- Überprüfen Sie mittels Assessments alle Systeme auf potenzielle Schwachstellen
- Wenn Sie nur einen Teil Ihrer Systeme und Anwendungen testen wollen, verwenden Sie Hacker-Powered Pentests
- Formen Sie ein Red-Team, um aus Sicht eines Angreifers die Systeme zu testen
- Erstellen Sie Sicherheitsrichtlinien für Drittanbieter und überprüfen Sie Ihre Lieferanten
- Schaffen Sie Prozesse, um neue Services und Anwendungen zu überwachen
- Beobachten Sie AWS-Konten und -Assets auf Rouge VMs und Services
- Erstellen Sie „vertrauenswürdige“ Schwellenwerte – Schwellenwerte für die Testabdeckung und andere Metriken, mit denen die „vertrauenswürdigste“ Software erstellt wird
- Fördern Sie eine umfassende, gelebte Sicherheitskultur
- Vermitteln Sie Praktiken und Prozesse zur Anwendungssicherheit
- Machen Sie Sicherheit zu etwas Lohnenswertem, überlegen Sie, ob es für Sie Sinn macht auch intern „Bounties“ zu vergeben
- Stellen Sie die ausgewählten Programme und Initiativen der IT-/IT-Sicherheitsabteilung im Detail vor
- Handeln sie immer kundenorientiert
- Bauen Sie ein Bug-Bounty-Programm auf
- Erstellen Sie zunächst eine VDP
- Führen Sie Hacker-powered Pen-Tests durch
- Steigen Sie zunächst mit einem privaten Bug-Bounty-Programm ein, und erst danach in ein öffentliches
- Teilen Sie Ihr Wissen, intern und extern
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“.
www.hackerone.com
