Vorbeugen ist besser als nachbessern müssen

Dirk Schadt Cloud Computing, Compliance, Datenschutz, Gastbeitrag, Kommentar, Sicherheit / Security Leave a Comment

Nachdem wir zuletzt erörtert haben, dass Fehlervermeidung durchaus der Planbarkeit im Projekt als auch später dem Betrieb des Produkts oder Service zugutekommt, stellt sich die naheliegende Frage, wie man selbst das so hinbekommt, dass man auch wirksame Ergebnisse erzielt.

Niemanden ist damit gedient einfach nur vertragskonform oder „compliant“ zu sein, vielleicht noch unnötig die Werte des Unternehmens zu riskieren, zumal das Kriminelle und Hacker auch reichlich wenig imponiert oder gar abschreckt.

Sicherheitslücken haben den Nachteil, dass sie relativ klein sein können um doch recht große Wirkung zu erzielen. Also ist es sinnvoll strukturiert vorzugehen, anstatt aus dem Expertenbauch heraus empfohlen, ein paar offensichtliche Maßnahmen einzubauen, welche am Ende dann doch Lücken übersehen.

Welche Modelle erzeugen relativ angemessene Sicherheitsmaßnahmen?

In erster Linie muss man ermitteln, welche Maßnahmen tatsächlich wirken und zu der Funktionalität und Betriebsfähigkeit des eigenen Produktes passen. Alles andere wäre ökonomisch nicht angezeigt, denn ein übersteigertes Maß an Sicherheit ist einfach nur unangemessen, wirkungslose Maßnahmen dagegen Ressourcenverschwendung.

Formal kann man das als Sicherheitskonzept bezeichnen, natürlich mit einem begrenzten Geltungsbereich bezogen auf das Produkt, welches man gerade plant und dessen Funktionalität und was alles darauf Einfluss nehmen kann wie Administrationsprozesse oder Berichtswesen.

Demnach muss jede Sicherheitsmaßnahme ein tatsächliches Risiko adressieren, im besten Fall beseitigen oder zumindest mindern. Maßnahmen, welche keine Risiken wirksam adressieren sind somit sinnfrei und im besten Fall dazu geeignet den Ruf von Sicherheitsexperten ad absurdum zu führen.

Deshalb ist es essentiell, dass für das geplante Produkt eine Risikobewertung durchgeführt wird. Auch hier gilt, wenn das nicht möglichst vollständig und realitätsnah erfolgt, werden Risiken nicht erkannt oder im schlimmsten Fall verschleiert. Das ist jedoch Hackern und Kunden wiederum egal. Risiken verschwinden nicht einfach durch Ignoranz, wegdiskutieren oder im Keller neben den anderen Leichen vergraben. Und Kunden oder Anleger reagieren härter als Aufsichtsbehörden, welche Unwissenheit manchmal noch als leichte Fahrlässigkeit werten.

Für die Bewertung von Risiken benötigt man wiederum zwei Parameter. Die Eintrittswahrscheinlichkeit eines Schadens und die maximal mögliche Auswirkung eines Schadens. Wenn wir Produkte neu bauen und nach dem Mantra „Fehler frühest möglich im Prozess vermeiden“ handeln, können wir jedoch meistens nicht auf Erfahrung oder Fehlerstatistiken zurückgreifen. Das ist etwas für den Modus Nachbessern bei Fehlern.

Also können wir selten Häufigkeiten für eine Eintrittswahrscheinlichkeit heranziehen. Die Beurteilung kommt eher aus dem Bauch. Als hilfreich hat sich erwiesen unabhängige und unbeeinflusste Meinungen zum betrachteten Sachverhalt von mehreren Leuten zu erhalten, die noch nicht mal Experten sein müssen. Methodisch wird diese „Weisheit der Vielen“ [1] auch bei „wer wird Millionär“ oder Kursbewertung an der Börse eingesetzt. Hat man dann Einzelrisiken als Frage bzw. Schadenszenario formuliert, kann man abfragen, wie wahrscheinlich es ist, dass dieses Szenario eintritt.

