Alle an einem Strang: 4 Schritte in Richtung zentralisierte Sicherheitstools

In unserer kürzlich gemeinsam mit ESG Research veröffentlichten Studie „Der Wendepunkt bei Webanwendungen und API-Sicherheit“ sind mir einige Fakten aufgefallen, die zueinander im Widerspruch stehen. Die Befragten gaben an, durchschnittlich 11 verschiedene Tools für die Sicherheit von Webanwendungen und APIs zu nutzen. Gleichzeitig bestätigten 93 % von ihnen, die Einführung eines konsolidierten Ansatzes für ihre Sicherheitstools zu planen oder an einem solchen interessiert zu sein. Zwischen der Vielzahl der verwendeten Tools und dem klaren Wunsch nach einem konsolidierten Ansatz besteht also eindeutig eine Kluft, die es zu überwinden gilt.

Und die Gründe dafür liegen für mich auf der Hand: Seine 11 Tools unter die Lupe zu nehmen und sich Gedanken darüber zu machen, wie man seine technischen Schulden senken und gleichzeitig seinen Security Stack und seine Sicherheitspraktiken verbessern kann, ist nicht leicht. Noch schwieriger ist es allerdings, sich von einer größeren Sicherheitsverletzung zu erholen. 

Die gute Nachricht ist, dass Sie nicht gleich alles auf einmal in Angriff nehmen müssen. Ich empfehle Ihnen, bei der Überarbeitung Ihrer Sicherheitstools einen evidenzbasierten Ansatz zu wählen: Beginnen Sie mit einem kleinen Projekt wie der Einführung von Okta in Ihrem gesamten Unternehmen und beweisen Sie, dass es dabei zwar zu einem anfänglichen Geschwindigkeitsverlust kommen kann, das Festhalten an der falschen Lösung aber zu einem dauerhaften Geschwindigkeitsverlust sowie zu einem höheren Risiko führt, dass etwas schief läuft. Wiederholen Sie diesen Vorgang, sobald Sie die nötige Unterstützung haben und das Vertrauen zwischen dem CEO oder CFO und dem CISO aufgebaut ist. 

Ich zeige Ihnen vier wiederholbare Schritte, mit denen Sie Ihre technischen Schulden im Bereich Security abbauen, Ihre Apps und APIs sicherer machen und Ihre Sicherheitstools konsolidieren können.

Dabei kann es zwar zu einem anfänglichen Geschwindigkeitsverlust kommen, das Festhalten an der falschen Lösung kann aber zu einem dauerhaften Geschwindigkeitsverlust sowie zu einem höheren Risiko führen, dass etwas schief läuft.

1. Inventur machen

Man kann nur das schützen, was man auch sehen kann. Der Begriff „Schatten-IT“ bezeichnet die Nutzung von Technologien, die nicht von der IT-Abteilung freigegeben wurden. Laut Statista werden solche Technologien von 42 % aller Befragten genutzt. Entwickler sind beispielsweise an schnellen Fortschritten interessiert, sodass sie IT-Teams möglicherweise nicht immer über neue APIs oder AWS Instanzen informieren. Aber selbst wenn Sie die ausgefeiltesten Sicherheitstools auf dem Markt parat haben, sind unbekannte APIs, die von Entwicklern eingeführt werden, nicht geschützt.

Dieses Problem lässt sich unter anderem auf ein Silodenken zurückführen. Es liegt in der Natur des Menschen, ein Problem sofort lösen zu wollen, aber nicht jedes Tool, das ein Entwickler verwendet, wurde von der Sicherheitsabteilung entwickelt beziehungsweise freigegeben. Am besten verschaffen Sie sich zunächst einen Überblick über die Workflows zur Softwarebereitstellung in Ihrem Unternehmen, um diese besser zu verstehen. Welche Gemeinsamkeiten gibt es zwischen Technologie und Prozessen? Welche Komponenten dienen als Zentralisierungspunkte oder haben Zugriff auf die gesamte IT-Landschaft? Die Antworten auf diese Fragen liefern Ihnen einen guten Ausgangspunkt, um gemeinsam mit den Verantwortlichen aus der Entwicklungsabteilung nach optimalen Lösungen für diese Risikokategorien zu suchen, anstatt weiterhin Ihr Glück mit einer immer länger werdenden Liste von spezifischen Tools oder Anbietern zu versuchen.

2. Risiken kategorisieren und priorisieren

