Crowdstrike-Falcon ist eine hochentwickelte Sicherheits-Software, die Rechnersysteme in Echtzeit vor Cyberangriffen aller Art schützen und nicht als Quelle eines massiven Denial-of-Service-Angriffs dienen soll. Bemerkenswert ist, mit welcher Geschwindigkeit sich eine solche Schadsoftware inzwischen verbreiten kann: Laut den Crowdstrike-Stellungnahmen waren nur Windows-Systeme betroffen, die am 19. Juli in der Zeitspanne von 4:09 bis 5:27 Uhr UTC online waren und das Update von den Crowdstrike-Servern geladen haben. Positiv zu bewerten ist, dass schnell reagiert wurde und das fehlerhafte Update auf den Servern gelöscht wurde. Da vom BSoD auch Großbildschirme auf dem New Yorker Time Square, Anzeigen auf zahlreichen Flughäfen, Busstationen, Bahnhöfen sowie Selbstbedienungskassen in Supermärkten betroffen waren, verursachte dieser Crowdstrike-Vorfall so etwas wie die maximale Sichtbarkeit für ein Cybersicherheitsproblem.

Die Feinheiten von Falcon

Bild 1. Beispiel für ein funktionsredundantes IoT-Gateway: Zwei voneinander unabhängige Rechnersysteme (Sys1, Sys2), die über separate Spannungsversorgungen U1, U2 verfügen, sind mit dem gleichen lokalen OT-Netzwerk (OT-LAN) verbunden. Jedes Rechnersystem besitzt eine Wireless Wide Area Network (WWAN)-Schnittstelle, um dem IoT-Gateway per Mehrfachauslegung zwei unterschiedliche Verbindungsmöglichkeiten zu einer externen IoT-Plattform zu ermöglichen. © SSV Software Systems

Falcon wird überwiegend von größeren Unternehmen und Organisationen als Endpoint-Security-Plattform eingesetzt, um Malware, Zero-Day-Angriffe, verhaltensbasierte Besonderheiten (Anomalien) und andere Bedrohungen in Echtzeit zu erkennen, zu verhindern und kontextbezogen darauf reagieren zu können, aber auch, um beispielsweise ISO-27001-Compliance-Anforderungen zu erfüllen. Falcon lässt sich zusammen mit dem umfangreichen Zubehör daher auch als Enterprise Endpoint Detection and Response (EDR)-Software einordnen. Falcon basiert auf einer SaaS-Architektur mit agentenbasierter Sensorik in den Endpunkten vor Ort und erfordert daher eine Cloud-Anbindung dieser Endgeräte. Dafür wird eine Sensor-Softwarefunktion auf den Kundengeräten installiert, die Echtzeitdaten sammelt und hinsichtlich bestimmter Merkmale prüft. Werden verdächtige Aktivitäten erkannt, übermittelt der Agent die jeweiligen Daten zur weiteren Analyse an die Crowdstrike-Cloud. Dort erfolgen bei Bedarf die Anpassungen der Angriffserkennungsalgorithmen an neue Erkenntnisse und das Erzeugen sogenannter ‚Rapid Response Content Configuration Updates‘. Diese Updates werden von den Agenten teilweise mehrmals täglich automatisch heruntergeladen und installiert. Als Folge dieser Aktivitäten entsteht eine dynamische Angriffserkennung in den einzelnen Endpunkten.

Wie wurde getestet?

Bild2. Die Synchronisation der beiden Rechnersysteme (Sys1, Sys2) zu einem funktionsredundanten IoT-Gateway erfolgt mit Hilfe einer System-Watchdog-Software (SysWd). Diese verteilte Softwarefunktion orientiert sich für dieses Beispiel an einem vierstufigen Zustandsdiagramm. © SSV Software Systems

Wenn man sich ein Windows-Update vorstellt, dass man lediglich installieren muss, um sofort einen BSoD zu erzeugen, stellt man sich die Frage, ob überhaupt irgendetwas getestet wurde oder, ob nicht auch andere Ursachen in Frage kommen könnten. Dazu hat Crowdstrike inzwischen verschiedene Informationen veröffentlicht. Aus denen geht hervor, dass sehr umfangreiche Qualitätssicherungsmaßnahmen mit Unit- und Integration-Tests, aber auch Performance- und Stress-Tests angewendet werden (Crowdstrike-Tests).

Diese Tests werden aber bei Crowdstrike wohl nur für Sensor- und Treiber-Codes angewendet. Neben dem Code gibt es weitere Daten, den sogenannten Rapid Response Content. Das sind binäre Schlüssel-Wert-Paare, die vom Falcon-Sensor-Code zum Erkennen verdächtiger Aktivitäten genutzt werden. Diese Signaturdaten wurden wohl bisher nicht vollständig in die Code-orientierten Testkonzepte einbezogen, so dass fehlerhafte Daten einer sogenannten Channel-Datei letztendlich zum BSoD-Vorfall bei über 8 Millionen Windows-Rechnern geführt haben sollen.

