Dieses Dokument ist eine Übersetzung der folgenden englischen Version https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/. Diese übersetzte Version dient ausschließlich der einfacheren Bezugnahme und Zweckmäßigkeit. Im Falle von Widersprüchen oder einer Unklarheit hat die englische Version stets Vorrang.
—
Aktualisiert am 26-07-2024 1915 UTC
Preliminary Post Incident Review (PIR)
Content Konfigurationsupdate mit Auswirkungen auf den Falcon-Sensor und das Windows-Betriebssystem (BSOD)
Dies ist die vorläufige Bewertung von CrowdStrike nach dem Vorfall (Post Incident Review, PIR). Einzelheiten unserer vollständigen Untersuchung werden in der bevorstehenden Ursachenanalyse (Root Cause Analysis, RCA) veröffentlicht. Zum besseren Verständnis verwenden wir in dieser PIR verallgemeinerte Terminologien zur Beschreibung der Falcon-Plattform. Die Terminologie in anderen Dokumentationen ist spezifischer und technischer.
Was ist passiert?
Am Freitag, den 19. Juli 2024 um 04:09 Uhr UTC, veröffentlichte CrowdStrike im Rahmen des regulären Betriebs ein Content- Konfigurationsupdate für den Windows-Sensor, um Telemetriedaten über mögliche neue Bedrohungstechniken zu sammeln.
Diese Updates sind ein kontinuierlicher Teil der Schutzmechanismen der Falcon-Plattform. Das problematische Konfigurationsupdate für Rapid Response Content führte zu einem Windows-Systemabsturz.
Zu den betroffenen Systemen gehören Windows-Hosts mit einer Sensor-Version 7.11 und höher, die zwischen Freitag, 19. Juli 2024 04:09 Uhr UTC und Freitag, 19. Juli 2024 05:27 Uhr UTC online waren und das Update erhielten. Mac- und Linux-Hosts waren nicht betroffen.
Der Fehler im Content-Update wurde am Freitag, 19. Juli 2024 um 05:27 Uhr UTC zurückgesetzt. Systeme, die nach diesem Zeitpunkt online gingen oder während des Zeitfensters keine Verbindung hatten, waren nicht betroffen.
Was ist schief gelaufen und warum?
CrowdStrike stellt Konfigurationsupdates von Sicherheitselementen für seine Sensoren auf zweierlei Weise bereit: Sensor-Content, der direkt mit unserem Sensor ausgeliefert wird, und Rapid Response Content, der entwickelt wird, um möglichst schnell auf die sich verändernde Bedrohungssituationen zu reagieren.
Das Problem am Freitag betraf ein Update von Rapid Response Content mit einem nicht erkannten Fehler.
Sensor-Content
Sensor-Content stellt ein breites Spektrum von Fähigkeiten zur Reaktion auf Angriffe zur Verfügung. Er ist immer Teil eines Sensor-Releases und wird nicht dynamisch aus der Cloud aktualisiert. Sensor-Content umfasst sensorinterne KI- und Machine-Learning-Modelle und besteht aus Code, der speziell geschrieben wurde, um den CrowdStrike Threat Detection Ingenieuren für die Erkennung von Bedrohungen langfristige, wiederverwendbare Funktionen bereitzustellen.
Zu diesen Funktionen gehören Template-Typen mit vordefinierten Feldern, die von Threat Detection Ingenieuren für Rapid Response Content genutzt werden können. Template-Typen werden in Code ausgedrückt. Der gesamte Sensor-Content, einschließlich der Template-Typen, durchläuft einen umfangreichen QA-Prozess, der automatisierte Tests, manuelle Tests, Validierungen und Rollout-Schritte beinhaltet.
Der Prozess des Sensor-Releases beginnt mit automatisierten Tests, sowohl vor als auch nach der Integration in unsere Codebasis. Dazu gehören Unit-Tests, Integrationstests, Performance-Tests und Stresstests. Dies führt zu einem stufenweisen Sensor-Rollout-Prozess, der mit internen Tests bei CrowdStrike beginnt, gefolgt von Early Adopters. Anschließend wird der Sensor allgemein für Kunden verfügbar gemacht. Kunden haben dann die Möglichkeit zu entscheiden, in welchen Teilen ihrer Umgebung die neueste Sensorversion (‚N‘), beziehungsweise die um eine Version ältere Version (‚N-1‘) oder die um zwei Versionen ältere Version (‚N-2‘) über entsprechende Sensorupdate-Policies installiert werden soll.
Der Vorfall vom Freitag, 19. Juli 2024, wurde nicht durch Sensor Content ausgelöst, der nur mit dem Release eines aktualisierten Falcon-Sensors bereitgestellt wird. Kunden haben die vollständige Kontrolle über die Bereitstellung des Sensors – einschließlich Sensor-Content und Template-Typen.
Rapid Response Content
Rapid Response Content wird verwendet, um eine Vielzahl von Operationen zum Abgleich von Verhaltensmustern auf dem Sensor mit Hilfe einer hochgradig optimierten Engine durchzuführen. Rapid Response Content ist eine Darstellung von Feldern und Werten mit zugehöriger Filterung. Dieser Rapid Response Content wird in einer proprietären Binärdatei gespeichert, die Konfigurationsdaten enthält. Es handelt sich weder um Code noch um einen Kernel-Treiber.
Rapid Response Content wird in Form von „Template-Instanzen“ bereitgestellt. Hierbei handelt es sich um die Instanziierung eines bestimmten Template-Typs. Jede Template-Instanz wird einem bestimmten Verhalten zugeordnet, das der Sensor beobachten, erkennen oder verhindern soll. Template-Instanzen verfügen über eine Reihe von Datenfeldern, die konfiguriert werden können, um das gewünschte Verhalten zu erzielen.
Mit anderen Worten: Template-Typen stellen eine Sensorfunktion dar, die neue Telemetrie und Erkennungsmechanismen ermöglicht. Ihr Laufzeitverhalten wird dynamisch von der Template-Instanz konfiguriert (d. h. von Rapid Response Content).
Rapid Response Content bietet Sichtbarkeit und Erkennung auf dem Sensor, ohne dass Änderungen des Sensorcodes erforderlich sind. Diese Funktion wird von Threat Detection Ingenieuren verwendet, um Telemetriedaten zu sammeln, Anzeichen für Angriffsverhalten zu identifizieren und Erkennungs- und Präventionsmaßnahmen durchzuführen. Rapid Response Content ist eine verhaltensbasierte Heuristik, die von den KI-Präventions- und Erkennungsfunktionen auf dem Sensor von CrowdStrike getrennt ist und sich davon unterscheidet.
Testen und Bereitstellen von Rapid Response Content
Rapid Response Content wird in Form von Content-Konfigurationsupdates für den Falcon-Sensor bereitgestellt. Es gibt dabei drei Hauptsysteme: das Content-Konfigurationssystem, den Content Interpreter und die Sensor Detection Engine.
Das Content-Konfigurationssystem ist Teil der Falcon-Plattform in der Cloud, während der Content Interpreter und die Sensor Detection Engine Bestandteile des Falcon-Sensors sind. Das Content-Konfigurationssystem wird verwendet, um Template-Instanzen zu erstellen, die über einen Mechanismus namens „Channel Files“ validiert und auf dem Sensor bereitgestellt werden. Der Sensor speichert und aktualisiert seine Content-Konfigurationsdaten über Channel Files, die auf die Festplatte des Hosts geschrieben werden.
Der Content Interpreter auf dem Sensor liest das Channel File und interpretiert den Rapid Response Content, wodurch die Sensor Detection Engine in die Lage versetzt wird, bösartige Aktivitäten zu beobachten, zu erkennen oder zu verhindern, abhängig von der Policy-Konfiguration des Kunden. Der Content Interpreter ist darauf ausgelegt, Fehler von potenziell problematischen Inhalten auf anwenderfreundliche Art und Weise zu verarbeiten.
Neu veröffentlichte Template-Typen werden in Bezug auf viele Aspekte wie Ressourcenauslastung, Auswirkungen auf die Systemleistung und Event-Volumen einem Stresstest unterzogen. Für jeden Template-Typ wird eine spezifische Template-Instanz für den Stresstest des Template-Typs verwendet, indem alle möglichen Werte der zugehörigen Datenfelder abgeglichen werden, um negative Systeminteraktionen zu identifizieren.
Template-Instanzen werden mit hilfe des Content-Konfigurationssystems erstellt und konfiguriert, zu dem auch der Content Validator gehört, der vor der Veröffentlichung Validierungschecks des Contents durchführt.
Zeitleiste des Vorfalls: Testen und Rollout des Template-Typs InterProcessCommunication (IPC)
Sensor-Content-Release: Am 28. Februar 2024 wurde den Kunden der Sensor 7.11 allgemein zur Verfügung gestellt. Damit wurde ein neuer IPC-Template-Typ eingeführt, um neue Angriffstechniken zu erkennen, die Named Pipes missbrauchen. Diese Veröffentlichung erfolgte nach allen Sensor-Content-Testverfahren, wie vorstehend im Abschnitt „Sensor-Content“ beschrieben.
Template-Typ Stresstest: Am 05. März 2024 wurde in unserer Staging-Umgebung, die aus einer Vielzahl von Betriebssystemen und Workloads besteht, ein Stresstest des IPC-Template-Typs durchgeführt. Der IPC-Template-Typ bestand den Stresstest und wurde zur Verwendung freigegeben.
Freigabe der Template-Instanz über Channel File 291: Am 05. März 2024 wurde im Anschluss an den erfolgreichen Stresstest eine IPC-Template-Instanz im Rahmen eines Content-Konfigurationsupdates für die Produktion freigegeben. Anschließend wurden zwischen dem 8. April 2024 und dem 24. April 2024 drei weitere IPC-Template-Instanzen bereitgestellt. Diese Template-Instanzen verhielten sich in der Produktion wie erwartet.
Was geschah am 19. Juli 2024?
Am 19. Juli 2024 wurden zwei weitere IPC-Template-Instanzen bereitgestellt. Aufgrund eines Fehlers im Content-Validator bestand eine der beiden Template-Instanzen die Validierung, obwohl sie problematische Content-Daten enthielt.
Auf der Grundlage der vor der ersten Bereitstellung des Template-Typs ( 5. März 2024) durchgeführten Tests, des Vertrauens in die vom Content-Validator durchgeführten Überprüfungen und früherer erfolgreicher Bereitstellungen von IPC-Template-Instanzen, wurden diese Instanzen in die Produktion übernommen.
Beim Empfang durch den Sensor und beim Laden in den Content Interpreter führte problematischer Content in der Channel-Datei 291 zu einem unzulässigen Speicherzugriff, der eine Exception auslöste. Diese unerwartete Exception konnte nicht auf anwenderfreundliche Art und Weise verarbeitet werden und führte zu einem Absturz des Windows-Betriebssystems (BSOD).
Wie verhindern wir, dass so etwas noch einmal passiert?
Resilienz und Testen von Software
• Verbesserung des Testens von Rapid Response Content, indem folgende Testtypen verwendet werden:
• Lokale Tests durch Entwickler
• Testen von Content-Updates und Rollbacks
• Stresstests, Fuzzing und Fault Injection
• Stabilitätstests
• Testen von Content-Schnittstellen
• Hinzufügen weiterer Validierungsprüfungen zum Content-Validator für Rapid Response Content. Ein neuer Check ist in Bearbeitung, um zu verhindern, dass diese Art von problematischen Inhalten in Zukunft veröffentlicht werden kann.
• Verbesserung der vorhandenen Fehlerbehandlung im Content Interpreter.
Bereitstellung von Rapid Response Content
• Implementierung einer gestaffelten Bereitstellungsstrategie für Rapid Response Content, bei der Updates schrittweise für größere Teile der Sensor-Basis bereitgestellt werden, beginnend mit einer Canary-Releasebereitstellung.
• Verbesserung der Überwachung von sowohl Sensor- als auch Systemleistung, indem während der Bereitstellung von Rapid Response Content Feedback gesammelt wird, um so einen schrittweisen Rollout zu steuern.
• Mehr Kontrolle unserer Kunden über die Bereitstellung von Rapid Response Content Updates, indem eine granularere Auswahl, wann und wo diese Updates bereitgestellt werden, ermöglicht wird.
• Details zu Content-Updates über Release-Notes bereitstellen, die Kunden abonnieren können.
Aktualisiert am 26-07-2024 1915 UTC
Validierung durch Dritte
• Durchführung mehrerer unabhängiger Sicherheitsüberprüfungen des Programmcodes durch Dritte.
• Durchführung unabhängiger Überprüfungen des gesamten Qualitätsprozesses, von der Entwicklung bis zur Bereitstellung.
Zusätzlich zu diesem vorläufigen Post Incident Review beabsichtigt CrowdStrike, die vollständige Ursachenanalyse (Root Cause Analyse) zu veröffentlichen, sobald die Untersuchung abgeschlossen ist.