Drei Gründe, warum die Einführung von Zero Trust zu Bot-Schutz sowie Web- und API-Sicherheit führt

F5-Ökosystem | 12. Oktober 2022


Heute ist Zero Trust der angesagte neue Trend, mit dem jeder in Verbindung gebracht werden möchte. In unserem Bericht State of Application Strategy 2022 wurde Zero Trust als einer der drei „spannendsten“ Trends genannt und verzeichnete laut Google Trends in den vergangenen zwölf Monaten durchgehend großes Interesse.

Das Ergebnis ist, dass Zero Trust zu den meistdiskutierten – und missverstandenen – Sicherheitsansätzen gehört, seit „Shift Left“ Einzug gehalten hat. Allzu oft wird Zero Trust mit einer bestimmten Technologie wie dem Software-Defined Perimeter (SDP) oder einem Marktsegment wie dem Identity and Access Management (IDAM) gleichgesetzt.

Das ist nicht wirklich überraschend. Als Cloud Computing eingeführt wurde, erlebten wir denselben Ansturm, bestimmte Technologien oder Produkte mit dem „angesagten neuen Trend“ gleichzusetzen. Cloud Washing kam regelmäßig vor und wurde häufig als abwertende Bezeichnung dafür verwendet, wie „cloudbasiert“ ein neues Produkt tatsächlich war.

Daher sollte ich zunächst Zero Trust definieren. Dazu möchte ich meine Kollegen Ken Arora und Mudit Tyagi zitieren, die bereits einen hervorragenden Leitfaden zu diesem Thema veröffentlicht haben:

"Wir sind der Überzeugung, dass Zero-Trust-Sicherheit im Kern eine Denkweise – ein Überzeugungssystem – ist, aus der Techniken und Taktiken hervorgehen, die sich bestimmte Technologien zunutze machen und so zur Abwehr eines breiten Spektrums von Sicherheitsbedrohungen eingesetzt werden können."

Dies ist ein wichtiger Punkt, deshalb möchte ich ihn noch einmal wiederholen: Zero-Trust-Sicherheit ist im Kern eine Denkweise.

Diese Denkweise beruht auf einer Reihe von Annahmen, und der Einsatz von Technologien ergibt sich aus diesen Annahmen.

Das bedeutet, dass die Implementierung einer Technologie wie SDP oder API-Sicherheit nicht automatisch heißt, dass Sie Zero Trust eingeführt haben. Es gibt kein einzelnes Produkt, dessen Einsatz Sie plötzlich „Zero-Trust-konform“ und damit immun gegen Angriffe, Sicherheitsverletzungen oder die Ausnutzung von Schwachstellen macht.

Tatsächlich können SDP und API-Sicherheit geeignete taktische Maßnahmen zur Umsetzung eines Zero-Trust-Ansatzes sein. Dafür müssen Sie jedoch zunächst einige grundlegende Annahmen treffen und anschließend entscheiden, welche Tools und Technologien sich daraus logisch ableiten lassen.