Kunden, die Crowdstrike aus Compliance-Gründen einsetzen, werden sich in der Regel nicht allzu viele Gedanken über den Umfang und die Details der Update-Testprozesse machen. Im Umfeld der kritischen Infrastruktur muss man sich aber die Frage stellen, ob die Update-Tests auf der Anbieterseite ausreichen oder, ob vor dem Einsatz eines wie auch immer gearteten Updates, nicht auch auf der Anwenderseite im Rahmen angepasster CI/CD-Prozesse entsprechende Tests erforderlich sind, bevor eine neue IDS-Angriffserkennungsversion in die jeweiligen Sensoren eingespielt wird. Eigentlich ist ein zweistufiges Testkonzept notwendig: Der IDS-Partner erstellt ein Update und testet es gemäß dokumentierter Qualitätssicherungsmaßnahmen. Dann wird dieses Update an den Anwender übermittelt. Dort durchläuft die Softwarekomponente weitere Tests. Zeigen sich dabei keine Auffälligkeiten, kommt die Software zum Einsatz. Solche zweistufigen Software-Update-Testkonzepte verursachen zwar Mehrkosten, führen aber zu einem deutlich höheren Sicherheitsniveau.

Resilienzoptimierung und Redundanzüberprüfung

Eine effektive Cyberresilienz und die Erfüllung von Compliance-Anforderungen sind in der Praxis nicht unbedingt das gleiche. Daher waren vom Crowdstrike-Ausfall auch zahlreiche Organisationen betroffen, die der kritischen Infrastruktur zuzurechnen sind. Da in Deutschland derartige Vorfälle meldepflichtig sind (KRITIS-Verordnung und demnächst auch NIS-2), wurde das BSI eingeschaltet. Diese Bundesbehörde befasst sich inzwischen intensiv mit dem Crowdstrike-Vorfall und will zusammen mit den Verursachern auch für eine Resilienzoptimierung sorgen. Dazu wurde ein mehrstufiger Maßnahmenplan veröffentlicht, um wie es heißt „durch die Etablierung einer Zusammenarbeit des BSI mit Crowdstrike und Microsoft“ dabei zu helfen, deren EDR-Werkzeuge zu verbessern (BSI-Folgemaßnahmen).

Dass KRITIS-Organisationen überhaupt wichtige Funktionen mit Windows-Rechnern realisieren, die nur über eine Standard-EDR-Software mit automatischen Remote-Updates geschützt sind, stimmt nachdenklich. Es gibt mit dem derzeitigen Stand der Technik einige Optionen, die solche Betreiber neben einem zweistufigen Software-Update-Test einsetzen könnten, um sich besser gegen Totalausfälle zu schützen: A/B-Boot-Konzepte und systemredundante Anlagekonzepte sind Lösungen, die in anderen Bereichen zur Verbesserung der Ausfallsicherheit erfolgreich genutzt werden. Hierzu zwei Beispiele:

Der Autor: Klaus-Dieter Walter, SSV Software Systems © SSV Software Systems

• A/B-Bootstrategie: Damit wäre ein fehlerhaftes Update ohne nennenswerte Folgen für den operativen Betrieb geblieben, da statt der Bluescreen-Anzeige nach dem Booten der fehlerhaften Software-Partition einfach wieder der „alte“ unveränderte Software-Stack aktiviert wird.
• Redundanz: Die beiden Abbildungen illustrieren ein Funktionsredundanz-Beispiel zur Mehrfachauslegung einer IoT-Gateway-Funktionen durch zwei weitestgehend identische Rechnerbaugruppen, die sich mit Hilfe einer verteilten Watchdog-Anwendung synchronisieren. Bei einem Rechnerausfall wird automatisch umgeschaltet.

Wer oder was ist Crowdstrike?

Crowdstrike ist ein börsennotiertes US-amerikanisches Unternehmen für Cybersicherheitstechnologie mit ca. 8000 Mitarbeitern. Das Hauptprodukt bildet ein hybrides IDS mit dem Namen „Falcon“, um verschiedenartige Cyberangriffe in IT-Systemen mit Windows-, macOS- oder Linux-Betriebssystem zu erkennen. Crowdstrike selbst sieht sich als ein Marktführer für Plattformen zur „risikobasierten Schwachstellenverwaltung“. Als Anwendernutzen wird eine schnelle und skalierbare Bedrohungserkennung und -reaktion hervorgehoben. Dadurch können die zuständigen Sicherheitsteams vor Ort beim Anwender umgehend reagieren, kompromittierte Systeme isolieren und forensische Untersuchungen durchführen.

ah