Tackling the Security Challenge

Der Hack von Flipboard (1) hat 150 Millionen Kundenkonten offengelegt, der Sicherheitsanbieter Checkpoint berichtete über einen Einbruch in der Spieleplattform Fortnite (2), bei dem die Angreifer 200 Millionen Kundenkonten habhaft werden konnten und im April berichtete Upgard (ebenfalls ein Sicherheitsanbieter), dass ca. 540 Millionen facebook-Identitäten, durch 3rd party apps öffentlich zugänglich waren. Diese Liste ließe sich fortsetzen.

Welcher CISO oder CIO würde gerne seinen Unternehmensnamen in Verbindung mit einer solchen Schlagzeile lesen? Aber wie kann man sich davor schützen? Wie bekommt man den Fuß auf den Boden, in einer sich immer schneller entwickelnden Industrie, die zudem immer intransparenter wird? Cybersecurity ist eines der heißesten Themen der letzten Jahre und die Anzahl der Lösungen wächst nahezu täglich. Und alle versprechen, den Heiligen Gral der Sicherheit.

Sicherheit ist für uns kein Thema mehr!“, entgegnete neulich ein möglicher Kunde auf die Frage nach dam Stand der Sicherheit. „Wir setzen jetzt ein Security Operations Center (SOC) auf und damit kümmert sich jemand um alles.

Äh, sicher?!“, es ist auf jeden Fall eine gute Idee, die Verantwortung für Sicherheit einer dedizierten Ressource zu übertragen. Aber die Annahme, dass die Einführung eines SOC sofort das gesamte Unternehmen absichern wird, ist dann schon ein gefährliches Missverständnis! Auf jeden Fall ist es ein wichtiger Aspekt und sollte Teil eines guten Lösungskonzeptes sein. Aber in der Regel ist ein SOC nicht dafür ausgelegt, alle Sicherheitsaforderungen einer Unternehmung zu bedienen. Sicherheit ist eine wesentlich breitere Aufgabenstellung.

Cybersecurity is hot!

Sophos – ein englischer Anbieter von Sicherheitslösungen – wurde kürzlich für ein Multiple von 35 auf den Free Cash Flow gekauft.

Unsere Analyse von 100 Security Startups zeigt, dass in den letzten 10 Jahren mehr als 8.3 Mrd USD Venture Capital in dieses Segment geflossen sind.

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 "Angriffsoberfläche" (Surface)

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).

Geht man in der Kette weiter, wird das Gerät entweder über Funk, Netzwerk- oder Stromkabel mit dem eigentlichen Netzwerk verbunden sein, um „nach Hause“ zu telefonieren. Die Existenz eines solchen Mediums, die physische Verbindung als auch die Signalgebung behandeln wir in dem Aspekt „Physical and Data“. In diesem Aspekt sind vor allem die Authentizität der Kommunikationsteilnehmer als auch die Vertraulichkeit zu fokussieren.

Durch ebendieses Medium fließen dann im Regelfall die Kommunikationspakete. Die älteren Leser haben sicherlich sofort das OSI-Modell (5) mit seinen sieben Schichten vor Augen, und das ist solange wir mit der paketvermittelnden Kommunikation haben auch unverändert: Unser Network Aspekt adressiert den Paketfluss und Steuerung (routing), vergleichbar zu OSI-Layer 3. wir folgen aber nicht lange dem OSI-Modell.

Der folgende Aspekt entspricht jedoch noch dem OSI Layer 4, wo aus den Paketen wieder Kommunikation zusammengesetzt wird. Auch in unserem Modell bezeichnen wir diesen Aspekt als „Transportation“. Hintergrund für die feine Trennung sind die unterschiedlichen Schutzmechanismen.

Aber nun entfernen verlassen wir mit dem Communications Aspekt das OSI-Modell. Dieser Aspekt behandelt alles, was zur sitzungsorientierten Verbindung, bspw. ein REST call via HTTP/S, eine FTP/S Sitzung oder eine DNS Auflösung. Die betrifft alle Netzwerk-Stack typischen Verantwortlichkeiten und hat damit einen wesentlich breiteren Umfang als der ursprüngliche Layer 5 des OSI-Modells.