Natürlich muss auch das Schadensszenario in seiner Auswirkung bewertet werden, am besten in Euro, steht dem doch eine zu finanzierende Maßnahme entgegen. Das geht nicht immer einfach, den Auswirkungen haben unterschiedliche Stoßrichtung wie

  • Verfügbarkeit (zumeist als SLA im Vertrag vereinbart),
  • Rechtsverstoß (bis zu 4% vom Umsatz oder 20 Millionen € bei DSGVO),
  • Vertraulichkeitsbruch (v.a. durch Industriespionage wie bei Enercon oder Toyota),
  • Imageverlust (50 % Kursverlust bei Yahoo Übernahme)  
  • etc.

Diese Varianten von Schäden beeinflussen sich auch noch gegenseitig, lassen sich aber als Orientierung leicht auf die primären Schutzziele der Informationssicherheit

  • Vertraulichkeit,
  • Integrität und
  • Verfügbarkeit

mappen. Viele Unternehmen haben bereit sinnvolle Auswirkungstabellen beschrieben, die vor allem den Produktverantwortlichen helfen sollen, das jeweilige Ausmaß des Schadensszenarios zu bewerten.

Jetzt braucht man nur noch eine vollständige Liste von Szenarien, richtig?

Und die sind quasi das schwierigste in der ganzen Methode. Natürlich gibt es die Gefährdungskataloge aus dem IT Grundschutz des BSI [2], welche solche Szenarien sehr detailliert und auch relativ vollständig durchdeklinieren, aber nur für bereits bekannte und nicht immer vergleichbare Einsatzzwecke und Infrastrukturen. Das sind alles bekannte und standardisierte Umgebungen und basiert auf Fehlern anderer. Die Gefährdungskataloge stoßen sehr schnell an die Grenze bei Neuartigem, dem was vorher kein anderer gemacht hat. Das gilt besonders bei neuen Geschäftsideen und deren Umsetzung, denn die Differenzierung ist es meist, was neue Produkte ausmacht. Zudem beschreibt Gefährdung bekannte Szenarien, daraus abgeleitete Risiken die nicht sinnvoll adressiert sind gehören in den Bereich Risikoappetit oder Fahrlässigkeit, je nach Managementstrategie.

Unbekannte Szenarien sind dagegen besser als Bedrohung definiert, sind jedoch nicht so greifbar wie reale Gefährdungen. Und vollständig Bedrohungen zu ermitteln ist eine Herkulesaufgabe, wenn man nicht strukturiert und methodisch da herangeht.

Die Vollständigkeit gegenüber der Szenarienbildung „aus dem Bauch“ entsteht durch Betrachtung der geplanten Prozessabbildung zu dem geplanten Produkt, der eingesetzten Softwarearchitektur und der voraussichtlich verwendeten Systeminfrastruktur. Da sich Schadensauswirkungen gerne an den verwendeten Daten und deren Wert orientieren, bietet sich an Datenflüsse oder Prozessdarstellungen als Grundlage der Bewertung zu nutzen. Solange alle Datenflüsse bzw. Prozesse betrachtet werden, sollten sich auch alle Risiken, besser eigentlich, alle Bedrohungen modellieren lassen.

Und die bestehen im Grunde daraus zu simulieren, wie üblicherweise ein Hacker angreifen würde, also Verfügbarkeit beeinträchtigen, Identitäten fälschen, Berechtigungen erobern und missbrauchen, Daten ändern, Spuren verwischen, etc.

Das zugrunde liegende Modell wurde vom Microsoft schon 1999 unter dem Akronym STRIDE entwickelt und ist in den Secure Development Lifecycle (SDL)[3] integriert worden.

Durch bloße Anwendung dieser Angriffsvektoren lässt sich so eine mehr oder weniger vollständige Bedrohungslandkarte der Produktarchitektur abbilden. Natürlich macht nicht jeder Angriff auf jedes Element auch wirklich Sinn, aber so wird nichts vergessen oder „untermodelliert“. Die Kunst besteht darin zu erkennen, welche der Angriffssimulationen sinnfrei ist, und welche Simulationsvarianten benötigt werden, welche durch generische Bedrohungsbäume abgebildet werden, An der Stelle gibt es zwar einige unterstützende Werkzeuge [4][5], aber hier liegt auch genau die Schwäche, nämlich sich nicht auf die Ergebnisse der Werkzeuge zu verlassen, solange man die Qualität der Bedrohungsbäume und Handlungsempfehlungen nicht einschätzen oder nachbessern kann.