Sobald Sie eine umfassende Liste mit allem, was Sie absichern müssen, erstellt haben, können Sie für jeden Punkt auf der Liste eine Risikobewertung durchführen. Zunächst ist es wichtig zu verstehen, welche Services oder Tools für eine erfolgreiche Softwarebereitstellung absolut unerlässlich sind. Wie können Sie sicherstellen, dass Ihre Services für Ihre Nutzer in der Produktivumgebung möglichst uneingeschränkt verfügbar sind? Welche Komponenten speichern oder verarbeiten sensible Daten? Bei welchen Tools gibt es privilegierte Verknüpfungen zu anderen Tools oder Komponenten? Überlegen Sie dabei ganz einfach, welche Komponenten Ihrer Softwaresysteme die Umsatzgenerierung und die Bereitstellung an Ihre Nutzer am meisten beeinträchtigen würden.

Als nächstes können Sie sich überlegen, wie Sie Angreifern den Zugriff auf diese wichtigen Ressourcen so schwer wie möglich machen können. Ein nützliches Hilfsmittel dabei sind zum Beispiel die OWASP Top 10. Die drei größten Bedrohungen im Jahr 2021 sind Injection-Angriffe, fehlerhafte Authentifizierung und Offenlegung sensibler Daten. Alles, was diesen drei Risikotypen ausgesetzt sein könnte, sollte bei der Überarbeitung Ihrer Sicherheitstools Priorität haben. 

Sobald Sie Ihre Risiken kategorisiert und priorisiert haben, können Sie Ihre Liste Schritt für Schritt abarbeiten. Gehen Sie dabei der Reihe nach vor: Optimieren oder ersetzen Sie zunächst eines Ihrer Sicherheitstools und fahren Sie dann mit dem nächsten fort.

3. Gleichzeitige Implementierung von Secure DevOps

Während Sie daran arbeiten, Ihre Sicherheitstools und -praktiken Stück für Stück zu konsolidieren, sollten Sie auch Ihre Prozesse nicht vernachlässigen. Wenn Entwickler mehrmals am Tag neuen Code bereitstellen, können sie das Sec-Team nicht über jede neue Instanz informieren. Im Grunde genommen bedeutet Secure DevOps also die Integration von Tools in das Produkt, damit es schon während seiner Entwicklung auf Sicherheit getestet werden kann, ohne dass die Entwicklungsproduktivität oder -geschwindigkeit darunter leiden.

Dev- und Sec-Teams müssen zusammenarbeiten, damit beispielsweise bei der Erstellung einer neuen API die Sicherheitsrichtlinien zur Anwendung kommen. Anschließend kann das Sicherheitsteam die Richtlinien verwalten, wenn neue Bedrohungen oder Schwachstellen auftauchen, und sie auf alles anwenden, was auf dieser API aufbaut.

Aber nicht nur Ihre Teams müssen miteinander kommunizieren. Das „Defense in Depth“-Konzept ist allgemein bekannt. Nur in der Praxis wird es oft etwas komplizierter: Es gibt bestimmte Tools, die gut gegen bestimmte Bedrohungen schützen, aber wenn sich keines davon integrieren lässt, haben Sie ein Problem. Sie müssen ein ganzes Spektrum von Bedrohungen erkennen können, da Angreifer an verschiedenen Stellen nach Schwachstellen oder Missbrauchsmöglichkeiten suchen. Sich über Sec und Dev hinweg einen umfassenden Überblick über Ihre Bedrohungen und Ihren Traffic zu verschaffen, gehört ebenfalls zu Secure DevOps.

4. Waschen, spülen … und nochmal von vorn.

Testen Sie Ihr neues Tool oder Verfahren, sobald Sie es eingeführt haben, und testen Sie es auch weiterhin in der Produktivumgebung. Angreifer freuen sich über Tools, die einmal eingerichtet und dann vergessen wurden, da diese ihre Chancen erwischt zu werden minimieren (oder ihnen einen bequemen Rückzugsort bieten). Ihr Ziel ist es, in der Reihenfolge Ihrer geschäftlichen Prioritäten kontinuierliches, nachweisbares Vertrauen in jede Ihrer Lösung zu gewinnen. So stellen Sie sicher, dass Sie Ihren ROI maximieren und gleichzeitig Ihre Teams mit zuverlässigen Tools versorgen, die sie durch wiederholten Einsatz in ihren Workflows sicher anwenden können.

Der Gedanke an eine Umstellung auf einheitlichere Sicherheitslösungen kann zunächst abschreckend sein, aber der Nutzen, den Sie aus Ihrer Investition ziehen, ist unbezahlbar: weniger Schwachstellen, weniger False Positives, mehr Übersichtlichkeit, Kosteneinsparungen und vieles mehr. Mit einem evidenzbasierten Ansatz rückt die Konsolidierung Ihrer Lösungen in greifbare Nähe.

Laden Sie die vollständige Studie herunter, um mehr darüber zu erfahren, wie und warum die Entwicklung von Sicherheitstools an einem Wendepunkt angelangt ist.