Um die Aufgabe ganzheitlich zu greifen, erscheint eine umfassendere Sicht notwendig. Um unseren Kunden Orientierung zu geben, wollen wir mit dem im folgenden vorgestellten Modell einen Ansatz liefern, der es auch ohne intensives Studium der Materie ermöglichen soll, die Gesamtheit der Maßnahmen und Initiativen zu beurteilen, bzw. Lücken zu identifizieren.

Wir haben diese Notwendigkeit gesehen, nachdem unsere Recherche in der Literatur kein Modell auffinden konnte, das sowohl hinreichend pragmatisch nutzbar aber auch technischer versiert genug erscheint. Um diese Lücke zu füllen, haben wir das nachstehend beschriebene Modell skizziert.

Die erste Dimension unserer Betrachtung soll die Angriffsoberfläche selbst sein. Solange wir nicht wissen, was es zu schützen gilt, solange wird es schwierig bleiben, es in den Griff zu bekommen. Hierbei ist zu beachten, dass wir nicht eine konkrete Bedrohungssituation versuchen zu modellieren, sondern versuchen, ein allgemeines Modell aufzustellen. In diesem abstrakten Fall kann ein an der Bedrohung orientierter Ansatz mangels konkreter Gefahrensituation nicht erfolgreich sein. Daher empfehlen wir die im folgenden beschriebenen Aspekte.

Warum wählen wir den Begriff „Aspekte“? Nun, Software ist typischerweise in diversen Schichten entwickelt. Aber wie oft im Leben, keiner hält sich an die Regel und gerade im Bereich der embedded Systeme aber auch bedingt durch unterschiedliche Virtualisierungsmethoden geraten die Schichten auch einmal durcheinander. Somit ist die hierarchische Implikation, die mit dem Begriff einer Schicht einhergeht, unnötig irreführend. Der Begriff „Aspekt“ hat eher die Konnotation eines anderen Blickwinkels auf die gleiche Sache, was in diesem Fall passender erscheint.

Ein bisschen Sicherheit ist keine Sicherheit!

Insbesondere in IoT-Szenarien beginnt alles mit der Hardware. Das Endgerät selbst, sei es ein Fernseher oder ein Sensor wird sich stets im ungeschützten Bereich, jedenfalls aber außerhalb des geschützten Rechenzentrums befinden. Die sich heraus ergebenden Anforderungen um Komplikationen, wie bspw. Sicherheit des Datenverkehrs subsumieren wir in dem Device Aspekt.

Ereignisse wie Meltdown (7, 8, 9) zeigen aber auch, dass sogar die Hardware selbst fehlerhaft sein und somit eine Angriffsfläche bieten kann. Gerade die stetig wachsende Zahl von IoT-Geräten erhöhen die Angriffsfläche einer Organisation erheblich. Dabei kann es nicht nur um das Gerät selbst, wohl aber um eine im Netzwerk befindliche Ausgangsposition für weitere Aktivitäten gehen.

Diesen Sommer (2019) haben Analysten des Darmstädter Fraunhofer SIT in fast allen marktgängigen VoIP-Telefonen Möglichkeiten entdeckt, die es ermöglichten, von außen die Kontrolle zu übernehmen und sie für weitere Angriffe auf die einzusetzen (10).

Je weiter man in dem Modell geht, desto klarer wird es, weshalb wir von den schichten oder Layern Abstand genommen haben. Beispielsweise setzt ein bare-metal Hypervisor wie Xen direkt auf der Hardware, ein Level 2 Hypervisor wie VMWare Workstation oder VirtualBox auf dem Betriebssystem auf. Jedoch bieten sowohl der Hypervisor als auch das Betriebssystem eigenständige Angriffsvektoren, die unterschiedlichen zu behandeln sind. Daher unterscheiden wir den Operating-System-Aspekt und den Abstraction-Aspekt.

Meistens werden Daten übertragen, um sie anschließend mit irgendwelchen Anwendungen zu verarbeiten. Die Anwendungen selbst bieten eine vielschichtige Angriffsoberfläche. Authentifizierung und Autorisierung werden üblicherweise hier abgehandelt. Daher haben wir den Software-Aspekt ergänzt.

Hinter der Anwendung stehen letztendlich auch noch Benutzer, die eine extrem wichtige jedoch in technischen Modellen oft übersehenen Aspekt darstellen. ein überwältigender Anteil an Problemfällen wird durch hausinterne Benutzer verursacht, ob absichtlich oder unabsichtlich: zu einfache Passwörter, laxer Umgang mit Sicherheitsbestimmungen, vergessene Zugänge oder hilfreiches Verhalten, verursachen nach wie vor eine Großzahl von Sicherheitsfällen (11, 12). Wenn wir über Sicherheit reden, spielt für uns daher immer der Organisations-Aspekt eine wichtige Rolle.

Aus Sicherheitsperspektive sollte es klar sein, dass jeder der Aspekte das Risiko spezifischer Angriffe mit sich bringt. Daher wird es für ein geschlossenes Sicherheitskonzept erforderlich, jeden dieser Aspekte zu beobachten, zu sichern und kritische Ereignisse zu erkennen.

Jedoch sind Daten und Systeme ja nicht nur in Benutzung bedroht. Insbesondere Daten liegen zumeist ja nur rum, wenn auch nicht physisch. Genau genommen warten sie nur darauf, abtransportiert zu werden. Geschieht dies durch nicht autorisierte Benutzer, ist das Data Leak da. gespeicherte Daten stellen also ebenfalls einen hohen Sicherheitsanspruch dar. Der Persistenz-Aspekt soll die „data at rest“-Betrachtung ergänzen.

