Das Wort „Sicherheit“ hat im Systems Engineering zwei Bedeutungen. Das ist zum einen die Betriebssicherheit (oder funktionale Sicherheit), womit gemeint ist, dass durch den Betrieb des Systems kein Schaden \u2013 egal ob k\u00f6rperlicher, finanzieller oder anderer Art \u2013 verursacht wird. Klassische Elemente der funktionalen Sicherheit sind Not-Ausschalter oder Einrichtungen, die den Betrieb eines Ger\u00e4ts bei ge\u00f6ffneter Motorhaube verhindern. Betriebssicherheit ist heutzutage gut verstanden.<\/p>\n
Aber dann gibt es noch Sicherheit im Sinne von Angriffssicherheit, also dass ein das System nicht unterwandert und missbraucht werden kann. Das ist in der heutigen Zeit ein ganz gro\u00dfes Thema, da durch die Digitalisierung und Vernetzung mit der physikalischen Welt es immer mehr potentielle Angriffsziele gibt.<\/p>\n
Im Englischen gibt es zwei verschiedene Begriffe f\u00fcr die zwei Arten von Sicherheit, n\u00e4mlich Safety (Betriebssicherheit) und Security (Angriffssicherheit). Die zwei Arten der Sicherheit lassen sich leicht an der Richtung des Schutzes Unterscheiden: Bei der Betriebssicherheit wird die Umgebung vor dem System gesch\u00fctzt, und bei der Angriffssicherheit wird das System von der Umgebung gesch\u00fctzt.<\/p>\n
Im folgenden wird beschrieben, warum es so schwierig ist, sich gegen Angriffe zu sch\u00fctzen. Aber m\u00f6glich ist es, und f\u00fcnf L\u00f6sungen werden vorgestellt.<\/p>\n
<\/p>\n
Wie schon erw\u00e4hnt, geht es bei der Angriffssicherheit darum, dass System vor dessen Umgebung zu sch\u00fctzen. Das System ist \u00fcber Schnittstellen von der Umgebung getrennt. Schnittstellen k\u00f6nnen explizit definiert sein (bspw. der Zugang zu einem Tank) oder implizit (bspw. das Geh\u00e4use eines Ger\u00e4tes). Um Angriffssicherheit zu erreichen, m\u00fcssen die Schnittstellen ausreichend gesch\u00fctzt sein.Dabei ist es wichtig, auch die impliziten Schnittstellen zu untersuchen.<\/p>\n
Die T\u00e4ter bohrten ein Loch in die Verkleidung und steckten einen USB-Stick in den PC des Geldautomaten [tweetthis]Die T\u00e4ter bohrten ein Loch in die Verkleidung und steckten einen USB-Stick in den PC des Geldautomaten[\/tweetthis]<\/p><\/blockquote>\n
Ein Interessantes Beispiel f\u00fcr dieses Problem ist ein System, mit dem Geldautomaten leerger\u00e4umt<\/a> werden k\u00f6nnen. Dazu bohren die Diebe ein Loch in das Geh\u00e4use des Geldautomaten, durch den dann ein USB-Stick gesteckt wird. Gewiss, der Hack nutzt die Schw\u00e4che des Betriebssystems des Geldautomaten aus (Windows XP). Doch w\u00e4re der Einbruch in dieser Form nicht m\u00f6glich gewesen, wenn es nicht so leicht gewesen w\u00e4re, mit einer einzigen Bohrung durch das d\u00fcnne Geh\u00e4use den USB-Port zu erreichen.<\/p>\n
Diese Geschichte macht aber auch klar, warum das Thema heute aktueller denn je ist: Denn mit dem Loch war es ja noch nicht getan. Ohne die Schw\u00e4che im Betriebssystem, der Konfiguration des Computers und der Bank-Software w\u00e4re der Einbruch ebenfalls nicht m\u00f6glich gewesen. Software hat nun mal Schw\u00e4chen, die ausgenutzt werden k\u00f6nnen.<\/p>\n
Jede Software hat Fehler, die f\u00fcr Angriffe genutzt werden k\u00f6nnen<\/h2>\n
Windows XP hat bereits 45 Millionen Zeilen Code \u2013 kein Wunder, dass dort Schwachstellen zu finden sind. Das ist vielleicht nicht ganz fair, da es schlie\u00dflich ein altes Betriebssystem ist, welches zu einer Zeit entwickelt wurde, als Computersicherheit noch kein allzu gro\u00dfes Thema war. Aber auch heute ist die Situation nicht besser geworden: Der Einsatz von Software in allen Lebensbereichen erh\u00f6ht sich von Jahr zu Jahr. Inzwischen wird Computersicherheit zwar wesentlich mehr Beachtung geschenkt, dass \u00e4ndert aber nichts daran, dass in jeder Software Fehler stecken, die f\u00fcr Angriffe genutzt werden k\u00f6nnen.<\/p>\n
Typische Programme haben zwischen 10 und 50 Fehlern pro 1000 Zeilen Code [tweetthis]Typische Programme haben zwischen 10 und 50 Fehlern pro 1000 Zeilen Code[\/tweetthis]<\/p><\/blockquote>\n
Es ist unm\u00f6glich, fehlerlose Software zu produzieren. Dutzende von Bugs pro 1000 Zeilen Code ist nicht ungew\u00f6hnlich, und selbst bei gr\u00fcndlicher \u00dcberpr\u00fcfung lassen sich bestenfalls 0,5 Fehler pro 1000 Zeilen Code<\/a> erreichen. Das bedeutet, dass selbst in kleineren Programmen mit gro\u00dfer Wahrscheinlichkeit Fehler stecken.<\/p>\n
Computersicherheit ist von Grund auf defekt<\/h2>\n
Viel der heute eingesetzten Software ist Jahrzehnte alt und stammen aus einer Zeit, als Computersicherheit kaum ein Thema war. Das trifft besonders auf die Software zu, die f\u00fcr den Betrieb des Internets verwendet wird. Was noch viel schlimmer ist: Teilweise wurden Ans\u00e4tze zur Sicherheit aktiv unterdr\u00fcckt. Zum Beispiel wollte Vint Cerf<\/a>, ein Internet-Pionier, Kryptografie direkt in die Internet-Infrastruktur einbauen, was von den Sicherheitsbeh\u00f6rden der USA verhindert wurde. Statt dessen wurde eine weitere Schicht f\u00fcr die Sicherheit entwickelt, wodurch die Infrastruktur noch komplexer und viel neuer Code beigesteuert wurde, was ohne Zweifel neue Bugs, und damit Sicherheitsl\u00fccken, geschaffen hatte.<\/p>\n
Es ist eine Sache, wenn eine Webseite besch\u00e4digt oder blockiert wird, wobei auch da ein erheblicher Schaden entstehen kann. Aber durch das Internet der Dinge (IoT) wird das Problem pl\u00f6tzlich akut: Beim IoT sind Ger\u00e4te der physikalischen Welt permanent mit dem Internet verbunden. Das kann ein Stromz\u00e4hler sein oder eine Kaffeemaschine, aber das zur Zeit am hei\u00dfesten diskutierte Ger\u00e4t ist das Auto. Welche Gefahr von einem gezielten Angriff auf vernetzte Autos ausgehen kann, ist kaum vorzustellen. Das ist kein theoretisches Problem, ein Jeep wurde bereits gehackt<\/a> \u2013 zum Gl\u00fcck von Sicherheitsforschern.<\/p>\n
Was nun?<\/h2>\n
Zum Gl\u00fcck wird das Problem sehr ernst genommen, und es wird nach L\u00f6sungen gesucht. Hier sind einige der Ans\u00e4tze, die verfolgt und teilweise auch schon praktiziert werden.<\/p>\n
1. Sandbox: Den Schaden in Schach halten<\/p>\n
Bei einer Sandbox<\/a> wird eine abgeschottete Umgebung geschaffen, in der die Software betrieben wird. Der Vorteil: Diese Umgebung muss nur ein einziges Mal programmiert werden, und sollte dementsprechend sorgf\u00e4ltig \u00fcberpr\u00fcft werden. Selbst wenn ein Angreifer es schafft, die eigentliche Software zu unterwandern, so ist der Schaden auf die Sandbox begrenzt. Auch in der Sandbox gefundene Schwachstellen brauchen nur ein mal korrigiert zu werden, egal, f\u00fcr wie viele Programme die Sandbox eingesetzt wird.<\/p>\n
2. Bounties: Menschen auf die Fehler ansetzen<\/p>\n
In der Vergangenheit wurden Sicherheitsforscher, die Softwarehersteller auf Schwachstellen hinwiesen, oft ignoriert, und manchmal sogar mit rechtlichen Schritten bedroht. Das hat sich ge\u00e4ndert. Die gr\u00f6\u00dferen Hersteller haben angefangen, Pr\u00e4mien f\u00fcr das Finden von Sicherheitsl\u00fccken auszuschreiben. Es gibt inzwischen sogar Wettk\u00e4mpfe.<\/p>\n
3. Sichere Hardware: Sicherheit im Kern verbaut<\/p>\n
An kritischen Stellen werden sicherheitsrelevante Funktionen nicht mehr in Software, sondern in Hardware realisiert. Allen voran Apple, die Sicherheit zu einem zentralen Marketingfeature gemacht haben. Es wird auch viel in diesem Bereich geforscht. Das Forschungsprojekt CHERI<\/a> hat zum Ziel, verschiedene Sicherheitsfunktionen, wie den Schutz des Speichers zum Beispiel, direkt in einem generischen Chip zu realisieren.<\/p>\n
4. Formale Methoden: Sicherheit beweisen<\/p>\n
Wenn Systeme \u00fcber formale Spezifikationen beschrieben werden, so lassen sich darauf basierend bestimmte Eigenschaften mathematisch nachweisen. Dieser Ansatz wird schon l\u00e4nger im Bereich der funktionalen Sicherheit eingesetzt, ist aber auch bei der Angriffssicherheit effektiv, wenn auch leider sehr aufw\u00e4ndig. Mit diesem Ansatz wurde im Rahmen des Forschungsprojekts SMACCM<\/a> eine Software f\u00fcr die Steuerung von Flugdrohnen entwickelt. Der generierte Quellcode wurde offengelegt und bisher noch keine Schwachstelle gefunden.<\/p>\n
5. Versicherung: Das Risiko minimieren<\/p>\n
Trotz all dieser Entwicklungen ist klar: Eine Nachhaltige L\u00f6sung f\u00fcr Computersicherheit gibt es nicht, und wird es auch so schnell nicht geben. Aber wir Menschen haben ja l\u00e4ngst einen Weg gefunden, um mit Risiken umzugehen: Inzwischen werden immer \u00f6fter Risiken bez\u00fcglich Angriffssicherheit mit Versicherungen abgefangen. Das wird auch durch den Gesetzgeber unterst\u00fctzt. Dieser fordert zum einen in immer mehr L\u00e4ndern, dass Sicherheitsprobleme und Angriffe ver\u00f6ffentlicht werden; zum anderen werden die bisher eher laxen Haftungsfragen gestrafft. Beides f\u00f6rdert das Interesse an L\u00f6sungen f\u00fcr die betriebswirtschaftliche Risikominimierung, und die Versicherung ist nun mal ein altbew\u00e4hrtes Werkzeug.<\/p>\n
Fazit<\/h2>\n
Das Thema Angriffssicherheit ist so akut wie nie zuvor, insbesondere durch das Internet der Dinge. Ich hoffe inst\u00e4ndig, dass die Industrie das Thema proaktiv angeht, insbesondere die Automobilindustrie im Moment. Wenn hier zu lange gewartet wird und es zu viele auf Sicherheit zur\u00fcckzuf\u00fchrende Katastrophen gibt, dann hat die Industrie die Chance vers\u00e4umt, sich selbst zu regulieren, und der Gesetzgeber wird es tun.<\/p>\n