In immer mehr Kundenprojekten begegnet uns aktuell dieselbe Fragestellung: Wo und wie wird Generative AI im Unternehmen genutzt? Zwischen Innovationsdruck und Compliance-Anforderungen wächst die Sorge vor unkontrollierter Nutzung externer KI-Services, sei es durch den Upload sensibler Daten, Shadow-IT oder neue Angriffsflächen durch Browser-basierte AI-Tools.

Viele Organisationen haben bereits Richtlinien zur KI-Nutzung definiert, haben aber aufgrund der unzähligen KI-Services kein verlässliches Monitoring. Wir haben deshalb in mehreren Projekten eine gezielte CrowdStrike SIEM Suche entwickelt, mit der sich Prozesse identifizieren lassen, die auf bekannte Generative-AI-Services zugreifen. In diesem Beitrag zeigen wir, wie dieser Ansatz funktioniert, welche Datenquellen genutzt werden können und wie Security-Teams damit schnell mehr Klarheit über AI-Nutzung im eigenen Umfeld gewinnen.

Falcon SIEM Use-Case: GenAI Nutzung

In diesem Beispiel nutzen wir das CrowdStrike Falcon SIEM, da es in Kombination mit dem Falcon EDR bereits alle notwendigen Telemetriedaten beinhaltet, die wir für die Erkennung benötigen. Die Umsetzung dürfte jedoch auch mit anderen SIEM Produkten ohne weiteres Möglich sein. Wichtig ist die folgende Datengrundlage:

• DNS Request Events
• Process Events

Der CrowdStrike Sensor erzeugt für DNS Requests jeweils ein Event, welches Informationen über die DNS Auflösung und den Kontext dazu speichert:

#event_simpleName=DnsRequest

Da wir für den Use-Case den Zugriff auf einen GenAI-Service auch den verantworlichen Nutzer anreichern möchten, benötigen wir den Kontext aus dem Event für den verantwortlichen Prozess. Prozessinformationen speichert der Sensor in diesem Feld:

#event_simpleName=ProcessRollup2

Als dritte Komponente benötigen wir eine Liste mit den AI Services und deren Domains. Damit diese Liste nicht innerhalb der Suche gepflegt werden muss, lagern wir sie in eine sogenannte Lookup-File aus. Das sind Tabellen, die wir später in der Suche aufrufen und abgleichen können.

Wir pflegen eine Vielzahl an Lookup-Files zentral für unsere Kunden und können sie in verschiedenen Use-Cases anwenden:

CrowdStrike Falcon NextGen SIEM Query

In diesem Abschnitt gehen wir ein wenig auf die Query ein, die nun den Inhalt der Lookup-File gegen alle DNS-Requests der Hosts abgleichen soll.

1defineTable(query={#event_simpleName=ProcessRollup2}, include=[TargetProcessId,UserName,ImageFileName,ComputerName], name="ProccessQuery")
2| #event_simpleName=DnsRequest
3| ComputerName = ?ComputerName
4| ContextBaseFileName = ?SourceProcess
5| match(file="AI-Domains.csv", field=[DomainName],column=Domain,ignoreCase=true,mode=glob)
6| Service = ?Service
7| match(file="ProccessQuery", field=[ContextProcessId],column=TargetProcessId,strict=false)
8| UserName = ?UserName
9| SourceProcess := ContextBaseFileName
10| groupBy([ComputerName, UserName, Service, DomainName, SourceProcess],function=count(as=Count))
11| sort(field=Count,type=number,order=desc)

Die Query lässt sich logisch in drei Bestandteile zerlegen. Im ersten Teil wird über die “defineTable” Funktion eine virtuelle Tabelle erzeugt. Diese ist notwendig, um die DnsRequest-Events mit Kontext aus den ProcessRollup2-Events anzureichern. Andernfalls wäre es nicht möglich den für den Prozess verantwortlichen Nutzernamen mit aufzuführen. Um die Verbindung zwischen DnsRequest und ProcessRollup2 Events in den Kontext zu setzen, nutzen wir die TargetProcessID. Da DNS Requests immer in Relation zu einem Prozess stehen, führt jedes DnsReques Event das Feld “TargetProcessId”. Dieses hat den selben Wert, wie das vorausgehende ProcessRollup2 Event, dort heißt der Wert “ContextProcessId”. Durch diese Verbindung ist es möglich, alle zugehörigen DNS Requests eines Prozesses zu identifizieren, oder umgekehrt den verantwortlichen Prozess für einen spezifischen DNS Request.

Im zweiten Teil findet der Abgleich mit der Lookup-Datei statt. Diese enthält eine Liste an bekannten KI-Diensten und deren Domains. Mithilfe der match() Funktion wird das Feld DomainName aus dem DnsRequest Event abgeglichen.

Der letzte Teil der Query gruppiert und sortiert die Ausgabe der Ergebnisse. Um die Tabelle schnell auf bestimmte Hosts, AI-Services, Prozesse, oder Nutzer filtern zu können, werden diese Felder als Parameter definiert. Damit lässt sich die Query z.B. auch als Widget in ein Dashboard überführen. Hier werden nur die Ergebnisse der DNS Requests angezeigt, die Chrome.exe als Parent-Prozess haben:

Anpassung & Effizienz

Abschließend ein paar Hinweise zur Anwendung und Verbesserung solcher Queries. Gerade in diesem Beispiel werden eine hohe Anzahl an DNS Requests gegen eine ebenfalls hohe Anzahl an AI-Services abgeglichen. Aus diesem Grund ist es sinnvoll, den Suchzeitraum der Query einzuschränken, um die Performance zu erhöhen.

Sofern es genehmigte AI-Services gibt, sollten diese nicht in der Lookup-File geführt werden. Dadurch wird das unnötige Abgleichen der ohnehin erlaubten DNS-Requests erspart. Auch durch das Filtern von genehmigten oder bekannten SourceProcesses hilft bei der Reduktion der Ergebnisse. Hierzu zählen beispielsweise die Microsoft Prozesse (MsSense.exe, Copilot.exe, svchost.exe…).

ByteRay SIEM Services

Wenn Sie Transparenz über KI-Nutzung, Shadow-IT oder andere sicherheitsrelevante Aktivitäten in Ihrer Umgebung schaffen möchten, unterstützen wir Sie gerne bei der Erstellung, Validierung und Optimierung Ihrer SIEM Queries. In unserem SIEM Use-Case-Katalog pflegen wir über 300 Security- und Compliance-Use-Cases, die wir praxiserprobt haben und schnell auf individuelle Kundenumgebungen anpassen können.