KI-Bedrohungen entwickeln sich rasant. Ihre Verteidigung sollte das auch tun.

Kürzlich hat Vincent Danen von Red Hat hervorgehoben, wie KI-Modelle während der Zusammenarbeit von Mozilla mit Anthropic 271 echte Sicherheitsmängel in Firefox in einem einzigen Durchlauf fanden. Wenn eine KI das für die Verteidigung leisten kann, kann sie das Gleiche für Angreifende tun. Wie Danen es formulierte: „Wenn Ihre Sicherheitsstrategie ausschließlich auf der Annahme basiert, dass Software frei von Schwachstellen ist, haben Sie bereits verloren.“ 

Schwachstellen im Code sind nur der Einstieg. Der eigentliche Schaden entsteht erst danach – durch Lateral Movement in falsch konfigurierten Netzwerken, überprivilegierte Zugangsdaten, nicht rotierte Secrets und Services, die sich gegenseitig blind vertrauen. Da kann kein Patch-Zyklus mithalten. Dies unterstreicht die Notwendigkeit für eine umfassendere „Defense in Depth (Tiefenverteidigung)“ in Unternehmen – ein kultureller Wandel, der davon ausgeht, dass eine Kompromittierung wahrscheinlich ist, und sich darauf konzentriert, die Auswirkungen der Gefährdung selbst zu reduzieren. 

Dies ist die Definition von Zero Trust. Dieser ersten Welle von Sicherheitsschwachstellen folgen eine zweite und dritte. Unternehmen müssen Zero Trust einführen, um von der reinen Prävention zur Eindämmung von Sicherheitsverletzungen überzugehen. Dabei setzen sie Least Privilege-Prinzipien für Identitäten, Secrets, Netzwerksegmentierung und Richtlinien auf jeder Ebene durch. Unternehmen benötigen eine automatisierte Durchsetzung, die im Tempo dieser KI-gesteuerten Bedrohungen ausgeführt wird. Red Hat Ansible Automation Platform macht dies möglich.

Die Verschiebung der KI-Angriffsoberfläche

Herkömmliche Schwachstellenscanner identifizieren potenzielle Probleme und übergeben sie zur Selektierung an eine Fachkraft. KI hat Cyberangriffe zu einem Massenphänomen gemacht. Die heutigen KI-Tools sind im Grunde genommen ein ganzes Team in einer Lösung, und das alles zum Preis von Tokens. Während verheerende Sicherheitsverletzungen wie SolarWinds Zeit, tiefgreifendes Fachwissen und Glück erforderten, ermöglicht KI nun motivierten Angreifenden, komplexe, plattformübergreifende Schwachstellen mühelos zu verketten.

Diese scheinbar kleinen Schwächen summieren sich und sind nicht zu Ihrem Vorteil. Zum Beispiel:

• Eine Anmeldeseite, auf der Sie Passwörter zu schnell nacheinander eingeben können
• Eine Einstellungsseite, auf der Ihre Identität nicht erneut überprüft wird
• Eine API, die während der Abmeldung kurzzeitig ein Sitzungstoken offenlegt

Keine dieser Bedrohungen ist für sich allein übermäßig gefährlich. Einzeln betrachtet würde jeder dieser Fehler mit „niedriger Priorität“ im Backlog verweilen. Miteinander verkettet könnten sie es Angreifenden jedoch ermöglichen, ein Passwort mittels Brute-Force zu knacken, die Session vor deren Ablauf zu übernehmen und als Administrator auf die Einstellungsseite zu gelangen. 3 kleine Bugs, und doch gelingt ein funktionaler Einbruch.

