DIE HERAUSFORDERUNGEN DER KOMPONENTENZIERUNG FÜR SICHERHEIT UND TEAMBILDUNG

Quelle: Zeitschrift der brasilianischen Computergesellschaft

Artikel von Roberto Gallo

Die Sicherheit eines Systems hängt immer von der Sicherheit seiner Komponenten ab. Obwohl diese Aussage scheinbar einfach und durch gesunden Menschenverstand gestützt ist, verbirgt sich hinter ihr eine ganze Reihe von Faktoren, die selbst für die kompetentesten Teams bei der Konzeption, Entwicklung, Bereitstellung und Wartung von Computersystemen eine Herausforderung darstellen, wenn es darum geht, diese während ihres gesamten Lebenszyklus sicher zu halten.

Durch die Untersuchung der Literatur, bekannter Schwachstellen-Repositories (von MITRE verwaltete CVE-Videos) und sogar der Medien zu diesem Thema können wir bedeutende Fälle identifizieren, in denen ein Aspekt der Systemkomponentenbildung zu Sicherheitsproblemen geführt hat, die möglicherweise durch eine stärkere Verbreitung von Sicherheitswissen an die Designteams von Computersystemen hätten vermieden werden können.

Einige bemerkenswerte Beispiele sind:

die Supply-Chain-Angriffe auf SolarWinds Orion und der XZ-Ausbruch (CVE-2024-3094), bei denen diese von anderen Lösungen verwendeten Komponenten unterwandert wurden,

Gefährdung der Systeme, die sie verwenden;

die Downfall-Seitenkanalangriffe auf Intel-CPUs (CVE-2023-12301), Inception auf AMD-CPUs (CVE-2023-12302) und in jüngerer Zeit der GoFetch-Angriff

unter CPU Apple Mx (2024), die den Verlust von Informationen (kryptografischen Schlüsseln) zwischen Prozessen (Komponenten) eines Systems ermöglichte;

die Fälle unzureichender Architektur in Kombination mit einer Fehlkonfiguration von Amazon S3-Buckets, die zu berühmten Datenlecks führten, wie etwa dem 1-TB-Leck von Attunity im Jahr 2019 und dem Leck von 100 Millionen Capital One-Kunden im Jahr 2019.

In diesem Artikel untersuchen wir die Gemeinsamkeiten mehrerer Fälle von Sicherheitsmängeln, die auf den ersten Blick recht unterschiedlich erscheinen, deren Ursache und Reaktion jedoch in der Organisation und den koordinierten Aktionen der verschiedenen Teams liegt, die für die Entwicklung, Beschaffung, Integration und Prüfung der Systeme und der zugehörigen Komponenten verantwortlich sind.

Einige Probleme mit der Komponentenbildung

Die Modularisierung von Systemen in Form von Komponenten hat zahlreiche Vorteile, die sowohl in der Wissenschaft als auch in der Industrie weithin bekannt und verbreitet sind, insbesondere die Erleichterung von Wartung und Tests, Wiederverwendbarkeit, Kosten- und Risikoreduzierung sowie die Skalierbarkeit des Systems und des Entwicklungsprozesses [1].

Diese Vorteile bleiben jedoch weder den intrinsischen theoretischen Grundlagen der Informatik noch den alltäglichen konkreten Phänomenen verborgen, die Bedrohungsquellen darstellen und die überraschenderweise in der Denkweise vieler Absolventen einer Hochschulausbildung im Bereich Informatik nicht verankert sind. Als nächstes, in zusammengefasster Form im Namen der Aufgrund des begrenzten Platzes in dieser Veröffentlichung liste ich einige der wichtigsten auf:

1. Der für die Informatik grundlegende Satz von Rice besagt, dass jede nicht-triviale Eigenschaft von Programmen unentscheidbar ist. Dies bedeutet, dass es keinen allgemeinen Algorithmus gibt, der für jedes Programm und jede mögliche Eingabe entscheiden kann, ob es eine bestimmte Verhaltenseigenschaft aufweist, die beispielsweise die Ausführung einer unsicheren Operation nicht zulässt. In der Praxis bedeutet dies, dass die Programmsicherheitstests nur eine begrenzte Aussagekraft haben, fallbezogen sind und notwendigerweise durch heuristische Methoden unterstützt werden.

Darüber hinaus hegen viele Entwickler trotz ihrer Klassiker und Bekanntheit immer noch die Illusion, dass manche Technologien Allheilmittel seien, wie etwa Virtualisierungsplattformen.

