Andreas Sperber 08. Mai 2018

Wo ist die Knautschzone von IT-Systemen?

Wer sich eingesteht, dass Sicherheitsvorfälle zu erwarten sind, muss weiter denken. © konradbak / Fotolia.com — © konradbak / Fotolia.com

Seit der Erfindung des Benz Patent-Motorenwagens Nummer 1 im Jahre 1886 hat das moderne Automobil eine enorme Entwicklung durchlebt. Nicht nur Platz und Komfort haben sich weiterentwickelt, auch wurden die Wagen mit der Zeit immer sicherer. Baute man anfänglich besonders steife Karosserien, wodurch sich bei einer Kollision zwar das Gefährt nur geringt verformte, aber die Insassen besonders schwere Verletzungen erlitten, so gibt es heute die Knautschzone. Sie absorbiert beim Aufprall einen großen Teil der Energie und schützt damit im Fall der Fälle Menschenleben.

Die Informationstechnologie hat eine mindestens ebenso enorme Entwicklung durchlaufen. Schnell wurde deutlich, dass Vorfälle durch Unachtsamkeit, technisches Versagen oder böswillige Hackerangriffe weitreichende Konsequenzen haben können. Aus diesem Grund hat die Informationssicherheit bisher versucht Vorfälle mit allen Mitteln zu verhindern. Burgmauern in Form von Perimeter-Firewalls wurden errichtet, Virenscanner installiert und es wurde versucht, mit Code-Überprüfungen Fehler zu erkennen.

Und dann passiert der Super-Gau doch immer wieder: Yahoo verliert 2013 beim bisher größten Angriff in der Geschichte alle drei Milliarden Nutzerkonten [1]. 2016 verschweigt der Fahrdienstvermittler Uber einen Verlust von 57 Milliarden Nutzerdaten und verpasst es bis Ende 2017 verantwortungsvollerweise Betroffene zu informieren [2]. Und kürzlich erfuhr die Öffentlichkeit von einem gravierenden Sicherheitsvorfall beim Informationsverbund Berlin-Bonn, einem Netzwerk des Bundes [3]. Vermeintlich sichere Strukturen haben versagt und es drängt sich die Frage auf, wo die Knautschzone von IT-Systemen bleibt – diejenige, die das System vor dem Abfluss sensitiver Daten beschützt?

Sicherheitsvorfälle verhindern oder erwarten?

Die Vorstellung, erfolgreich von böswilligen Hackern angegriffen zu werden, ist beunruhigend. Sie zu verdrängen, wäre jedoch blauäugig. Dies hat die Informationssicherheitsbranche nun seit einigen Jahren erkannt: wollte man früher Sicherheitsvorfälle verhindern, so geht man heute davon aus, dass irgendwann in der Zukunft ein Angriff doch erfolgreich ist. Diese Erkenntnis ist für den Aufbau von resilienten Systemen entscheidend, für die es keine absolute Sicherheit gibt. Vielmehr werden Systeme mit einer Knautschzone konstruiert, die Vorfälle für eine Organisation erträglich gestalten.

Um in alter Manier Sicherheitsvorfälle zu verhindern (Prevent Breach), sollten Systeme zunächst sicher entworfen und umgesetzt werden. Hierzu wird ein Bedrohungsmodell erstellt, das individuell die Gegebenheiten der Anwendung berücksichtigt. Geschulte Fachleute realisieren das Vorhaben nach dem Stand der Technik und vermeiden Umsetzungsfehler durch Audits.