Diese fortgeschrittenen KI-Modelle schreiben, kompilieren und führen Exploit-Code aus und verwenden dabei Fehler-Outputs, um ihre Angriffe iterativ zu verfeinern und zu wiederholen. Unternehmen nutzen dies zu ihrem Vorteil, indem sie bisher unbekannte Schwachstellen schnell finden und beheben. Die unangenehme Wahrheit ist jedoch, dass diese Funktionen auch Angreifenden zur Verfügung stehen. Wie Danen schrieb: „Die gleichen Tools, mit denen die Sicherheitsteams Bugs finden, helfen unweigerlich auch Angreifenden, sie zu finden.“ Die Messlatte für das notwendige Fachwissen von Angreifern ist gerade gesunken. Schnelleres Patching ist ein Teil der Lösung, muss aber durch gute Sicherheitsmaßnahmen ergänzt werden. 

Verteidigung benötigt eine automatisierte operative Schicht

Red Hat Enterprise Linux mit SELinux und Red Hat OpenShift bieten bereits eine Härtung auf Plattformebene, allerdings müssen Sie diese Abwehrmaßnahmen noch ergänzen. So entscheidet SELinux zum Beispiel nicht, wer eine Anwendung bereitstellen darf. Die Container-Isolierung sperrt keine Datenbank-Zugangsdaten, wenn ein SIEM-System (Security Information and Event Management) um 3.00 Uhr morgens einen Brute-Force-Angriff erkennt. Diese Rollen kann die Automatisierung übernehmen, wenn Sie eine effektive Verteidigungsstrategie entwickeln. 

Operative Änderungen (Deployments, Patches, Netzwerkneukonfigurationen, Rotation von Zugangsdaten) erfolgen über Mitarbeitende, Skripte, Pipelines und Automatisierung. Wenn Richtlinien diese Pfade nicht absichern, schützt Sie die Plattformhärtung vor einer bestimmten Klasse von Angriffen, während sie aber für eine andere weit offen bleibt. 

NIST SP 800-207 legt den Blueprint der Zero Trust-Architektur (ZTA) fest, und in der Mitte befindet sich der Policy Enforcement Point (PEP). Die meisten IT-Teams stellen sich den PEP als eine Firewall oder ein Gateway vor, das den Netzwerkdatenverkehr filtert. Wenn Teams jedoch Anwendungen bereitstellen, Server patchen und Netzwerkkonfigurationen ändern, laufen diese Aktionen nicht durch eine Firewall, sondern durch die Automatisierung. Letztendlich ist Zero Trust eine operative Disziplin, die eine skalierbare Automatisierung im großem Umfang erfordert.

Ansible Automation Platform als Policy Enforcement Point (PEP)

Wenn Ansible Automation Platform als PEP fungiert, durchlaufen operative Aktionen eine Plattform, die Identitäten überprüft, Richtlinien bewertet, Secrets verwaltet und das Ergebnis protokolliert. Dabei handelt es sich nicht um erweiterte Funktionen, sondern um die für Zero Trust erforderlichen Mindestkontrollen. Der Operator greift niemals direkt auf das Zielsystem zu. Ansible Playbooks übernehmen dies und werden erst ausgeführt, nachdem die Plattform die Autorisierung des Operators bestätigt hat.

Der architektonische Vorteil ist eine zentralisierte Durchsetzung bei verteilter Ausführung. Richtlinienentscheidungen werden auf einer einzigen Control Plane getroffen, die Durchsetzung findet jedoch dort statt, wo die Automatisierung ausgeführt wird. Es gibt keine direkte Verbindung zu Servern und es werden keine Skripte von Laptops aus ausgeführt, was die Risiken von „Cowboy-Engineering“ und nicht nachverfolgbarem Konfigurationsdrift verringert. Dies adressiert auch Anti-Patterns wie ausufernde Zugangsdaten, Schattenautomatisierung oder unkontrollierte Lateral Movements.

Diese Architektur entschärft kritische Sicherheitslücken, da sie hochprivilegierte Produktionszugangsdaten auf anfälligen lokalen Endpunkten eliminiert. Die Automatisierungsplattform dient als zentraler Kontrollpunkt, und jede Änderung umfasst eine Identität, eine Richtliniengenehmigung sowie einen Audit-Datensatz. 

