Selbstverständlich haben wir in der Praxis seit Jahren bewährte (Industrie-)Standards für Security bei Design. Beispiele für allgemeine Vorgaben, die den gesamten Lebenszyklus eines Produkts beginnend mit den ersten Anforderungen abdecken, sind der Microsoft Security Development Lifecycle (SDL) [1] und die Special Publication 800-160 „Systems Security Engineering“ des National Institute of Standards and Technology (NIST) [2]. Außerdem gibt es auch sehr detaillierte Spezifikationen für Secure Coding und Security Testing, wie z.B. die SEI CERT Coding Standards [3] des Software Engineering Institute (SEI) der Carnegie Mellon University und den Web Security Testing Guide des Open Web Application Security Project (OWASP) [4].
Nun könnte man auf die Idee kommen, dass man auf diverse teure und aufwändige Maßnahmen der Informationssicherheit verzichten könnte, wenn man ausschließlich Produkte verwenden würde, die by Design sicher sind. Wenn diese Produkte dann sogar per Default sicher konfiguriert wären und der Nutzer eigentlich nichts mehr falsch machen kann, würde doch nicht mehr viel zu einer vollumfänglichen Sicherheit fehlen.
Dass dies eine höchst gefährliche Fehleinschätzung ist, zeigen folgende Beispiele.
Am 23. April 2020 hatte das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine Warnung für den Einsatz der iOS-App „Mail“ veröffentlicht [5]. Hintergrund war eine höchst interessante, neu festgestellte Schwachstelle. Alleine der Empfang einer bösartigen E-Mail (die E-Mail brauchte also vom Nutzer noch nicht einmal gelesen werden) konnte einem Angreifer potentiell den vollen Zugriff auf alle E-Mails auf einem iOS Smartphone oder Tablet ermöglichen. Dies ist ein GAU für die Informationssicherheit, der sogar seit ziemlich langer Zeit in iOS verborgen war. Die Empfehlung des BSI war an dieser Stelle klar: Weg mit der App bzw. automatisierte Synchronisation deaktivieren und ein anderes Mail-Tool installieren. Es dauerte dann in etwa einen Monat, bis Apple in der iOS-Version 13.5 unter anderem diese Schwachstelle behoben hatte.
Leider werden seit einiger Zeit immer häufiger unangenehme Schwachstellen für iOS festgestellt. Am 1. Mai gab es dann die Meldung, dass mit der neuen iOS-Version 13.5 (die zu dem Zeitpunkt der Meldung noch als Beta Release vorlag) auch eine andere Schwachstelle beseitigt ist. Hierbei konnte ein Angreifer Nachlässigkeiten beim Parsing von XML-Kommentaren geschickt so ausnutzen, dass er praktisch beliebige Berechtigungen erhält und sogar einen Ausbruch einer App aus der Sandbox möglich macht [6]. Diese Schwachstelle und die Technik der Ausnutzung (der sogenannte Exploit) waren dabei schon seit Jahren in hoffentlich nur gutwilligen Kreisen bekannt.
Also: Eine Woche nach GAU Nr. 1 gab es GAU Nr. 2, und man könnte diese beiden Beispiele sehr leicht um weitere spannende aktuelle Schwachstellen ergänzen.
Beide Beispiele haben eine ganze Menge mit Security by Design zu tun. Ein Kernelement von Security by Design ist eine konsequente Input Validation zumindest aller externen Schnittstellen. Wären hier keine Fehler gewesen, hätte es die beiden Schwachstellen nicht gegeben. Also hat hier anscheinend die Software-Entwicklung geschlampt und das nachhaltig, denn zumindest über die XML-spezifische Schwachstelle im zweiten Beispiel wurde Apple durch den Entdecker der Schwachstelle frühzeitig informiert.
Nun ist Apple schon sehr sehr lange keine Garagenfirma mehr und stellt entsprechend lange professionell Software her. Es ist daher nicht überraschend, dass für iOS auch Security by Design eine sichtbare Rolle spielt und Apple auch ein entsprechendes Konzept hat [7]. Wie konnte es also zu den betrachteten Schwachstellen kommen? Einerseits reduziert Security by Design lediglich die Anzahl von Schwachstellen, und andererseits kommt es in der Praxis immer wieder vor, dass die Informationssicherheit trotz schöner Richtlinien, Konzepte, Prozesse und Arbeitsanweisungen aus Zeit- und Kapazitätsgründen auf der Strecke bleibt.
Wir müssen also als Nutzer von IT-Anwendungen und IT-Systemen leider akzeptieren, dass wir mit Schwachstellen in Produkten mal mehr und mal weniger intensiv leben müssen. Hier ist es ähnlich zum Qualitätsmanagement z.B. nach ISO 9001: Auch ein nach allen Regeln der Kunst qualitätsgesichertes System kann erhebliche Mängel aufweisen, die erst später im Einsatz auffallen.
Security by Design bleibt aber trotz allem ein ganz entscheidender Baustein der Informationssicherheit, und bei der Beschaffung eines IT-Produkts ist eine Prüfung des jeweiligen Produkts bzw. des Herstellers auf Security by Design essentiell. Wie wird die Software bzw. das System entwickelt und gewartet, wie wird dabei die Informationssicherheit berücksichtigt? Das sind Punkte, die bei einer Beschaffung (und nachhaltig im Einsatz der jeweiligen Lösung) stets systematisch abgefragt und bewertet werden sollten.
Ein wichtiger Parameter ist dabei auch die Betrachtung der über einen längeren Zeitraum für ein Produkt gemeldeten Schwachstellen und die Dauer bis zur Behebung durch den Hersteller. Es existiert aber noch eine weitere höchst interessante Kennzahl, die eine Aussage über die Güte von Security by Design eines Produkts ermöglicht. Es gibt nämlich Unternehmen, die Zero Day Exploits aufkaufen (und dieses Wissen dann natürlich entsprechend weiter verkaufen). Ein Beispiel ist die Firma Zerodium [8]. Zerodium hat am 13. Mai mitgeteilt, dass aufgrund der Masse an aktuell verfügbaren schwerwiegenden Zero Day Exploits für iOS erst einmal auf den Einkauf weiterer Exploits verzichtet wird und künftig ein deutlich geringerer Preis gezahlt werden würde [9]. Ein hoher Preis für einen Zero Day Exploit ist also durchaus ein Indikator für eine gute Qualität der Informationssicherheit des jeweiligen Produkts.
Verweise
[1] Siehe https://www.microsoft.com/en-us/securityengineering/sdl
[2] Siehe https://csrc.nist.gov/publications/detail/sp/800-160/vol-1/final
[3] Siehe https://wiki.sei.cmu.edu/confluence/display/seccode/SEI%20CERT%20Coding%20Standards
[4] Siehe https://owasp.org/www-project-web-security-testing-guide/
[5] Siehe https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2020/Warnung_iOS-Mail_230420.html
[6] Siehe https://siguza.github.io/psychicpaper/
[7] Siehe https://www.apple.com/business/docs/site/AAW_Platform_Security.pdf und https://www.apple.com/de/business/docs/site/iOS_Security_Guide.pdf
[8] Siehe https://zerodium.com/
[9] Siehe https://twitter.com/Zerodium/status/1260541578747064326