Wer sich dann aber eingesteht, dass Sicherheitsvorfälle zu erwarten (Assume Breach) sind, muss weiter denken: bei einem Vorfall sollte der entstehende Schaden besonders klein bleiben und es sind Prozesse zu definieren, wie in solch einer Situation gehandelt werden muss. Beispielsweise können Netzwerke physisch oder virtuell segmentiert werden. Wurde ein Netzwerkteilnehmer kompromittiert, ist potentiell nur ein bestimmter Netzabschnitt betroffen. Am Beispiel einer Webanwendung könnten besonders sensitive Daten nur verschlüsselt gespeichert werden. Gelangen Hacker in Besitz der Datenbank, können diese mit dem verschlüsselten Kauderwelsch nichts anfangen. Ebenso ist ein Detektionsmechanismus, ein sogenanntes Intrusion Detection System ((IDS), erforderlich, um den Vorfall überhaupt zu bemerken. Wenn der eintritt, wissen Verantwortliche, wie Schaden abzuwenden ist und ob gegebenenfalls Betroffene informiert werden müssen.

Einen Schritt voraus

Sicherheitsvorfälle grundsätzlich für möglich zu erachten bedeutet, den Angreifern einen Schritt voraus zu sein. Wer folgende Grundsätze wie Defense in Depth befolgt oder das Schadensausmaß eindämmt, kann Vorfälle bestmöglich bewältigen und schnell darauf reagieren.

Design sicherer Anwendungen

Wenn man Sicherheitsvorfälle in Betracht zieht, führt dies keinesfalls zu der fatalistischen Sichtweise "man könne ja ohnehin nicht wirklich etwas gegen Angreifer tun". Es ist unabdingbar, sichere Anwendungen zu planen und umzusetzen, um einer Kompromittierung des eigenen Systems zuvorzukommen. Neben funktionalen Anforderungen müssen Anforderungen an die Informationssicherheit definiert werden, die vom Bedrohungsmodell abgeleitet werden können. Muss eine Anwendung beispielsweise besonders sensitive Daten speichern, die von einem anderen System weiterverarbeitet werden, könnte man diese Daten asymmetrisch verschlüsselt speichern.

Grundsätzlich sind folgende Punkte relevant für alle Anwendungen:

Validierung aller Benutzereingaben.
Sichere Verarbeitung von Daten, beispielsweise durch Prepared Statements oder Überprüfung von Keyed-Hash Message Authentication Codes (HMAC).
Sichere Ausgabe von Variablen in Templates.
Authentifikation und Autorisierung.

Durch Segmentierung von Systemen kann der Durchmarsch eines Angreifers verhindert werden.

Defense in Depth

Defense in Depth folgt unweigerlich aus der Erkenntnis, dass Sicherheitsvorfälle zu erwarten sind. Diese Vorfälle entstehen nämlich durch den Fehler einer Komponente, ob durch technisches Versagen, menschliche Fehler oder mangelhaftes Design. Security in Depth – auch Zwiebelschalenprinzip genannt – fordert den Aufbau mehrerer Schutzschichten. Versagt eine davon, bleibt das System weiterhin geschützt. Ein Beispiel für die Redundanz von Schutzmechanismen gegen Cross-Site-Scripting (XSS) ist neben dem Einsatz von Output Escaping die Formulierung einer restriktiven Content Security Policy (CSP).

Eindämmung

Die Eindämmung der Auswirkung eines Angriffs ist ein wesentliches Prinzip, um Schaden zu begrenzen. Durch Segmentierung von Systemen kann der Durchmarsch eines Angreifers verhindert werden. Wer dem Datenbankbenutzer einer Anwendung minimale Rechte gibt, realisiert bereits dieses Prinzip: Dieser Datenbankbenutzer benötigt im Produktivbetrieb keine Rechte wie DROP oder GRANT und er muss auch nicht auf andere Datenbanken zugreifen können. Ebenso tragen dezentrale Systeme zur Eindämmung bei. Besonders sensitive Bereiche können ausgegliedert und besonders geschützt werden.

Zentrale Überwachung

Die zentrale Überwachung ist Voraussetzung, um Angriffe überhaupt erst erkennen zu können. Wer auf die Erpresser-E-Mail mit einer horrenden Bitcoin-Forderung wartet, kommt zu spät. Systeme benötigen ein zentrales, datenschutzkonformes Logging. Aus diesen Daten und dem Netzwerkverkehr können Intrusion Detection-Systeme (IDS) Angriffe erkennen und Intrusion Prevention-Systeme (IPS) Angriffe nach bestimmten Regeln abwehren. Als ganzheitlicher Ansatz versteht sich das Security Information and Event Management (SIEM), welches einem Unternehmen erlaubt, Sicherheitsvorfälle schnell zu untersuchen. Diese qualifizierten Aussagen sind wichtig, da stets Informationen über die Art und den Umfang des Vorfalls benötigt werden. Wem das Wissen oder die Ressourcen für das SIEM fehlen, kann sie an ein sogenanntes Security Operations Center (SOC) auslagern. Das SOC besteht aus einem Expertenteam, das sich rund um die Uhr um die Sicherheit der Systeme kümmert.

Datensparsamkeit

Wer keine Daten hat, kann sie auch nicht verlieren. Diese Leitspruch steht natürlich im Widerspruch zum Big Data-Paradigma, und dennoch: es sollte die Frage gestellt werden, ob bestimmte Daten wirklich benötigt werden und ob man bei einem Sicherheitsvorfall den Verlust dieser Daten verantworten kann. Beispielsweise müssen Bankverbindungen oder andere Zahlungsdaten nicht bei einem selbst (zusätzlich) gespeichert werden, sondern ausschließlich beim Bezahldienstanbieter. Wer dennoch sensitive Daten speichern muss, sollte sich überlegen, wie lange er diese Daten benötigt und ob er sie nach einer bestimmten Zeit löschen oder anonymisieren kann. Dies ist ohnehin eine zentrale Forderung der bevorstehenden Datenschutz-Grundverordnung (DSGVO/GDPR) [4].

Die Erfahrung hat gezeigt, dass absolute Sicherheit selten erreicht wird.

Verantwortlichkeiten definieren und den Ernstfall proben

Tritt ein Ernstfall ein, ist es wichtig, schnell reagieren zu können. Verantwortlichkeiten eines Notfallteams und auch das grundsätzliche Vorgehen müssen geklärt sein. Hierzu gehört es, unmittelbar Schaden abzuwenden, Beweise zu sichern, Dienste wiederherzustellen und verantwortungsvoll Betroffene und Behörden zu informieren. Der Ernstfall sollte in regelmäßigen Abständen geprobt (War Gaming) und Erfahrungen zur Prozessverbesserung genutzt werden.

Penetrationstests der Produktivsysteme

Ein Penetrationstest ist eine beauftragte, nachvollziehbare Prüfung durch Sicherheitsspezialisten, die ein System angreifen und versuchen, bestimmte Schutzziele zu verletzen – beispielsweise Daten zu erbeuten. Um böswilligen Hackern zuvor zu kommen, sollten an Produktivsystemen Pentests durchgeführt werden. Schließlich muss genau dieses System Angreifern standhalten können – und die kennen kein Pardon.

Für Vorfälle gewappnet

Es ist also an der Zeit, die Informationssicherheit von Systemen einen Schritt weiterzubringen. Sicheres Design und dessen Umsetzung ist ein Muss. Doch die Erfahrung hat gezeigt, dass absolute Sicherheit selten erreicht wird. Wer sich eingesteht, dass Vorfälle zu erwarten sind, hat Sicherheit richtig verstanden und kann für die rettende Knautschzone sorgen.

Quellen