Ansible Automation Platform kann dies über ein Dual Ring-Enforcement-Modell implementieren. Der äußere Ring arbeitet auf Plattformebene. Bevor ein Job-Template startet, fragt Ansible Automation Platform den OPA-Server (Open Policy Agent) über die integrierte Funktion zur Richtliniendurchsetzung mit dem vollständigen Jobkontext ab: wer diesen startet, zu welchem Team die Person gehört und welches Template sie ausführt. 

Abb. 1: Richtliniendurchsetzung im äußeren und inneren Ring mit Ansible Automation Platform

OPA prüft die Anforderung anhand der Richtlinie und lässt diese zu oder lehnt sie ab. Das Playbook wird nicht ausgeführt, wenn der äußere Ring die Anfrage ablehnt. Die OPA-Richtlinie ordnet die Teammitgliedschaft zulässigen Template-Kategorien zu.

package aap.gateway
import rego.v1
default decision := {"allowed": true, "violations": []} 
patching_teams := {"Infrastructure", "Security"} 
network_teams := {"Infrastructure"} 
app_teams := {"Applications", "DevOps"} 
user_teams := {name | name := input.created_by.teams[_].name} 
decision := {
    "allowed": false,
    "violations": [sprintf(
        "user '%s' is not in an authorised team for patching templates (requires: %v, has: %v)",
        [input.created_by.username, patching_teams, user_teams],
    )],
} if {
    not input.created_by.is_superuser
    is_patching_template
    not team_match(patching_teams)
}

Abb. 2: Beispiel für eine Rego-Richtlinie für den Policy as Code Check

Der innere Ring agiert innerhalb der Vorlage bzw. des Workflows selbst. Bei Vorgängen mit potenziell weitreichenden Auswirkungen wie VLAN-Änderungen ruft das Playbook eine SPIFFE-Identität (eine kryptografische Workload-Identität) ab und sendet sie an OPA. OPA wertet 3 Bedingungen aus: 

• Die Teammitgliedschaft autorisiert die Person
• Die Workload ist über die SPIFFE Verifiable Identity legitim
• Die angeforderte Änderung liegt innerhalb eines genehmigten Bereichs

Alle 3 Bedingungen müssen erfüllt sein.

Abb. 3: Beispiel für mehrere Richtliniendurchsetzungen mit Ansible Automation Platform

Dies ist bei KI-gesteuerten Angriffen wichtig, da die Exploit-Kette am Durchsetzungspunkt, nicht an der Schwachstelle, unterbrochen wird. Ein KI-Agent, der Bugs verkettet, um Zugriff auf einen Server zu erhalten, bleibt auf der Data Plane hängen. Dort verhindern Zero Trust-Richtlinien wie Netzwerk-Mikrosegmentierung und kurzlebige Zugangsdaten den externen Zugriff oder Lateral Movement. Er kann weder Ihr Deployment missbrauchen, um bösartige Anwendungen bereitzustellen, noch die Netzwerkrichtlinien des Unternehmens ändern, ohne Ansible Automation Platform zu durchlaufen. Sobald eine lokale Kompromittierung erkannt wird, kann Event-Driven Ansible, das in Ansible Automation Platform enthalten ist, das System automatisch isolieren und Ihren Sicherheitsteams unmittelbaren Kontext bereitstellen.

Gestohlene Anmeldedaten von Nutzenden bestehen die SPIFFE-Prüfung nicht, da die Workload-Identität nicht übereinstimmt. Ein kompromittierter Automatisierungsknoten besteht die Prüfung der Teammitgliedschaft nicht, da Angreifende die Session von Ansible Automation Platform der Nutzenden nicht kontrollieren. Die einzelnen Ringe sind unabhängig voneinander. Die Kompromittierung eines einzelnen Rings reicht nicht aus. Dies demonstriert das Prinzip der Tiefenverteidigung (Defense in Depth) in der Praxis.

Potenzielle Auswirkungen durch dynamische Anmeldedaten und Mikrosegmentierung reduzieren