Anmerkung: Wir diskutieren noch, ob wir Hardware und Firmware als separate Aspekte führen sollen. Dass die Firmware eigene Angriffsvektoren bietet, wird sowohl von SIT als auch BSI (14) klar herausgearbeitet. Aus technischer Perspektive erscheint eine Differenzierung daher sinnvoll. Jedoch stellen aus pragmatischer Perspektive für Anwender beide üblicherweise ein Blackbox dar und erfordern daher auch eine vergleichbare Behandlung. für Anbieter solcher Geräte ist die Differenzierung jedenfalls empfehlenswert. Wir freuen uns auf Ihre Gedanken dazu! Mailen Sie uns unser discussions @ eacg.de

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.

Die "Lebenszyklus" Dimension

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!

Sie suchen Orientierung im Dschnungel der Security Abkürzungen? Oder Sie benötigen eine professionelle Einschätzung Ihrer gegenwärtigen Sicherheitsinitiativen?

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:

  • AST: Application Security Testing
  • AuthN, AuthZ: Authentication and Autorisation Concept and Procedures
  • CI/CD: Continuous Integration / Deployment
  • DAST: Dynamic Application Security Testing
  • DoSP: Denial of Service Protection
  • DRP: Desaster Recovery Plan
  • DRT: Desaster Recovery Test
  • EPP: Endpoint Protection
  • IAM: Identity & Access Management
  • IDS: Intrusion Detection System
  • IRM: Incident response management
  • L2TP: Layer 2 Tunneling Protocol
  • RM: Risk Management
  • SAST: Static Application Security Testing
  • SCA: Software Composition Analysis
  • SIEM: Security Incident Event Monitoring
  • SOAR: Security Orchestration, Automation and Response
  • TA: Threat Analysis and Risk Evaluation
  • TIP: Threat Intelligence Provider
  • TPM: Trusted Platform Module
  • VPN: Virtual Private Network
  • VSS: Video Analytics Systems

Literaturhinweise:

  1. https://about.flipboard.com/support-information-incident-May-2019/, visited Nov 6th, 2019
  2. https://research.checkpoint.com/hacking-fortnite/, visited Nov 7th, 2019
    https://www.upguard.com/breaches/facebook-user-data-leak, visited Nov 6th, 2019
  3. find the standard at ISO IEC OSI Standard 7498, https://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip or a quick introduction at https://en.wikipedia.org/wiki/OSI_model
  4. Andrew L. Russell, IEEE Spectrum, OSI - The Internet That Wasn’t, https://spectrum.ieee.org/tech-history/cyberspace/osi-the-internet-that-wasnt, visited Nov 1st, 2019
  5. Arm Processor Security Update https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability, visited Nov 7th, 2019
  6. IBM PSIRT Blog, https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/, visited Nov. 7th, 2019
  7. Intel Security Centre, https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html, visited Nov, 7th 2019
  8. Danger over the phone - https://www.sit.fraunhofer.de/en/news-events/latest/press-releases/details/news-article/show/gefahr-uebers-telefon/, visited Sept, 15th 2019
  9. „The global state of Information security“ by PWC et al, https://www.pwc.com/sg/en/publications/assets/gsiss-2018.pdf, p. 11, Fig 9, visited Apr 16th, 2019
  10. „2018 Cost of Data Breach“by IBM (https://www.ibm.com/downloads/cas/861MNWN2) shows 24% of all breaches are human based
    An analysis of 20 articles on application (lifecycle) management in the HMD Wirtschaftsinformatik between 2011 and 2017 did not show any article paying explicit respect to the retirement step, while all outline the growing maintenance expense due to changing requirements, see https://dl.gi.de/discover?rpp=10&etal=0&query=application+lifecycle
  11. BSI Lagebericht 2019, Fallbeispiel S.24, „Vorinstallierte Schadsoftware“ (https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Lageberichte/Lagebericht2019.pdf)