In den vorherigen Teilen sind immer wieder Begriffe wie Schwachstelle oder Risiko gefallen. Diese Begriffe wollen wir nun in diesem Teil etwas ausführlicher behandeln und mit weiteren Details erläutern. In den weiteren Teilen unserer Kleinserie werden wir das Thema Risikomanagement auch noch ausführlicher behandeln und weitere Details und Hinweise dazu geben.
Schwachstellen
Eine Schwachstelle definiert das Vorhandensein einer Sicherheitslücke in einem IT-System der Organisation. Wird diese Schwachstelle durch einen Angreifer ausgenutzt, kann der Organisation dadurch ein Schaden entstehen. Der Angreifer könnte so z. B. die Integrität der Daten auf dem IT-System negativ beeinträchtigen oder Informationen entwenden.
Daher ist es für eine Organisation unerlässlich, fortwährend auf aktuelle Schwachstellenmeldungen zu achten oder eigene Scans durchzuführen. Ein funktionierendes Schwachstellenmanagement ist daher entscheidend für die Informationssicherheit.
Ein erster Anlaufpunkt ist die Fachpresse oder z. B. der Warn- und Informationsdienst von CERT-Bund. Aktuelle Meldungen können direkt online eingesehen werden: https://wid.cert-bund.de/portal/wid/kurzinformationen
Eine Schwachstelle kann abseits der IT-Systeme jedoch auch in der Umgebung, der Infrastruktur oder dem Personal vorhanden sein. So könnte vor Ort ein instabiles Stromnetz existieren oder das Rechenzentrum, die Produktionshalle oder das Bürogebäude könnte in einem Erdbebengebiet liegen.
Für die Informationssicherheit als solche ist es daher auch unerlässlich, dass nicht nur auf Schwachstellen in IT-Systemen, sondern auf alle kritischen Unternehmensbereiche geachtet wird. Bleiben Schwachstellen unerkannt, unbehandelt oder werden unsachgemäß behandelt, kann dies für die Organisation existenzgefährdend sein.
Beispiele von Schwachstellen:
-
Schwerwiegende Sicherheitslücken in Softwareprodukten
-
Mangelhaft definierter physischer Sicherheitsperimeter
-
Mangelhafte Durchführung von Zugangskontrollen
Bedrohungen
Eine Bedrohung kann ein Angreifer, ein Krimineller oder sogar ein Insider darstellen. Die Ziele sind dabei oft unterschiedlicher Natur, so hat ein Angreifer womöglich das Lahmlegen der Produktion als Ziel, ein Krimineller möchte womöglich die Organisation erpressen und der Insider verkauft die Informationen womöglich an einen Konkurrenten.
Jedoch kann eine Bedrohung auch dann entstehen, wenn ein technischer Fehler vorliegt oder ein Bedienfehler aufgrund falscher Anweisungen oder komplizierter Menüführung entsteht.
Die Bedrohung wirkt immer direkt auf die Information selbst und stellt für diese eine Gefahr dar.
Bedrohungen, die eine Schwachstelle ausnutzen, werden nach BSI-Definition zur Gefährdung. Im BSI IT-Grundschutzkompendium gibt es eine Übersicht über elementare Gefährdungen, welche kostenfrei heruntergeladen werden kann.
Nicht für alle Schwachstellen ist jede Art von Bedrohung relevant, diese müssen auch immer im Kontext betrachtet werden. Eine Applikation, welche bspw. nicht über einen Internetzugriff verfügt, kann aufgrund der fehlenden externen Erreichbarkeit nicht durch einen Angriff von extern bedroht sein. Auch wenn die Applikation durch solche Maßnahmen vor der Bedrohung geschützt wird, sollte diese dokumentiert und regelmäßig geprüft werden. Nur wenn diese Schwachstelle fortwährend sichtbar bleibt, kann bei einer geänderten Bedrohungslage auf diese reagiert werden.
Die Beispiele der Schwachstellen bringen wir nun noch mit einer Bedrohung in Verbindung:
| Schwachstelle | Mögliche Bedrohung |
|---|---|
|
Schwerwiegende Sicherheitslücken in Softwareprodukten |
Unerlaubte Ausführung von schadhaftem Programmcode |
|
Mangelhaft definierter physischer Sicherheitsperimeter |
Unbefugte Dritte können Außenanlagen, z. B. NEA, manipulieren |
|
Mangelhafte Durchführung von Zugangskontrollen |
Unbefugte Dritte gelangen ins Rechenzentrum |
Risiken
Ein Risiko entsteht, wenn eine Bedrohung auf die Schwachstelle des Assets trifft und dieses dadurch negativ beeinträchtigt. Ein Risiko hat in der Informationssicherheit üblicherweise mindestens den Verlust eines der wesentlichen Schutzziele (CIA – "Confidentiality", "Integrity" und "Availability") zur Folge.
Der definierte Risikoprozess identifiziert die Risiken, welche anschließend durch diesen auch analysiert, bewertet und abschließend auch behandeln werden. Dafür ist es notwendig, dass die Organisation ihre Assets identifiziert und dokumentiert hat. Hierbei können Schwachstellen und Bedrohungen für diese Assets definiert werden, welche dann systematisch mit den im Risikoprozess vorgesehenen Methoden initial im Hinblick auf Eintrittswahrscheinlichkeit und Auswirkung bewertet werden.
Die Risiken werden anschließend anhand der Risiko-Matrix kategorisiert und können dadurch strukturiert und systematisch abgearbeitet werden. Wurde ein Risiko mit einer Eintrittwahrscheinlichkeit von häufig (4) aber einer Auswirkung von unbedeutend (1) bewertet, so ist dieses Risiko als "Medium" kategorisiert. Gibt es daneben noch ein Risiko, welches mit jeweils unwahrscheinlich (1) und unbedeutend (1) bewertet wurde, wird dieses als "Low" kategorisiert. Damit sollte klar sein, dass das Risiko welches als "Medium" kategorisiert wurde, vorrangig behandelt werden sollte.
Als Ergebnis liegt nun eine Liste von Risiken vor, welche hinsichtlich Ihrer Kritikalität kategorisiert wurden. Die Risiken sind einem Risikoverantwortlichen zugewiesen, es wurden Maßnahmen getroffen, die geeignet sind, die definierte Risikobehandlung zu unterstützen. Die Risiken können also nun in die Linie gebracht werden, um dort abgearbeitet zu werden.
Die Risiken bleiben in der Liste enthalten und werden regelmäßig erneut betrachtet, um fortwährend auf eine geänderte Bedrohungslage zu reagieren. Risiken sollten so definiert sein, dass diese fortwährend Bestand haben und nicht irgendwann überflüssig werden. Daher ist es wichtig, dass diese nicht auf einem zu detaillierten, aber auch nicht auf einem zu hohen Level, definiert wurden.
Beispiel für eine zu detaillierte Risikodefinition:
"Der Juniper Router MX480 ist bereits in die Jahre gekommen und wurde von Juniper bereits als EoL gekennzeichnet."
Besser wäre hier:
"Der Router ist bereits in die Jahre gekommen und wurde vom Hersteller als EoL gekennzeichnet."
So kann dieses Risiko fortwährend genutzt sowie bewertet werden und hat weder einen Bezug zu einem spezifischen Hersteller noch zu einem Modell.
Beispiel für eine zu abstrakte Risikodefinition:
"Der Server fällt aus."
Besser wäre hier:
"Der Server fällt aufgrund einer zu hohen Temperatur im Rechenzentrum aus."
Sie möchten weitere Informationen zum Thema Informationssicherheit oder einen Beratungstermin vereinbaren? Dann hier entlang: Beratung zu ISO-Normen.