Selbst wenn Richtlinien auf der Automatisierungsebene durchgesetzt werden, bleiben Anmeldedaten und Netzwerkpfade eine Angriffsfläche. Werden Datenbankpasswörter monatlich rotiert, haben Angreifende, die Zugriff erhalten, ein Zeitfenster von einem Monat. Sind Network Access Control Lists (ACLs) zwischen Anwendungs- und Datenbank-Tiers dauerhaft geöffnet, ist der Pfad stets verfügbar.

Bei der Ausführung eines Workflows für das Anwendungs-Deployment kann Ansible Automation Platform dynamische Datenbank-Anmeldedaten von HashiCorp Vault anfordern. Dabei handelt es sich um eine PostgreSQL-Rolle, die auf das Schema der Anwendung beschränkt ist und eine Time-to-Live (TTL) von 5 Minuten besitzt. Die Anmeldedaten existieren nur während des Deployment-Fensters. Mit Ablauf der TTL wird die Rolle gelöscht. Es gibt keine zu stehlenden Daten, da nichts persistent ist.

Im selben Workflow konfiguriert Ansible Automation Platform das Netzwerk so, dass ein ACL-Eintrag geöffnet wird, um Datenverkehr von der IP-Adresse der Anwendung zum Datenbankport zu ermöglichen.

Bei KI-Exploit-Ketten ändert dies die Art des Angriffs. Tools können zwar Schwachstellen verketten, um eine Datenbankebene zu erreichen, finden jedoch nur Anmeldedaten vor, die bereits vor 4 Minuten abgelaufen sind. Das Zeitfenster für eine Ausnutzung verringert sich von „bis das Passwort rotiert wird“ auf „bis die Automatisierung abgeschlossen ist“ – also auf Minuten statt Monate. Beim Betrieb der Anwendung in der Produktion übernimmt der Vault-Agent den fortlaufenden Lifecycle der Anmeldedaten.

Incident Response in Maschinengeschwindigkeit

Wenn KI-Agenten Exploits generieren und verketten können, arbeiten Analysierende im Security Operations Center (SOC), die benachrichtigt werden, sich anmelden und Anmeldedaten manuell widerrufen, in einem menschlichen Zeitrahmen. Dies ist gegenüber digitalen Bedrohungen oft zu langsam.

Event-Driven Ansible hilft, diese Lücke zu schließen. Ein SIEM wie Splunk erkennt ein Brute-Force-Muster am Authentifizierungsendpunkt einer Anwendung. Splunk kann über einen Event-Stream eine Warnung an Event-Driven Ansible auslösen. Event-Driven Ansible wertet das Ereignis aus und startet einen Automatisierungsjob, um entsprechende Maßnahmen zu ergreifen. Dieser Job ruft die API von HashiCorp Vault auf, um alle aktiven dynamischen Datenbank-Leases der Anwendung zu widerrufen. Die Anwendung verliert umgehend die Verbindung zur Datenbank.

—  
  name: Splunk Brute-Force credential revocation
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000
  rules:
    - name: Revoke credentials on SSH brute-force detection
      condition: event.payload.search_name is search("SSH Brute Force Detected")
      action:
        run_job_template:
          name: "Emergency: Revoke App Credentials"
          organization: Default

Abb. 4: Beispiel für ein Event-Driven Ansible Rulebook für Brute-Force-Ereignisse von Splunk
 

Die Schleife von der Erkennung bis zur Eingrenzung ist in Sekunden abgeschlossen, wodurch sich die durchschnittliche Zeit bis zur Fehlerbehebung von Stunden auf Sekunden verkürzt. Die potenziellen Auswirkungen verringern sich von „Angreifer hat möglicherweise Datenbankzugriff“ auf „Angreifer hat Zugriff auf eine Anwendung, die ihre Daten nicht mehr erreichen kann“.

Abb. 5: Beispiel für eine Incident Response auf Angriffe für eine Zero Trust-Architektur mit Event-Driven Ansible
 