Um dies näher zu erläutern, betrachten wir einige Beispiele, die uns – wie der Titel bereits sagt – zu dem Schluss führen, dass Bot-Schutz sowie Web- und API-Sicherheit zum Werkzeugkasten für „Zero Trust“ gehören.

  1. Ein Zero-Trust-Ansatz geht von einer Kompromittierung aus. Legitime Benutzer mit autorisiertem Zugriff können tatsächlich kompromittiert sein und damit eine unbeabsichtigte – und sehr kostspielige – Bedrohung darstellen. Angreifer wissen, dass es in der Regel einfacher ist, durch die Fenster (Benutzer) einzudringen als durch die Vordertür (Unternehmensnetzwerk). Benutzer sind ständig der Gefahr einer Kompromittierung ausgesetzt. Daher ist die Annahme, dass sie bereits kompromittiert sind, die sicherste Vorgehensweise. Von einem kompromittierten Firmenlaptop oder Mobiltelefon können zahlreiche potenzielle Aktivitäten ausgehen. Dazu gehören Angriffe auf Websites und Apps, mit denen Schadsoftware verbreitet werden soll (darunter Malware, Ransomware und was auch immer als Nächstes kommt), oder das Ausnutzen von Schwachstellen, um sich Zugriff zu verschaffen. Da APIs zunehmend „der Weg“ sind, über den mobile und webbasierte Apps auf Unternehmensanwendungen und -systeme zugreifen, ist es wichtig, selbst Inhalte von legitimen, authentifizierten Benutzern daraufhin zu überprüfen, ob sie schädlich sind. Daher ist Web- und API-Sicherheit eine logische Wahl, um Schutz vor diesem Risiko zu implementieren.

  2. Ein Zero-Trust-Ansatz geht davon aus, dass Anmeldedaten allein nicht ausreichen. Unabhängig davon, ob es sich bei einem Benutzer um einen Menschen, eine Maschine oder eine Software handelt, geht ein Zero-Trust-Ansatz davon aus, dass der tatsächliche Benutzer möglicherweise nicht legitim ist, selbst wenn gültige Anmeldedaten vorgelegt werden. Schließlich ist Credential Stuffing nach wie vor ein Problem, bei dem legitime, aber gestohlene Anmeldedaten verwendet werden. Bekanntlich werden im Durchschnitt täglich eine Million Benutzernamen und Passwörter als offengelegt oder gestohlen gemeldet. Analysen von F5 kommen zu dem Schluss, dass 0,5–2 % der Anmeldedaten aus einer kompromittierten Liste auf einer gezielt angegriffenen Website oder mobilen App gültig sind. Daher sollte ein Zero-Trust-Ansatz nicht nur die Anmeldedaten, sondern auch die tatsächliche Identität des Benutzers überprüfen. Dazu gehört auch, Bots zu erkennen, die sich als legitime Benutzer ausgeben. In der Praxis spielt daher der Bot-Schutz – auch Bot-Erkennung genannt – eine wichtige Rolle bei einem Zero-Trust-Ansatz.

  3. Ein Zero-Trust-Ansatz geht davon aus, dass Veränderungen allgegenwärtig sind. Zero Trust verwirft die Annahme, dass kein Risiko mehr besteht, sobald ein Benutzer verifiziert und der Zugriff auf eine Ressource autorisiert wurde. Jede Transaktion wird als riskant betrachtet und anhand der übermittelten Inhalte sowie des Benutzers, der sie sendet, bewertet. Session-Hijacking ist eine reale Angriffsmethode. Ständige Wachsamkeit ist schließlich das Motto von Zero Trust (oder sollte es zumindest sein). Das bedeutet, stets nach schädlichen Inhalten Ausschau zu halten. Daher sind die Sicherheit von Webanwendungen und APIs sowie die Bot-Erkennung entscheidende Komponenten eines Zero-Trust-Ansatzes.

Dieser Ansatz führt nun auch zu anderen Tools und Technologien wie SDP, Identitäts- und Zugriffskontrolle, Netzwerk-Firewalls und CASB sowie einer Vielzahl weiterer Lösungen, die bekannte Risiken mindern, welche sich naturgemäß aus diesen Annahmen ergeben. Man kann jedoch nicht nur eine davon implementieren und die Zero-Trust-Initiative damit als abgeschlossen betrachten. Das wäre, als würde man bei einem gebrochenen Bein Tylenol einnehmen, anstatt einen Arzt aufzusuchen. Ja, es lindert die Schmerzen, trägt aber überhaupt nicht dazu bei, das eigentliche Problem zu beheben.

Zero Trust als einen Mentalitätswandel zu verstehen, der zu Maßnahmen zur Risikominderung führt, ist kein perfekter Ansatz – das ist keine Methode –, aber er bringt Sie auf dem Weg zu mehr Anpassungsfähigkeit voran und versetzt Sie in die Lage, schneller und erfolgreicher auf neue und aufkommende Angriffe zu reagieren.

Bleiben Sie da draußen sicher.

Mehr darüber, wie Sie Ihre Sicherheitsarchitektur mit einem Zero-Trust-Ansatz modernisieren können, erfahren Sie in Kapitel 5 unseres Buches „Enterprise-Architektur für digitale Unternehmen“.


Teilen

Über den Autor

Lori Mac Vittie
Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie

Ähnliche Blogbeiträge

Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
F5-Ökosystem | 11.08.2024

Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen

Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.

KI zulassen und einführen? Lehren aus der Public Cloud
F5-Ökosystem | 06.04.2023

KI zulassen und einführen? Lehren aus der Public Cloud

Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.

Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
F5-Ökosystem | 12.04.2022

Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs

Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.

F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5-Ökosystem | 26.05.2020

F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen

F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.

Telemetrie: Eine andere Art von Daten
F5-Ökosystem | 24.02.2020

Telemetrie: Eine andere Art von Daten

Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.

MTTR bedeutet nicht „Mean Time to Reboot“
F5-Ökosystem | 14.03.2019

MTTR bedeutet nicht „Mean Time to Reboot“

„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.