Das Zusammenstellen von Sicherheitsrichtlinien ist sehr schwierig: Die Zusammensetzung der einzelnen Sicherheitsrichtlinien von Komponenten zu einer resultierenden Richtlinie für ein System ist ein NP- oder sogar Exponentialproblem, selbst bei Verwendung formaler Modelle mit Einschränkungen, wie z. B. erweiterten Petri-Netzen [2].

Das Ergebnis ist, dass es selbst dann, wenn eine zuverlässige, formale Beschreibung der zu erwartenden Sicherheit einer Komponente vorliegt (was selten vorkommt), nicht trivial ist, eine solche Beschreibung in eine Sicherheitsrichtlinie für das resultierende System zu fassen.

Vielleicht liegt es an der Schwierigkeit oder vielleicht am typischerweise qualitativen Aspekt der Sicherheitsanforderungen, dass im Durchschnitt nur wenige Fachkräfte auf den Markt kommen, die über eine Ausbildung in diesem Bereich verfügen.

Symptomatisch ist auch, dass in den meisten Softwarelizenzen steht: „Für diese Software gibt es keinerlei Garantie, noch wird garantiert, dass sie für einen bestimmten Zweck geeignet ist.“

Optimistische oder oberflächliche Modellierung: Forscher und Praktiker in der Informatik berücksichtigen in ihren Modellen (theoretisch und/oder mental) oft nicht, dass Algorithmen und ihre Realisierungen in Form von Programmen keine konkreten Objekte sind, sondern lediglich Anweisungen zur Ausführung für ein oder mehrere Verarbeitungselemente (CPUs, MCUs, GPUs, NPUs, FPGAs), die in einem oder mehreren Geräten organisiert sind. Diese Modellreduktion impliziert routinemäßig optimistische und unrealistische Annahmen über die Isolation zwischen Softwarekomponenten und über sensible Daten. So ist beispielsweise die Behauptung, ein System verfüge über „mehrschichtigen Schutz“, wenn seine Komponenten alle auf derselben Maschine und unter demselben Benutzer laufen, im Allgemeinen falsch, da es mehrere häufige Fehlermodi gibt (d. h. ein Element, das im Falle eines Angriffs die Sicherheit von mehr als einer Komponente verletzt, etwa des Prozessors, der Festplatte und des Kernels).

Ein weiterer Fehler, der sich oft als fatal erweist, besteht darin, virtuelle Maschinen (oder Container) als wirklich isoliert zu betrachten, obwohl es in den letzten Jahren unzählige Fälle von „Flucht“ aus den Haupttechnologien gab.

Übermäßige Abstraktionen und Softwareabhängigkeiten: Die übermäßige Abstraktion von Rechenressourcen in APIs und Frameworks und die schwindelerregende Zunahme der Anzahl von Softwareabhängigkeiten erleichtern gleichzeitig das absichtliche Einfügen von Schwachstellen und Darüber hinaus erschweren oder verhindern sie für die für Implementierung, Wartung und Sicherheit verantwortlichen Teams die ordnungsgemäße Pflege der Bedrohungsmodellierung und Systemarchitektur auf dem neuesten Stand.

Über das Problem ist wenig bekannt, aber Daten von Apache Maven [3] deuten darauf hin, dass die durchschnittliche Java-Anwendung im Jahr 2022 von etwa 40 (!) Bibliotheken von Drittanbietern abhängig war. In diesem Zusammenhang eine Chance Bereits eine Kontamination von 1,7 % pro Angriff auf die Lieferkette einer einzelnen Komponente führt zu einer Gesamtwahrscheinlichkeit einer Anwendungskompromittierung von 50 %.

Andererseits ist in der Softwareentwicklungsdisziplin bekannt, dass Architekturkorrosion [4] ein Element ist, das die Identifizierung und Korrektur von Sicherheitsproblemen erschwert und den Schadensbegrenzungszyklus verlangsamt.

Viele Entwickler haben die Schwierigkeit eines Angriffs in den letzten 25 Jahren überschätzt. Mir ist ein Muster aufgefallen: Die meisten Entwickler, selbst diejenigen, die an unseren besten Schulen ausgebildet wurden, haben noch nie erlebt, dass ein echter, praktischer Angriff auf ein System ausgeführt wurde, das sie kennen oder entwickelt haben. Dies führt dazu, dass viele von ihnen typische Bedrohungen unterschätzen oder gar ignorieren.

