IT-Security: Das System ist sicher…, oder?!

Dass Security eine zunehmend wichtige Eigenschaft heutiger Systeme ist und mit der Digitalisierung noch an Priorität zunimmt, ist unumstritten. Systeme werden untereinander und mit Apps und Online-Diensten vernetzt. Daten und Datenverarbeitung werden in die Cloud verschoben. Aber wann ist ein System sicher?

Markus Fockel ist Seniorexperte in der Abteilung Softwaretechnik & IT-Sicherheit des Fraunhofer IEM.

Hundertprozentigen Schutz gegen Hackerangriffe gibt es nicht. Jeden Tag werden neue Sicherheitslücken bekannt, die es zu schließen gilt. Das Auftreten immer neuer Viren fordert uns zudem heraus, unsere Antivirensoftware regelmäßig zu aktualisieren. IT-Sicherheit ist ein Wettrennen mit den Angreifern.
Die Frage ist also nicht, ob man Security benötigt oder nicht, sondern, wie schwierig man es Angreifern machen muss und welches Restrisiko man zu tragen bereit ist. Welche Schutzmaßnahmen benötigt man dafür? Soll das System nur sicher vor sogenannten Script-Kiddies sein, die einfach mal ausprobieren, wie weit sie mit einfachen Hackerwerkzeugen kommen, oder vor Industriespionage durch Wettbewerber oder gar ausländische Geheimdienste?
In der Praxis kapitulieren Unternehmen regelmäßig vor dieser schwierigen Abwägung und vertagen daher das Thema Sicherheit. Jedoch hilft ein systematisches Vorgehen dabei, eine realistische Einschätzung zur notwendigen Security zu erstellen. Dazu sollte man sich ein Lagebild der schützenswerten Elemente, der vorhandenen Schutzmaßnahmen und der potentiellen Bedrohungen erstellen. Ein solches Lagebild wird im Rahmen einer sogenannten Bedrohungsanalyse erzeugt. Ziel ist die systematische Beantwortung der folgenden Sicherheitsfragen:

  • Sicher unter welchen Bedingungen?
    Die Sicherheit eines Systems hängt immer auch vom Einsatzkontext ab. Schutzmaßnahmen, die bereits durch die Umgebung realisiert werden, reduzieren das Risiko für das System. Annahmen über solche vorausgesetzten Schutzmaßnahmen sind unbedingt festzuhalten. Ist das System in einem separaten Netzwerk vom Internet getrennt? Befindet sich das Gerät in einem Raum, zu dem nur ein eingeschränkter Personenkreis Zugang hat?
  • Was ist schützenswert und wogegen soll es geschützt werden?
    Eine wichtige Grundlage zur Identifikation und Bewertung nötiger Schutzmaßnahmen ist die Kenntnis, welche Teile des Systems genau schützenswert sind. Wo befinden sich die schützenswerten Dinge wie Kundendaten, kryptografische Schlüssel, etc. – die sogenannten Assets? Sind diese identifiziert, schließt sich die Frage an, welche Schutzziele für diese gelten. Sollen Informationen vertraulich bleiben? Soll auch deren Integrität (Fälschungssicherheit) sichergestellt sein? Muss das (Teil-)System durchgehend verfügbar bleiben oder ist ein Ausfall, zum Beispiel durch eine sogenannte Denial-of-Service-Attacke verkraftbar?
  • Welche Sicherheitsanforderungen erfüllt das System bereits?
    Aus den allgemeinen Schutzzielen für die identifizierten Assets lassen sich feingranulare Sicherheitsanforderungen an Teile des Systems ableiten. Diese werden durch Schutzmaßnahmen erfüllt. Beispiele für Schutzmaßnahmen sind die Verschlüsselung von schützenswerten Daten oder die Verwendung von Kommunikationsprotokollen mit Schutz gegen Manipulation. Es gilt also zu prüfen, welche Schutzmaßnahmen bereits ergriffen wurden und welche Anforderungen damit erfüllt sind.
  • Was sind potentielle Bedrohungen für das System?
    Werden Sicherheitsanforderungen nicht vollumfänglich von Schutzmaßnahmen erfüllt, existieren Bedrohungen für die zugehörigen Assets. Sind die oben skizzierten Fragen beantwortet, lassen sich diese verbleibenden Bedrohungen durch Methoden wie STRIDE systematisch ermitteln. Dabei werden die einzelnen Elemente des Systems auf Basis verschiedener Bedrohungskategorien untersucht. Wäre es zum Beispiel möglich, trotz fehlender Berechtigung auf Daten in der Cloud zuzugreifen? Kann jemand mit Berechtigungen die Daten zerstören? Können Veränderungen an den Daten auf den Verursacher zurückgeführt werden?
  • Wie hoch ist das verbleibende Restrisiko?
    Für jede identifizierte Bedrohung lässt sich individuell das Risiko bewerten. Dieses drückt aus, wie wahrscheinlich ein Angriff ist, der sich aus dieser Bedrohung ableitet und wie kritisch die Auswirkungen solch eines Angriffs für das System bzw. das Unternehmen wären. Durch vorhandene Schutzmaßnahmen reduziert sich das Risiko einer Bedrohung, ein Restrisiko verbleibt jedoch. Jedes Unternehmen muss für sich entscheiden, welches Restrisiko es akzeptiert. Ist das Risiko noch zu hoch, sollten weitere Schutzmaßnahmen umgesetzt werden, bis man dieses auf ein akzeptables Minimum reduziert hat.

Die Frage „Ist das sicher?“ lässt sich selten pauschal beantworten. Die schützenswerten Assets, deren Schutzziele und deren Bedrohungslage sind für jedes System unterschiedlich. Auch die Risikobewertung und Risikoakzeptanz ist typischerweise unternehmensindividuell. Eine systematische Bedrohungsanalyse ebnet den Weg zu einem ausreichend sicheren System und einer klaren Bewertung, was man darunter versteht. Insbesondere bildet sie die Entscheidungsgrundlage für die Integration von Schutzmaßnahmen und der Bewertung des Sicherheitsrisikos. Selbstverständlich sollte die Bedrohungsanalyse in regelmäßigen Abständen wiederholt werden, um neuen Erkenntnissen über die allgemeine Sicherheitslage und Veränderungen am System selbst Rechnung zu tragen. Ein systematisches, wiederholbares Vorgehen und eine geeignete Werkzeugunterstützung reduzieren dabei den Aufwand auf ein angemessenes Maß.

Die systematische Bedrohungsanalyse ist der grundlegende Baustein für „Security by Design“. Unter diesem Stichwort werden Aktivitäten zusammengefasst, die jedes Unternehmen bei der Entwicklung ergreifen kann, um die IT-Sicherheit der eigenen Produkte wesentlich zu erhöhen. Das Fraunhofer IEM unterstützt bei der individuellen Umsetzung von Aktivitäten zu Security by Design, unter anderem bei der systematischen Bedrohungsanalyse.

Der Autor
Dr. Markus Fockel ist Seniorexperte in der Abteilung Softwaretechnik & IT-Sicherheit des Fraunhofer IEM. Er promovierte an der Universität Paderborn zum Thema Safety Requirements Engineering und leitet heute im Themenfeld Requirements Engineering für Security & Safety Projekte mit Industriepartnern aus verschiedenen Branchen. Ein Schwerpunkt dieser Projekte ist die Optimierung des Entwicklungsprozesses bezüglich Security by Design und Bedrohungsanalysen.