Hierbei handelt es sich um eine automatisierte Eingrenzung, auf die eine manuelle Wiederherstellung folgen kann. Event-Driven Ansible kann Anmeldedaten ohne menschliche Genehmigung widerrufen, da der Widerruf eine sichere Standardeinstellung ist – die Anwendung stellt keine Daten mehr bereit, es wird jedoch nichts zerstört. Für die Wiederherstellung müssen Mitarbeitende den Vorfall untersuchen, die Behebung der Bedrohung bestätigen und einen Restore-Workflow starten, der die Anwendung neu bereitstellt. Der Checkpoint im Wiederherstellungspfad ist vorhanden, da Sie den Zugriff nach einer Kompromittierung nicht ohne menschliche Untersuchung automatisiert wiederherstellen sollten.

Mehrere Schichten, eine Verteidigung

Die KI-gestützte Erkennung von Schwachstellen macht Tiefenverteidigung unverzichtbar. Doch Tiefenverteidigung ohne eine automatisierte Betriebsebene lässt eine Lücke offen, die Angriffe in Maschinengeschwindigkeit ausnutzen werden.

Drei Schichten können diese Lücke schließen und die KI-Exploit-Kette an jeweils unterschiedlichen Punkten unterbrechen:

• Plattformhärtung (Compiler-Flags, SELinux, Container-Isolierung, Address Space Layout Randomization (ASLR)) erschwert die Ausnutzung des ursprünglichen Fehlers. Ein KI-Modell findet möglicherweise die Schwachstelle, doch die gehärtete Plattform erzwingt eine mehrstufige Kette, nur um Code auszuführen.
• Die Durchsetzung von Richtlinien mit Ansible Automation Platform blockiert unautorisierte operative Pfade. Selbst wenn die Exploit-Kette erfolgreich ist, können Angreifende keine Secrets bereitstellen, patchen, neu konfigurieren oder darauf zugreifen, ohne die Control Plane der Automatisierung zu durchlaufen. Gestohlene Zugangsdaten allein reichen nicht aus.
• Die automatisierte Reaktion mit Event-Driven Ansible hilft, Sicherheitsverletzungen einzudämmen, bevor Lateral Movement einsetzt. Detection-to-Containment in Sekunden entspricht der Geschwindigkeit von KI-gesteuerten Angriffen auf eine Weise, die mit manuellen Reaktionen nicht möglich ist.

Die einzelnen Schichten arbeiten unabhängig voneinander. Die Plattformhärtung hängt nicht von der Durchsetzung von Richtlinien ab. Die Durchsetzung von Richtlinien hängt nicht von der automatisierten Reaktion ab. Wenn eine einzelne Schicht ausfällt, begrenzen die anderen 2 dennoch den Schaden. Dank dieser Unabhängigkeit können Sicherheitsteams ihre Zeit für die strategische Risikominderung nutzen, anstatt Warnmeldungen zu verfolgen. Zudem können Unternehmen KI-gestützte Abläufe mit Zuversicht einführen, da die Schutzmaßnahmen auch dann greifen, wenn sich die Tools schneller als die Richtlinien entwickeln.

Die meisten Unternehmen verfügen über eine Plattformhärtung. Viele führen Zero Trust-Prinzipien ein. Nur wenige Unternehmen haben die Durchsetzung und Automatisierung in der Geschwindigkeit miteinander verbunden, wie es diese Bedrohungen erfordern. In dieser Lücke wird die nächste Sicherheitsverletzung entstehen. Durch die Kombination der 3 oben beschriebenen Schichten stärken Sie Ihre Abwehr gegen die Gefahr von KI-gesteuerten Angriffen.  

Ressourcen

• Webinar: Zero Trust mit Red Hat Ansible Automation Platform implementieren
• Webinar: Sicherheit automatisieren. ITOps abstimmen
• E-Book: Sicherheit automatisieren zur Vereinfachung der Unternehmens-ITSeite verfügbar in Englisch (Deutsch ist nicht verfügbar)
• E-Book: Red Hat Ansible Automation Platform – ein Guide für den Einstieg
• Interaktiver Walkthrough: IT-Automatisierung einschließlich Sicherheitsautomatisierung
• Webseite: Sicherheitsautomatisierung