Fügen wir alle diese Aspekte zusammen, so entsteht ein Bild der Angriffsoberfläche in ihrer Gesamtheit. Nachstehendes Bild fasst all identifizierten Aspekte noch einmal zusammen.

Das sieht schon recht umfangreich aus. Aber nicht genug: Sicherheit ist eben nicht eine Sache eines spezifischen Zeitpunktes. Es ist wichtig, die Sicherheit entlang des gesamten Lebenszyklus eine Anwendung, Lösung bzw. Produktes sicherzustellen. Der typische Lebenszyklus einer Anwendung umfasst die Phasen DESIGN, DEVELOP, TEST, DEPLOY und RUN. Um die allgemeine Softwareentwicklung hier um die Dimension der Standardsoftware zu erweitern, soll der zweite Schritt mit CUSTOMIZE entsprechend ergänzt werden.

Etwas exotischer wirkt der RETIRE Schritt, das Ablösen von Anwendungen. Obwohl eine zunehmende Akzeptanz festzustellen ist, dass auch Anwendungen nicht für die Ewigkeit gebaut werden, so gibt es doch relativ wenig Literatur zum Thema Retirement. Aus Sicherheitsperspektive jedenfalls sollte dieser Schritt nicht in Vergessenheit geraten.

Weiterhin ist die RUN-Phase auch von spezieller Bedeutung für uns, da hier die meisten Angriffspunkte bzw. auch die höchste Angriffswahrscheinlichkeit zu finden sind. Wir schlagen daher vor, diese noch einmal in die folgenden vier Schritte zu unterteilen:

• PROTECT:
  Diese Phase repräsentiert den Regelzustand, sobald ein System in die RUN-Phase eintritt. Systeme sind operational und werden durch die identifizierten Maßnahmen geschützt.
• IDENTIFY:
  Vielleicht der kritischste Schritt im Lebenszyklus ist die Incident Identifikation, das Feststellen, dass etwas passiert ist. Die Unterscheidung, ob es nur ein Controller ist, der manuell Finanz-Excels aus unterschiedlichen Lokationen zusammenzieht oder ein bösartiger Spionageakt und nur im letzten fall einen Alarm auszulösen, ist kein Kinderspiel. Monitoring-Systeme, die betrügerische oder bösartige Aktivitäten erkennen und entsprechende Alarme auslösen, sind ein wichtiger Teil der Sicherheitssystematik.
• INSPECT:
  Sobald etwas aufgefallen oder ein Schadensfall eingetreten ist, müssen die Systeme isoliert und untersucht werden, um die den Angriff, bzw. seine Ursache oder Motivation, ggf. sogar den Angreifer zu identifizieren. Das ist wichtig, um daraus für die Zukunft zu lernen.
• RESTORE:
  In Abhängigkeit der Auswirkungen und des Schadensfalles müssen ggf. vernichtete oder verschlüsselte Daten oder die Arbeitsfähigkeit von Systemen wiederhergestellt werden. IN die Restore-Phase fallen Aufgaben der Rückkehr in den normalen Arbeitsmodus.

Zusammengefasst ergibt sich daraus die im folgenden Diagramm dargelegte Sicht:

Die „Security Matrix“

Die Kombination der Zeit-Dimension als x-Achse und die Oberflächen-Dimension als y-Achse lässt unsere hier vorgeschlagene Security-Matrix entstehen. Sie erfüllt den Anspruch, die Planung und Periodisierung von Maßnahmen zu unterstützen, sowie Transparenz über die Entscheidungen bzw. die noch offenen, weißen Flecken einer Organisation zu liefern. Für jedes Feld lassen sich eigene Ansätze, Werkzeuge oder KPIs definieren, um ein umfangreiches, solides Security-Management aufzusetzen.

Aber die Matrix eignet sich nicht nur zur eigenen Orientierung. Sie ist auch eine gute Möglichkeit, einen Anbieter erklären zu lassen, was er denn nun eigentlich in seinen Strauß an Tools alles abdeckt und was eben nicht. Haben Sie zuvor mit Hilfe der Matrix Ihren Bedarf bestimmt, lässt sich folgerichtig das Angebot leicht mit dem Bedarf abgleichen. Good bye Marketing blabla!

Anwendung der Security Matrix

Obwohl die Matrix nun ein ganzheitliches Bild mit vielen Feldern darstellt, möchten wir darauf hinweisen, dass es zwingend erforderlich ist, alle Felder sofort und umfassend zu füllen. Die Matrix soll vor allem dazu dienen, Orientierung zu geben und in Abhängigkeit der eigenen Situation und dem Schutzbedarf die richtigen Prioritäten zu setzen. Es wird eine Vielzahl situationsspezifischer Faktoren geben, die ihre Entscheidung beeinflussen. Auch kann es sein, dass die Matrix für die eine Business Unit anders aussieht, als für eine andere. Wichtig ist, dass zum einen die Entscheidungen bewusst getroffen werden und zu anderen, dass sie im Einklang mit den geschäftlichen Anforderungen und den technischen Fähigkeiten des Unternehmens stehen. Klaffen Wirklichkeit und Anspruch zu weit auseinander, so mag die Matrix zwar gut gefüllt sein, Sicherheit entsteht dadurch dennoch nicht.

Es wird keine allumfängliche Sicherheit geben , aber Sie sollten entscheiden, an welcher Stelle es dünn wird!

Wie oben beschrieben, eignet sich die Matrix auch dazu, Anbieter aufzufordern, ihre Fähigkeiten entsprechend einzuzeichnen bzw. die entsprechenden Felder zu markieren. Das lässt sich dann gut mit einer zuvor angefertigten Bedarfsbetrachtung vergleichen. In der folgend dargestellt, animierten Matrix ist ein Satz an Buzzwords aus dem Sicherheitsbereich dargestellt: