Mit der Zunahme der generativen KI (künstliche Intelligenz) im letzten Jahr rückten auch die vielseitig einsetzbaren Large Language Models (LLMs) in den Fokus der Öffentlichkeit. Unternehmen versuchen nun, die Möglichkeiten von LLMs zu nutzen, um ihren Kundenservice, die Aufgabenoptimierung, die Erstellung von Inhalten und die Gesamtproduktivität zu verbessern.

Mit dem rasanten Wachstum KI-gestützter Anwendungen wie LLMs steigt auch das Risiko damit verbundener Sicherheitslücken. Unternehmen wollen als Erste auf dem Markt sein, aber leider wird die Sicherheit dabei oft vernachlässigt.

Wie bei jeder neuen Anwendung sollten jedoch die getroffenen Sicherheitsmaßnahmen bewertet werden. Es gibt zwar Ähnlichkeiten zu herkömmlichen Ansätzen zur Anwendungsbewertung, aber auch feine Unterschiede, die bei der Entwicklung, Erstellung und Bewertung KI-gestützter Anwendungen berücksichtigt werden sollten.

^{LLMs sind große neuronale Netzwerke, die mit umfangreichen Datasets trainiert werden. Je nach Art des Datasets, mit dem das LLM trainiert wird, kann es für eine Vielzahl von Aufgaben eingesetzt werden, darunter Textgenerierung, Übersetzung und Zusammenfassung sowie die Beantwortung allgemeiner Fragen.}

^{Die meisten Unternehmen stellen LLMs webbasiert bereit. So können Kundinnen und Kunden und Nutzerinnen und Nutzer in einem vertrauten Format (über eine Webanwendung) mit dem LLM interagieren. Auch Entwicklerinnen und Entwickler haben die Möglichkeit, das LLM auf klar definierte Weise über bereitgestellte Web-APIs zu nutzen.} 

^{LLMs können routinemäßig Sprache für allgemeine Zwecke generieren und die Fähigkeit nachahmen, Nutzerinnen und Nutzer und ihre individuellen Anfragen zu „verstehen“. Dadurch eignen sich webbasierte LLMs besonders gut zur Verbesserung der Nutzerfreundlichkeit, zum Beispiel in Chatbots, Suchmaschinen und virtuellen Assistenten.}

Webbasierte LLMs für allgemeine Zwecke zeichnen sich durch vier Merkmale aus, die sie so attraktiv machen.

1. Der Prompt: Eine Abfrage, die die Endnutzerin oder der Endnutzer über das Frontend der Anwendung eingibt. Sie legt den Kontext der Interaktion zwischen LLM und Nutzer*in fest und steuert die Art der Unterhaltung. Je spezifischer der Prompt, desto besser kann das LLM sein Dataset nutzen, um die Frage der oder des Nutzenden zu beantworten.

2. Die bereitgestellten APIs: LLMs stellen eine API-Schnittstelle speziell für die Nutzung durch die Endanwendung bereit. Über die APIs können herkömmliche Webanwendungen die Möglichkeiten des LLM nutzen.

3. Die Daten: Die Daten liefern dem Modell die Informationen, die es benötigt, um die Nutzeranfrage zu beantworten. Qualität ist wichtig, denn je mehr und je genauere Daten vorliegen, desto besser kann das LLM die Nutzeranfrage verarbeiten und eine Antwort formulieren, die sowohl hilfreich als auch für den*die Nutzer*in zutreffend ist.

4. Die Trainingsdaten: Dies sind die Daten, mit denen das Modell ursprünglich trainiert wurde, um es für seinen eigentlichen Zweck geeignet zu machen. Auch hier gilt: Qualität ist entscheidend.

Webanwendungen werden ständig weiterentwickelt und sind heute allgegenwärtig. Leider hat sich auch die Anzahl und Art ihrer Sicherheitslücken erhöht. Das Open Web Application Security Project (OWASP) erfasst die Anzahl und Art der öffentlich gemeldeten Sicherheitslücken in Webanwendungen und veröffentlicht alle paar Jahre eine Top-10-Liste der häufigsten Sicherheitslücken. 

Dies ist die Top-10-Liste des OWASP für LLM-spezifische Anwendungen:

Webbasierte LLMs haben die Art und Weise, wie Nutzende mit herkömmlichen Systemen interagieren, revolutioniert. Gut definierte und strukturierte Abfragen sind nicht mehr erforderlich. Stattdessen können Nutzerinnen oder Nutzer auf natürlichere und dialogorientiertere Weise mit Anwendungen und Systemen interagieren. Die Anwendungsbereiche dieser Technologie werden dank der menschlichen Neugier und des Erfindungsgeistes immer vielfältiger.

Webbasierte LLM-Anwendungen können auf ähnliche Weise bewertet werden wie herkömmliche Webanwendungen. Kontrollen wie Ausgabecodierung, Authentifizierung und Autorisierung, Datenschutz und API-Sicherheit sind durch jahrelange Tests der Anwendungssicherheit auf Herz und Nieren gut definiert.

Sicherheitsfachleute sollten ihre Methoden zur Bewertung der Anwendungssicherheit weiterentwickeln und probabilistische Teststrategien einbeziehen. So können webbasierte LLM-Anwendungen besser bewertet und vor Prompt Injection, übermäßiger Eigenständigkeit und blindem Vertrauen geschützt werden, um einen aktuellen und robusten Sicherheitsansatz zu verfolgen.

Im Jahr 2024 sind SIEM-Systeme (Security Information and Event Management) das Rückgrat der meisten Security Operations Center (SOCs). SIEMs wurden schon immer verwendet, um Sicherheitsdaten aus dem gesamten Unternehmen zu erfassen und zu analysieren und damit Bedrohungen zu erkennen, zu untersuchen und abzuwehren. Heutige SIEMs haben jedoch wenig mit denen von vor 15 Jahren gemeinsam. Moderne SIEM-Systeme haben eine cloudnative Architektur und Funktionen wie die Analyse von Nutzerentitäten und ‑verhalten (User Entity and Behavior Analysis, UEBA), Sicherheitsorchestrierung, Automatisierung und Reaktion (Security Orchestration, Automation, and Response, SOAR), Angriffsflächenmanagement und künstliche Intelligenz (KI).

Legacy-SIEMs sind oft langsam, umständlich und schwer zu bedienen. Aufgrund ihrer Architektur ist es häufig kaum möglich, Logquellen mit hohem Volumen aufzunehmen, und sie sind unter Umständen nicht in der Lage, mit aktuellen Bedrohungen Schritt zu halten oder die neuesten Funktionen zu unterstützen. Sie bieten möglicherweise nicht die Flexibilität, die für die spezifischen Anforderungen Ihres Unternehmens erforderlich ist, oder sind nicht für eine Multi-Cloud-Strategie geeignet, die heute in den meisten Unternehmen zum Einsatz kommt. Außerdem kann es sein, dass Sie damit die neuesten technologischen Entwicklungen wie KI nicht nutzen können.

In letzter Zeit haben sich im Bereich der SIEM-Lösungen grundlegende Veränderungen ergeben, die nicht unterschätzt werden dürfen. Diese Entwicklungen werden die Migration von Legacy-SIEM-Plattformen zu modernen Plattformen beschleunigen. Viele Unternehmen werden sich dann nicht mehr fragen, ob sie migrieren sollen, sondern wann. 

Wichtige Entwicklungen auf dem SIEM-Markt im letzten Jahr: 

September 2023:

• Cisco kündigt die Übernahme von Splunk an

Mai 2024:

• Crowdstrike präsentiert ein neues SIEM-Angebot
• Exabeam und LogRhythm geben ihre geplante Fusion bekannt
• IBM verkauft sein Qradar-Cloud-Geschäft an Palo Alto Networks und stellt die Entwicklung neuer Funktionen für Kunden, die Qradar lokal nutzen, ein

Die Google Cloud Security-Fachleute haben im Laufe von Jahrzehnten Hunderte von SIEM-Migrationen begleitet. Dadurch haben wir Einblicke in die Best Practices, die von Unternehmen jeder Größe angewendet werden können. Sehen wir uns also die wichtigsten Tipps für eine SIEM-Migration im Jahr 2024 an.

Beim Evaluieren einer neuen SIEM-Lösung sollten Sie sich und Ihrem Sicherheitsteam die folgenden Fragen stellen, um die Stärken und Schwächen der einzelnen SIEM-Varianten festzustellen und zu prüfen, ob sie die Anforderungen Ihres Unternehmens erfüllen:

Die Migration von einem Legacy-SIEM-System zu einer modernen Lösung ist unvermeidbar, um mit der sich ständig weiterentwickelnden Bedrohungslandschaft Schritt zu halten. Auch wenn die Herausforderungen groß erscheinen – eine gut geplante und durchgeführte Migration kann zu erheblichen Verbesserungen beim Erkennen, Untersuchen und Abwehren von Bedrohungen und dem allgemeinen Sicherheitsstatus Ihres Unternehmens führen.

