Wenn die Informationssicherheit überreagiert

Kommentieren Drucken

Es kommt durchaus vor, dass durch Veränderungen in der IT-Konfiguration bestehende IT-Sicherheitsrichtlinien verletzt werden. Bei genauerem Hinschauen zeigt sich dann nicht selten, dass eine Richtlinie zu scharf formuliert und letztendlich einfach ignoriert worden ist.

Beispiel: Eine Netzzugangskontrolle soll in einem Unternehmen eingeführt werden, da im Rahmen eines Audits erhebliche Risiken durch den ungesicherten Netzzugang festgestellt wurden. Gleichzeitig wird die Anforderung gestellt, dass Geräte, die sich nicht erfolgreich authentisieren können (z.B. weil ihr Zertifikat abgelaufen ist oder ganz einfach, weil der PC noch einen PXE-Boot-Vorgang bearbeiten und zum Laden des Betriebssystems erst mit der Infrastruktur kommunizieren muss), einen eingeschränkten Netzzugang zu Wartungszwecken bzw. zur Softwareverteilung erhalten. Ähnliches gilt für Geräte, die zwar an das Netz gelassen werden müssen, sich aber nur mit einem Authentisierungsmittel geringer Güte ausweisen können. Das entsprechende Konzept hat hierzu eine Authentisierung am Netzwerkport in Verbindung mit einer dynamischen durch RADIUS gesteuerten logischen Trennung der Gruppen per VLAN und VRF vorgesehen. Die Übergänge zwischen Gruppen würden durch eine zentrale Firewall abgesichert. Das Konzept wird dem IT-Sicherheitsbeauftragten (ITSB) vorgelegt, der es mit dem Hinweis kategorisch ablehnt, dass gemäß einer Sicherheitsricht-linie VLANs zur Trennung von Netzen unterschiedlichen Sicherheitsniveaus nicht gestattet seien.
Ähnliche Situationen sind aus anderen Fällen bekannt, wo es z.B. um die Trennung von Gruppen in einem WLAN oder um die Zonierung und Virtualisierung im Rechenzentrum ging.

Welche technische Alternativen hätten in dem genannten Beispiel bestanden? Wenn keine dynamisch aktivierte ACLs auf den Access Switches zum Einsatz kommen können (was meist ein geringeres Sicherheitsniveau darstellt), bleiben nur der Aufbau einer nicht betreibbaren Lösung, der Verzicht auf den Einsatz einer Netzzugangskontrolle oder man macht es einfach trotzdem wie geplant. Die Folge könnte daher sein, dass Vorgaben des ITSB bei Infrastrukturprojekten und anderen Changes künftig immer öfter einfach ignoriert werden.

Das beschriebene Beispiel illustriert zwei Problembereiche:

Erstens mag die zugrundeliegende Sicherheitsrichtlinie zwar schön konkret sein, sie ist jedoch zu streng und geht an den Realitäten in der modernen IT (hier der Virtualisierung) vorbei. Die Richtlinie hätte besser Kriterien liefern müssen, wann unterschiedliche Systeme physikalisch (oder mit einem vergleichbar starken Mittel) zu trennen sind und wann eine logische Trennung erlaubt ist. Es werden leider zu oft in Sicherheitsrichtlinien Maximalforderungen gestellt. Dies passiert nicht zuletzt deshalb, weil sich der ITSB auf der sicheren Seite wähnen möchte („lieber mehr Sicherheit als zuwenig“) und selber die eigenen Richtlinien nicht umsetzen muss. Außerdem hinken Sicherheitsrichtlinien oft der Zeit hinterher und werden von Innovationen in der IT überholt. Es ist eine Kunst, gute und nachhaltig umsetzbare Sicherheitsrichtlinien zu entwickeln und dabei stets den aktuellen Stand der Technik in der IT reflektieren.

Zweitens hat in dem Beispiel der ITSB eine zwar standfeste aber vielleicht zu kompromisslose Haltung eingenommen. Wahrscheinlich wäre es besser gewesen, als Vermittler zwischen dem Wunschzustand einer Richtlinie und dem Alltag in der IT aufzutreten. Das Ergebnis hätte ein ausgehandelter Kompromiss sein können, der eine gute Balance zwischen Machbarkeit, Wirtschaftlichkeit und Restrisiko dargestellt hätte. Dass eine solche Kompromissfindung aufwendig sein kann und ggf. nicht das gewünschte Sicherheitsniveau darstellt, ist nicht schön, ist aber besser als nichts und insbesondere besser als eine Richtline zu ignorieren. Wenn sich der ITSB als aktiver Lösungsarchitekt sieht, dessen Sicherheitsgebäude kein Luftschloss werden, sondern akzeptiert und so einen nachhaltigen Bestand haben soll, kommt er um diese Rolle des Vermittlers auch nicht herum. Letztendlich ist die im Beispiel beschriebene Kompromisslosigkeit auch ein Zeichen eines nicht richtig gelebten Risikomanagements und damit seinerseits sogar ein Sicherheitsrisiko.

Wichtig ist also, dass der ITSB nicht nur Richtlinienkompetenz hat, sondern sich auch aktiv an der Umsetzung seines Richtlinienapparats beteiligt und vielleicht sogar hieran (zu einem gewissen Anteil) sein Erfolg gemessen wird.

zugeordnete Kategorien: IT-Sicherheit, LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

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

*

.