Abgearbeitet werden kann das Sicherheitskonzept natürlich dann in umgekehrter Reihenfolge, also mit der Sammlung der Architekturskizzen anfangen, daraus ein Bedrohungsmodell erstellen wo nötig und daraus die Risiken als Prioritätenmodell ableiten. Das geht zugegebenermaßen immer noch am leichtesten in einer Tabellenkalkulation. Je höher die Risiken um so mehr benötigt man um diese zu behandeln. Daraus leitet sich ein Maßnamenkatalog ab, der in die Budgetplanung einfließen muss.

Im Grunde hat man zu einer recht frühen Zeit im Projekt bereits alles, was nötig ist um eine tragfähige Beurteilung zu erarbeiten, welche Risiken in einem Produkt bleiben, und welche beseitigt werden können.

Handwerkliche Fehler werden auch mit guter Planung nicht ausgemerzt, aber es hilft viele Fehler frühzeitig zu vermeiden und eventuell Kontrollmechanismen zu etablieren um einfach erkennen zu können, ob das Produkt dann so funktioniert wie es soll und nicht ausgenutzt wird.

Es ist offensichtlich, dass ein Sicherheitskonzept somit in den verschiedenen Phasen eines Projektes unterschiedlichen Reifegrad und Aussagekraft besitzt. Demnach sollte ein Sicherheitskonzept verpflichtendes Dokument und integraler Bestandteil des eigenen Projektvorgehensmodells sein, sei es nun wasserfallartig oder agil.

Methodenmodelle wie SAMM [6] haben solche Vorgehensweisen bereit berücksichtigt, setzen aber zudem darauf in unterschiedlichen Phasen eines Projektes passende Prüfungen ansetzen zu können, die sich gegenseitig ergänzen. So hilft es ungemein bei Softwareentwicklungsanteilen den zugehörigen Code zu analysieren und bei der Installation mögliche Schwächen der Konfiguration und Wirkumgebung durch Penetrationstests zu auditieren.

Produktverantwortliche und Unternehmen die sich jedoch nur auf Penetrationstests verlassen, handeln heutzutage eher fahrlässig. Gerne wird hier auch noch der Prüfrahmen so eingeschränkt, dass er ein gefälliges Ergebnis erwarten lässt. Das ist vergleichbar mit den Zertifikaten und Testaten von Dienstleistern, die gerne vorgezeigt werden, aber selten die relevante datenverarbeitende Umgebung betrachten. Die Erfahrung und die Vorfälle zeigen, dass auch viel Erfahrung von Sicherheitsexperten gepaart mit wenig Struktur zu eher zufälligen Ergebnissen und Qualität führen. ‚Klein-Scopen“ dagegen verschleiert Risiken und eine nur abschließende Prüfung übersieht eher viel als dass sie Fehler aufdecken kann.


Links


Siehe auch

Hinterher hat man es meist vorher gewusst


Gastbeitrag von Dirk Schadt

Dirk Schadt beschäftigt sich seit über 20 Jahren mit Informationssicherheit und Datenschutz. Ursprünglich hat er als Ingenieur und Systemarchitekt für ein Systemhaus Sicherheitssysteme implementiert, später als Business Development Manager den Aufbau der eigenen Fachbereiche vorangetrieben. Er hatte daneben lange Zeit einen Lehrauftrag zu KRITIS, war und ist in unterschiedlichen Interessensverbänden wie der GI eV. aktiv und veröffentlich unregelmäßig auch Artikel. Seit 2007 ist Dirk Schadt selbständiger Berater und begleitet vor allem Innovations-, Reorganisations- und Strategieprojekte sowie Interimsmandate, die einen engen Bezug zu Informationsmanagement und mit dessen Risiken zu tun haben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.