Einen ausführlichen Leitfaden zur SIEM-Migration finden Sie im vollständigen Whitepaper „The great SIEM migration: A guide to ditching dinosaurs“ (Die große SIEM-Migration: Ein Leitfaden für das Ausmustern veralteter Strukturen).

Wenn Sie mehr über die moderne, cloudnative SecOps-Plattform von Google erfahren möchten, besuchen Sie unsere Website.

Die Zunahme digital nativer Umgebungen macht deutlich, dass Sicherheitsteams, insbesondere Red und Blue Teams, die Sicherheitsherausforderungen dieser neuen Ökosysteme kennen müssen, da sie sich von herkömmlichen lokalen Bereitstellungen unterscheiden. Die Frage ist also: Welche besonderen Herausforderungen gibt es und welche Fähigkeiten benötigen Fachleute für Cybersicherheit, um sie zu bewältigen? 

Angreifende und Cybersicherheitsteams liefern sich nicht mehr nur ein Wettrüsten um einige wenige wichtige Infrastruktur-Assets wie einen Domaincontroller oder einen Zertifikatsdienst. Stattdessen stellt jede Cloud-Ressource, jede SSO-Anwendung und jede Datenverbindung eine gleich große Bedrohung für ein Unternehmen dar. Wenn eine digital native Architektur auf Technologien wie APIs, IAM, Kubernetes, Docker, serverlosen Funktionen, Mikrodiensten, Cloud-Datenbanken, Speichern, Netzwerken, CI/CD-Pipelines oder anderen Gateways basiert, stellt jede einen potenziellen Angriffspunkt dar. Wie soll ein Unternehmen ohne gründliche Sicherheitstests wissen, dass die Kompromittierung einer SaaS-Anwendung eines Drittanbieters einer bzw. einem Angreifenden uneingeschränkten Zugriff auf die Cloud-Umgebung ermöglichen könnte? Der Grad der Vernetzung in ausgereiften digital nativen Umgebungen verwischt die Grenzen zwischen Drittanbieteranwendungen und den „Kronjuwelen“ eines Unternehmens. 

Eine weitere Herausforderung, vor der Sicherheitsteams nur in digital nativen Umgebungen stehen, sind die Protokolle, die für Angriffe verwendet werden. Da solche Umgebungen hauptsächlich aus Anwendungen und Diensten bestehen, die für den Zugriff über einen Webbrowser konzipiert sind, finden viele Angriffe auf Ebene 7 statt. Dort werden Interaktionen mit Unternehmensressourcen durch gängige Endnutzerprotokolle wie HTTP ermöglicht. Daher müssen Sicherheitsexpertinnnen und -experten die Rolle einer Nutzerin oder eines Nutzers in der Umgebung einnehmen und mit Anwendungen und Diensten hauptsächlich über Webbrowser interagieren, anstatt dedizierte Befehlszeilenprogramme zu verwenden. Diese Einschränkung erhöht den manuellen Aufwand erheblich, der erforderlich ist, um in einer neuen, digital nativen Umgebung ein angemessenes Situationsbewusstsein zu erlangen. 

Eine Folge dieser Einschränkung ist, dass herkömmliche EDR-Lösungen (Endpoint Detection and Response) deutlich weniger effektiv sind. Wenn sowohl legitime als auch böswillige Nutzende auf dieselbe Weise mit der Umgebung interagieren, erhöht sich der Aufwand für die manuelle Überprüfung durch die Cybersicherheitsteams erheblich, da sie zwischen tatsächlichen Bedrohungen und harmlosen Nutzeranfragen unterscheiden müssen. In dieser Hinsicht ähnelt der Schutz digital nativer Umgebungen dem einer Reihe einzelner Webanwendungen, die durch SSO und Vertrauensbeziehungen zwischen Cloud-Plattformen miteinander verbunden sind. 

Da jedes Unternehmen andere Anwendungen und Dienste benötigt, um zu funktionieren, lassen sich die über eine Unternehmensumgebung gewonnenen Erkenntnisse selten auf eine andere übertragen. Diese fehlende Standardisierung erfordert von Sicherheitsteams ein hohes Maß an Kreativität und Einfallsreichtum.

Mandiant nutzt die neuesten Trends bei digital nativen Angriffen, die in der Praxis beobachtet wurden, um die Methodik für Einsätze von Red Teams zu gestalten. Ein Szenario betrifft ein großes, rein digital tätiges Unternehmen. Mandiant und das Unternehmen hatten sich gemeinsam zum Ziel gesetzt, Zugriff auf eine interne administrative Webanwendung zu erhalten, die das Unternehmen als besonders schützenswert einstufte. 

Der Code dieser geschäftskritischen Anwendung wurde vor Kurzem von einem externen Unternehmen geprüft. Für die Authentifizierung wird ein bekannter SSO-Anbieter genutzt. Da es unwahrscheinlich war, dass die Anwendung selbst anfällig für gängige Webangriffe ist, konzentrierte sich das Red Team von Mandiant auf andere SSO-Anwendungen in derselben Umgebung, die möglicherweise mit der geschäftskritischen Anwendung verbunden sind. Zu diesen gehörten Plattformen zur Verwaltung von Zugriffsanfragen, Kubernetes-Manager und Tools für die API-Entwicklung. Mandiant dokumentierte diese Verbindungen sorgfältig und begann, die jeweils verfügbaren Zugriffsebenen zu analysieren. 

Im weiteren Verlauf der Bewertung fand Mandiant einen Vektor zur Rechteausweitung, der Administratorzugriff auf eine SaaS-Entwicklungsanwendung ermöglichte, mit der interne Automatisierungstools entwickelt werden. Zu Beginn der Zusammenarbeit wurde diese als geringes Risiko eingestuft, da die Nutzenden innerhalb der Anwendung auf die Rollen und Berechtigungen beschränkt waren, die ihnen über den SSO-Anbieter zugewiesen wurden. Erst einmal gab es keine Anzeichen dafür, dass ein*e Administrator*in dieser Anwendung zusätzlich Zugriff auf oder Berechtigungen für andere SSO-Anwendungen in der Umgebung erhalten könnte. 

Mit dem Administratorzugriff auf die SaaS-Entwicklungsanwendung stellte Mandiant fest, dass sich eine große Anzahl von Mitarbeiterinnen und Mitarbeitern bei der Anwendung authentifizierte und mindestens eines der darin enthaltenen Tools stündlich ausführte. Deshalb konzentrierte sich das Red Team darauf, diese speziellen Nutzer-Workflows besser zu verstehen und herauszufinden, wie sie kompromittiert werden könnten, um Zugriff auf andere privilegierte Ressourcen innerhalb der Umgebung zu erhalten.

Eine weitere Untersuchung der SaaS-Entwicklungsanwendung aus dieser administrativen Perspektive ergab, dass Mandiant die Berechtigung hatte, die Einstellungen zu bearbeiten, um Nutzerinnen und Nutzer mit der geschäftskritischen Anwendung zu verbinden. Mandiant nutzte diese Berechtigungen, um am Ende der SSO-Authentifizierung aller Nutzenden eine zusätzliche Anfrage einzuschleusen, die SSO-Tokens im Klartext an einen von Mandiant kontrollierten Server sendete. Nach dem Speichern dieser neuen Konfiguration erhielt das Red Team von Mandiant Authentifizierungsanfragen legitimer Nutzerinnen und Nutzer der geschäftskritischen Anwendung. Diese Anfragen enthielten Anmeldedaten, die Mandiant nutzen konnte, um sich als der*die jeweilige Nutzer*in auszugeben. Nachdem die Einschleusung eine Nacht gelaufen war, konnte das Red Team SSO-Tokens für eine Nutzerin bzw. einen Nutzer mit Administratorzugriff und sehr umfangreichen Berechtigungen abfangen und erhielt so Zugriff auf die zentrale Anwendung.

Unternehmen, die von Anfang an auf digitale Technologien gesetzt haben, und die cloudbasierten Umgebungen, in denen sie agieren, verändern sich ständig. Neue Technologien werden schneller denn je entwickelt, implementiert und wieder eingestellt. Die einzige Gewissheit für diese Unternehmen ist, dass Cyberkriminelle nicht warten werden, bis sie sich in ihrer neuen Umgebung zurechtgefunden haben. Deshalb sind proaktive Sicherheitsmaßnahmen, einschließlich kontinuierlicher Kontrollen der Cyberabwehr, fortlaufender Einsätze von Red Teams und spezialisierten Fachwissens im Bereich Cloud-Sicherheit, für eine angemessene Cyberabwehr unerlässlich.