Zu Beginn des neuen Jahres ging es dann mit den Attacken Meltdown und Spectre Schlag auf Schlag [2]. Angefangen damit, dass eine riesige Anzahl von Systemen mit Prozessoren von Intel betroffen war, mussten auch andere Prozessorhersteller wie AMD eingestehen, dass es auch sie erwischt hat. Schnell wurde klar, dass es sich hier um einen GAU der Informationssicherheit handelt, der praktisch jeden getroffen hat, von Cloud- und Server-Landschaften bis hin zu PCs, Tablets und Smartphones. Die Folgen sind bis heute zu sehen: hektische Bereitstellung von Patches, feststellen, dass die Patches nicht ordentlich funktionieren bzw. die Performance der Systeme drastisch reduzieren, Warnung vor der Installation von Patches, Rückruf von Patches (3], kurz: Panik.
Zunächst ist folgendes klar: Je komplexer und insbesondere intelligenter Systeme werden, desto größer wird die Wahrscheinlichkeit von Schwachstellen. Meltdown und Spectre sind außerdem ein klassisches Ying-und-Yang-Problem nicht nur der Informationstechnik: Eine Funktion, die viel Nutzen bringen kann, kann auch viel Schaden anrichten.
Interessant ist vielleicht nur, dass es hier den Prozessor erwischt hat. Bei Betriebssystemen und sonstiger Software haben wir uns ja längst dran gewöhnt. Bis wir neue Prozessoren haben, die immun gegen Meltdown, Spectre und ihren Varianten sind, geht der schwarze Peter an die Hersteller von Virtualisierungslösungen und Betriebssystemen (und den Nutzer, der mit Unbequemlichkeiten und eingeschränkter Performance leben muss). Da die Prozessoren aber weiterhin immer intelligenter werden, wird sich dies als Zyklus früher oder später wiederholen.
Aus dem Blickwinkel Informationssicherheit heißt das:
- Wer ein solides Schwachstellenmanagement als Bestandteil eines ordentlichen Information Security Management System (ISMS) etabliert hat, wird weitermachen wie bisher, es wird halt etwas turbulenter: Schwachstelle aufnehmen, Risiken analysieren, Patches (und die damit verbundenen Seiteneffekte) bewerten und ggf. einspielen, verbleibende Risiken durch Maßnahmen reduzieren oder akzeptieren und die Schwachstelle weiter im Auge behalten, bis sie als beseitigt angesehen werden kann.
- Angriffsfläche reduzieren: Wenn auf einem Virtualisierungs-Host ein Angriff der Form Meltdown und Spectre erfolgreich durchgeführt würde, können letztendlich alle VMs auf dem Host kompromittiert werden. Die Anforderung, für Internet DMZs und interne Zonen unterschiedliche physische Infrastrukturen (inklusive Virtualisierungs-Hosts) zu verwenden [4], hat daher Bestand. Die Empfehlung, ab einer gewissen kritischen Masse von besonders schützenswerten / kritischen internen Systemen auch diese auf dedizierten Virtualisierungs-Hosts für kritische Systeme laufen zu lassen [5], hat ebenfalls Bestand.
Wir hatten interessanterweise ähnliche Diskussionen hinsichtlich Schwachstellen in Prozessoren in den Seminaren und Sonderveranstaltungen der ComConsult im vierten Quartal 2017. Hier ging es im Detail um die Funktionen Intel Software Guard Extensions (SGX), AMD Secure Memory Encryption (SME) und AMD Secure Encrypted Virtualization (SEV), die es durch Verschlüsselung auf Ebene der Prozessoren ermöglichen würden Cloud-Infrastrukturen wesentlich besser absichern zu können [6]. Die Befürchtung war aber, dass mit diesen komplexen Funktionen auch Fehler auftreten können, die sich als Schwachstellen ausnutzen lassen. Wenn beispielsweise eine komplette VM mit SEV verschlüsselt wird und nur der Prozessor, der die VM gerade ausführt, den Schlüssel kennt, wie erfolgt dann die Migration einer VM im laufenden Betrieb zu einem anderen Prozessor, ohne dass es hier zu einer Schwäche in der Informationssicherheit kommt? Meltdown und Spectre haben nun drastisch demonstriert, wie berechtigt solche Befürchtungen sind.
Verweise
[1] Siehe z.B. https://gruss.cc/files/kaiser.pdf
[2] Siehe z.B. https://meltdownattack.com/ und https://www.bsi-fuer-buerger.de/BSIFB/DE/Service/Aktuell/Informationen/Artikel/Meltdown_Spectre_Sicherheitsluecke_10012018.html
[3] Siehe https://support.microsoft.com/en-us/help/4078130/update-to-disable-mitigation-against-spectre-variant-2
[4] Siehe Baustein NET.1.1 „Netzarchitektur und –design“ des BSI IT-Grundschutz-Kompendiums, verfügbar unter: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKompendium/bausteine/NET/NET_1_1_Netzarchitektur_und_-design.html
[5] Siehe Allianz für Cyber-Sicherheit, Server-Virtualisierung v1.0, verfügbar unter https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-CS_113.html
[6] Siehe „Verschlüsselung in der Cloud: Licht am Ende des Tunnels“ aus der „Der Netzwerk Insider“ vom Oktober 2017, verfügbar unter https://www.comconsult-research.de/standpunkt-2/