Andererseits konnte ich im Laufe meiner beruflichen Laufbahn bei der Bearbeitung mehrerer Kundenfälle zusammen mit einem kompetenten Team von Sicherheitsforschern beobachten, dass es uns in etwa 9 von 10 Fällen gelang, „zu gewinnen“ und die Kontrolle über Systeme zu übernehmen, manchmal durch den Angriff auf ein einzelnes Modul, oft jedoch durch Missbrauch der Architektur – Erfahrungen dieser Art werden in den Grundausbildungslehrplänen für Computerfachleute oft nicht vermittelt.

Diese Dichotomie des fehlenden Repertoires hat oft den Effekt, den man mit „Neulinge machen klassische Fehler“ beschreiben kann.

Best Practices zur Sicherung zusammengesetzter Systeme

Die besten Sicherheitspraktiken für Verbundsysteme und deren Komponenten variieren je nach Ihren Sicherheits- und Gewährleistungszielen, da unterschiedliche Methoden und technische Entscheidungen Auswirkungen auf Kosten, zusätzlichen Arbeitsaufwand, Technologieauswahl und Vorlaufzeiten haben. Es ist nicht beabsichtigt, in der Praxis erschöpfend zu sein, um nur einige aufzuzählen, denen in den Lehrplänen für Bachelor-Studiengänge offenbar nur sehr wenig Beachtung geschenkt wird.

Bevor wir fortfahren, müssen wir einige in diesem Abschnitt verwendete Begriffe klären. Ein Sicherheitsziel, auch Sicherheitsanspruch genannt, ist eine Beschreibung dessen, was eine Software, ein Subsystem oder das System selbst verspricht. Beispiel: „Behauptung 1: Die Vertraulichkeit der Nachricht ist mit Sicherheitsstufe 2256 gegenüber nicht-quantenbasierten Angreifern garantiert.“ Schon die Unter Assurance versteht man den Grad der Gewissheit, dass eine bestimmte Behauptung wahr ist. Beispielsweise ist Behauptung 1 mit „hoher Wahrscheinlichkeit“ oder „mit formalem Beweis“ wahr.

Die praktische Erfahrung zeigt, dass das Entwerfen, Implementieren und Warten von Komponenten und Systemen mit einem hohen Sicherheitsniveau tendenziell relativ weniger aufwändig ist als das Erreichen eines hohen Vertrauensniveaus, was hauptsächlich auf die Auswirkungen des Rice-Theorems und der Sicherheitsrichtlinienzusammensetzung zurückzuführen ist. Generell ist der hohe Aufwand, der zum Erreichen eines hohen Sicherheitsniveaus erforderlich ist, mit vielen Anwendungsszenarien nicht vereinbar. Er ist bis zu 3.83-mal höher [5] als bei weniger strengen Sicherheitsanforderungen, wie beispielsweise den Stufen EAL 1 gegenüber EAL 7 im ISO/IEC 15408-Standard – „Common Criteria“.

Kurz gesagt: Es ist wichtig, die Kritikalität des Anwendungsfalls mit den Sicherheitszielen und Sicherheitsstufen aus der Perspektive der Fähigkeiten der beteiligten Teams sowie der verfügbaren Ressourcen in Einklang zu bringen. Was die Vorgehensweisen angeht, haben wir die wirksamsten beobachtet:

Vokabular- und Methodikgrundlagen: Alle Teammitglieder müssen darin geschult werden, eine gemeinsame Nomenklatur zu verwenden, um sich in Bezug auf Sicherheitsziele, Bedrohungen, Schwachstellen, Sicherheitsprüfungen, Vorfallreaktionen usw. auszudrücken. Dabei muss ein dokumentiertes Framework zur Verwaltung des sicheren Lebenszyklus von Systemen verwendet werden, beispielsweise Microsoft SDL oder das SAMM-Modell.

Der Lösungsarchitekt sollte in kleinen bis mittelgroßen Projekten für die Sicherheit verantwortlich sein: In kleinen bis mittelgroßen Projekten ist es wichtig, dass der Lösungsarchitekt oder eine Person in einer ähnlichen Rolle alle Module und Systemkomponenten sowohl hinsichtlich des Quellcodes als auch der Architektur versteht und sich auch mit den wichtigsten Angriffsarten auskennt. Dies ist eine sehr anspruchsvolle Position, sie reduziert jedoch die Notwendigkeit, den Softwareentwicklungs- und -wartungsprozess zu formalisieren, erheblich. Im Allgemeinen umfasst die Ausbildung dieser Talente Schulungskurse im sicheren Lebenszyklus (z. B. MS-SDL, SAMM), in spezifischen, in der Anwendung verwendeten Technologien und in offensiver Sicherheit (z. B. CEH, CompTIA PenTest+, ECSA/LPT).

Kritische Projekte jeder Größenordnung erfordern Formalismus und es ist unerlässlich, eine Sicherungsmethode wie NATO AEP-67 ENGINEERING FOR SYSTEM ASSURANCE NATO IN PROGRAMMES einzusetzen, die eine Möglichkeit bietet, Sicherheitsansprüche und die jeweiligen Sicherungsstufen während des Lebenszyklus der Lösung unter Berücksichtigung aller ihrer Komponenten zu dokumentieren und nachzuweisen. Aufgrund seiner Koordinierungsleistung und seines anpassbaren Kraftaufwands wurde das NATO AEP-67 erfolgreich in mehreren Projekten eingesetzt und diente auch als Grundlage für Teamtraining [6], ein Thema, das später erörtert wird.

Trennen Sie Wegwerfsoftware von Produktionssoftware an der Quelle: Es ist notwendig, in der Produktion die Wegwerfsoftware-Mentalität zu vermeiden, die typisch für die Prototyping-Phasen ist, wo die Verwendung von „Nightly Build“-Versionen von Komponenten üblicherweise von Teams begeisterter Entwickler vorgenommen wird, die immer auf der Suche nach den „neuesten Funktionen“ sind. Das Einfrieren von Komponenten in „Long Term Support – LTS“-Versionen spielt eine grundlegende Rolle bei der Bereitstellung sicherer Systeme, nicht nur weil sie die langfristige Wartbarkeit des zusammengesetzten Systems garantieren, sondern vor allem weil sie die Angriffsfläche „einfrieren“ und das Einfügen von Sicherheitsmängeln im Laufe der Zeit reduzieren, wodurch das Team ein besseres formales und/oder mentales Modell dessen hat, was es schützen möchte.

Assurance Cases als Teambuilding-Tool

Assurance Cases in Form von NATO AEP-67 organisieren Sicherheitsansprüche hierarchisch, wie in Abbildung 1 dargestellt. Jeder „Anspruch“ kann rekursiv durch einen oder mehrere Zwischenansprüche („Unteransprüche“) unterstützt werden.

Im angegebenen Beispiel erfordert „Anspruch A“, dass die Unteransprüche 1 und 2 (und möglicherweise weitere) gleichzeitig wahr sind, damit er wahr ist. Irgendwann muss die Wahrheit einer Nebenbehauptung mit einem gewissen Grad an Sicherheit bewiesen oder angenommen werden. Im Falle des Unteranspruchs 1 wird seine Richtigkeit durch Argumentation und vordefinierten Bewertungskriterien.

FEIGE. 01 | AUSZUG AUS EINEM VERSICHERUNGSFALL, QUELLE [6].

Wie sich der aufmerksame Leser vorstellen kann, können Assurance-Fälle recht detailliert werden, da zur Sicherstellung der Wahrhaftigkeit einer gegebenen Behauptung mehrere Zwischenbedingungen erforderlich sein können, die viele Systemkomponenten betreffen. Darüber hinaus sind die Assurance Cases flexibel genug, um die verschiedenen Phasen des Lebenszyklus einer Komponente oder eines Systems zu berücksichtigen.

Genau diese Fähigkeit (oder Notwendigkeit) zur Ausdrucksstärke und Detailliertheit bei der Erstellung von Assurance Cases hat sich als entscheidend für die Schulung und Verbesserung von Teams erwiesen, die sich mit dem Entwurf, der Entwicklung und der Wartung von Systemen befassen, wie wir in [6] berichteten. In diesem Projekt wurden Doktoranden und Studenten von Unicamp in Teams eingeteilt, deren Ziel es war, einen sicheren, gruppengesicherten Nachrichtendienst zu implementieren, ihre Sicherheitsgarantien zu dokumentieren und dann das System des anderen Teams anzugreifen. Die Teams wurden so durch den gesamten Lebenszyklus ihrer Lösungen geführt und erhielten aussagekräftige Erkenntnisse im Rahmen der im Bereich der Informationssicherheit erforderlichen ganzheitlichen Vision.

Im pädagogischen Experiment erwiesen sich die Assurance Cases in mindestens drei pädagogischen Aspekten als grundlegend: (i) Sie zwangen jeden der Studenten, seine Annahmen über die Sicherheit der Systemkomponenten zu hinterfragen, (ii) sie demonstrierten dem Team die Notwendigkeit, einfache und präzise Sicherheitsrichtlinien/-ansprüche für die Systemkomponenten zu definieren und zu dokumentieren, und (iii) sie dienten als Achse objektive Kommunikation zwischen Teammitgliedern, Optimierung der Bemühungen und Begrenzung von Lücken.

Weit davon entfernt, nur ein theoretischer Gewinn und eine akademische Übung zu sein, konnte ich nach dem in [6] beschriebenen Experiment aus erster Hand sehen, wie wichtig die Assurance-Fälle für die kontinuierliche Verbesserung und die „Ausbildung am Arbeitsplatz“ von Fachkräften sind. Darüber hinaus haben solche Fälle den Stakeholdern der entwickelten Systeme geholfen, da sie nun eine genaue Beschreibung dessen haben, was sie von ihren Systemen erwarten können.

Fazit

Das Entwerfen, Implementieren, Erhalten und Warten sicherer Verbundsysteme ist eine große Herausforderung und erfordert von den beteiligten Teams vor allem ein situatives Bewusstsein. Das heißt, dass trotz der geschäftlichen Vorteile der Softwaremodularisierung dieselbe Organisation bei der Komponentenbildung mehrere der praktischen Wege abstrahiert, die Angreifer für erfolgreiche Angriffe nutzen.

Um die Anzahl der Schwachstellen zu minimieren, müssen Entwicklungs-, Betriebs- und Sicherheitsteams über die gleiche Bedrohungsmodellierung, das gleiche Vokabular und die gleichen Entwicklungspraktiken sowie über eine ganzheitliche Sicht auf die Systeme und ihre Komponenten verfügen. Zu diesem Zweck haben sich Methoden und Frameworks wie Microsoft SDL, SAMM und NATO AEP-67 als wirksam erwiesen.

Darüber hinaus müssen die für Design und Entwicklung zuständigen Teams regelmäßig mit den Sicherheitsteams in Kontakt treten, um über Angriffstechniken und vor allem über den oft geringen Aufwand für einen erfolgreichen Angriff auf dem Laufenden zu bleiben. Nach Ansicht des Autors steht der Einbeziehung all dieser Kenntnisse und Praktiken in die Lehrpläne für Informatikstudenten und Postgraduierte nichts im Wege.

Referenzen

Len Bass, Paul Clements und Rick Kazman, „Software Architecture in Practice“, 4. Auflage, August 2021.

Yen, Hsu-Chun. „Zur Regelmäßigkeit von Petri-Netz-Sprachen.“ Protokoll des 13. IEEE Annual International Phoenix

Konferenz über Computer und Kommunikation (1994): 329.

M. Mir, M. Keshani und S. Proksch, „Über die Auswirkungen von Transitivität und Granularität auf die Ausbreitung von Sicherheitslücken im

Maven-Ökosystem“, 2023 IEEE Internationale Konferenz für Softwareanalyse, Evolution und Reengineering (SANER), Taipa,

Macao, 2023, S. 201–211, doi: 10.1109/SANER56733.2023.00028.

Ullah Khan, M. Munib, U. Manzoor und S. Nefti, „Analyse von Risiken auf architektonischer Ebene“, Internationale Konferenz über

Information Society (i-Society 2011), London, UK, 2011, S. 231-236, doi: 10.1109/i-Society18435.2011.5978442.

Kou, K., Jeong, J., und Lee, G. (2008). Definition von Evaluationssicherheitsstufen und Abschätzung des Evaluationsaufwands für

Betriebssystembasiert ISO/IEC 19791. Internationale Konferenz für Sicherheitstechnologie 2008, 176-183. https://doi.

org/10.1109/SECTECH.2008.41

Gallo, R., Dahab, R. (2015). Assurance Cases als didaktisches Werkzeug zur Informationssicherheit. In: Bishop, M., Miloslavskaya, N.,

Theocharidou, M. (Hrsg.) Informationssicherheitsausbildung im gesamten Lehrplan. WISE 2015. IFIP Fortschritte in der Information

und Kommunikationstechnologie, Bd. 453. Springer, Cham. https://doi.org/10.1007/978-3-319-18500-2_2

ROBERTO GALLO

Er ist ein Veteran in den Bereichen Verteidigung und Cybersicherheit für Regierungs-, Telekommunikations-, Militär-, (Gegen-)Geheimdienst- und Unternehmensanwendungen. Leistung im akademischen, beruflichen und institutionellen Bereich. Er besitzt einen Doktortitel und einen Master-Abschluss in Informatik mit Schwerpunkt Cybersicherheit von UNICAMP. Er hat einen Abschluss in Computertechnik von derselben Universität.