Die sieben Todsünden des Security Policy Change Managements

Von   Robert Blank   |  Regional Sales Manager DACH   |  AlgoSec
28. Januar 2019

Die Verwaltung ständig wachsender Netzwerksicherheitsrichtlinien wird nicht einfacher. IT- und Cybersicherheit sind mit immer mehr Bedrohungen, der zunehmenden Komplexität und gestiegenen Anforderungen an Sicherheit und Anwendungskonnektivität konfrontiert. Viele Unternehmen versäumen es jedoch, ihren Ansatz für das Management von Sicherheitsrichtlinien anzupassen, um mit diesen Herausforderungen Schritt zu halten. In den letzten Jahren haben sich sieben „Todsünden“ des Security Policy Managements herausgebildet, die in fast jeder Organisation zumindest teilweise stattfinden. Ein genauer Blick im eigenen Unternehmen lohnt sich.

  1. Kein Fokus auf die Geschäftsanwendungen: Wenn ein Verantwortlicher für IT-Sicherheit über Netzwerksicherheit nachdenkt, ist er oft schnell dabei, einen netzwerkzentrierten statt eines anwendungszentrierten Ansatzes zu wählen: Das heißt, er konzentriert sich auf die IP-Adressen, Ports, Protokolle, VPN-Tunnel usw. Das bedeutet allerdings, den Weg und nicht den Zweck zu betrachten. Die Dokumentation konzentriert sich entsprechend oft auf diese Elemente der Infrastruktur. Der Grund, warum der Netzzugang gewährt wurde, erscheint dann als nachträglicher Gedanke im Kommentarfeld, falls er überhaupt nachvollzogen werden kann. Oft denken die Verantwortlichen erst viel später darüber nach, was die wichtigste Frage sein sollte: Warum gibt es diese Regel überhaupt? Welche Geschäftsanwendung unterstützt sie?
  2. Keine Bereinigung der Firewall-Regeln für stillgelegte Anwendungen: Wenn ein Unternehmen eine Anwendung bereitstellt, erstellt die Netzwerksicherheit Regeln und definiert Zugriffsrechte. Wenn jedoch eine Anwendung außer Betrieb genommen wird, geschieht der umgekehrte Schritt selten. Der nicht benötigte und aus Sicht der Sicherheit unerwünschter Zugriff wird beibehalten, weil man befürchtet, dass ein Entfernen zu Problemen führen kann. Der Gedanke scheint zu sein: Wenn es nicht kaputt ist, repariere es nicht. In der Regel ist das Gegenteil der Fall. Die Zugänge, die für keinen Geschäftszweck erforderlich sind, summieren sich und schaffen Unordnung. Dies macht es einem Angreifer viel einfacher, eine erfolgreiche Attacke durchzuführen. Hinzu kommt, dass die Vorbereitung eines Audits erschwert wird.
  3. Duldung oder Förderung einer ineffektiven Kommunikation: Die Wartung einer großen IT-Infrastruktur erfordert mehrere Teams: ein Sicherheitsteam zur Definition und Durchsetzung von Richtlinien, ein Operation-Team zur Sicherstellung der Verfügbarkeit und des ordnungsgemäßen Betriebs des Netzwerks sowie ein Anwendungsteam zur Unterstützung der Geschäftsanwendungen. Typischerweise kümmern sich diese Teams sehr wenig um die Arbeit der anderen Teams und sprechen sehr unterschiedliche Sprachen. Die Kommunikation ist entsprechend katastrophal. Dafür gibt es viele Gründe: unterschiedliche Berichtsstrukturen, kulturelle Unterschiede und unterschiedliche Ziele. Das macht es für jedes Team schwierig, das Netzwerk und seine Herausforderungen genauso zu sehen wie die jeweils anderen, wodurch Fehler auftreten und es zu langen Durchlaufzeiten bei der Bearbeitung von Änderungen kommt.
  4. Unzureichende oder fehlende Dokumentationen: Die Dokumentation ihrer Arbeit ist für die meisten Experten der unangenehmste Teil der IT-Arbeit, aber sie ist entscheidend. Wenn eine Regel nicht dokumentiert ist, geht das Wissen darüber verloren, warum sie konfiguriert wurde. Daraus folgt die Herausforderung, zu wissen, wie man mit Änderungen umgeht, die sich auf eine Richtlinie auswirken. Darüber hinaus führt eine schlechte Dokumentation zu sehr umständlichen Audits, weil ein Auditor nicht damit zufrieden sein wird, wenn man ihm sagt, etwas könne nicht nachvollzogen werden, weil der Verantwortliche das Unternehmen verlassen hat. Die Netzwerksicherheit muss zuverlässig beantworten können, warum eine Regel existiert. Der Versuch, das Monate oder Jahre nach der Implementierung herauszufinden, macht noch mehr Arbeit und Umstände als die anfängliche Dokumentation.
  5. Kein Recycling bestehender Firewall-Regeln und -Objekte: Ein häufiges Problem. Eine Person ruft alle IP-Adressen für die Datenbank „DB_srv“ auf. Wenige Wochen später erstellt jemand anderes „dbserver“ für die gleichen Adressen und ein paar Monate später erstellt jemand „databasesrv“ – erneut für denselben Zweck. Nicht nur, dass all diese Duplikate Unordnung schaffen, es verwirrt jeden im Team, der versucht herauszufinden, warum es drei Datenbanken gibt, welche Unterschiede zwischen ihnen bestehen und ob sie noch benötigt werden.
  6. Wilde Änderungen zulassen: Jedes Unternehmen hat jene Administratoren, die ohne jeden Prozess oder eine Genehmigung ihre Firewall-Konsole starten und Änderungen vornehmen. Das mag mit den besten Absichten geschehen wie eine Ad-hoc-Änderung, die schnell durchgeführt werden muss. Aber selbst dann können die Auswirkungen verheerend sein. Eine Vielzahl von Organisation erlebt immer wieder, dass es zu Anwendungs- und Netzwerkausfällen kommt, die durch Änderungen an den Sicherheitsrichtlinien verursacht werden, ohne dafür eingerichtete Prozesse einzuhalten.
  7. Manuelle Eingabefehler aufgrund „dicker Finger“: Irren ist menschlich, aber ein IT-System wird das nicht verzeihen. Wenn Sicherheitsteams Änderungen manuell codieren oder verarbeiten, laufen sie Gefahr, Fehler zu machen. Diese machen das Netzwerk möglicherweise anfällig für Angriffe oder Ausfälle. Ein Fall ist ein einfacher Tippfehler des Administrators, der versehentlich Port 433 anstelle von Port 443 eingibt, weil er „dicke Finger“ hat. Die Folgen davon können für sein Unternehmen, die Mitarbeiter sowie letztlich die Geschäftsbilanz – im besten Fall – unangenehm sein. Es benötigt allerdings nicht viel, damit eine solche Situation in eine katastrophale Verletzung der IT-Sicherheit resultiert. Ohne eine Möglichkeit, Fehler zu erkennen oder Prozesse zu automatisieren, laufen die Verantwortlichen Gefahr, menschliche Fehler zu machen und Zeit mit Aktivitäten zu verschwenden, die eine Software schnell und zuverlässiger erledigen könnte.

Fazit

Die manuelle Verwaltung von Sicherheitsrichtlinien wird immer schwieriger, weil die Regelkataloge stetig umfangreicher und die Netzwerkinfrastruktur in Unternehmen zunehmend komplexer werden. In vielen Organisationen lässt sich feststellen, dass diese Herausforderung in sieben „Todsünden“ resultiert, deren Minderung Prozesse, Transparenz und Automatisierung erfordert. Diese Schritte in einem Unternehmen zu etablieren, ist aufwendig, aber die notwendige Arbeit ist es wert, da sie sowohl die Sicherheit als auch die Agilität einer Organisation wesentlich verbessern kann.

Robert Blank ist Regional Sales Manager DACH bei AlgoSec, dem führenden Anbieter geschäftsorientierter Lösungen für das Sicherheitsmanagement in der Cloud und im DC. Zuvor hat der Diplom-Informatiker über 15 Jahre Lösungs-/Großkundenvertrieb bei Cisco, Juniper, Level 3 – und die letzten 10 Jahre verstärkt Software und Cloud Vertrieb bei Itizzimo, F24 und Cancom – erfolgreich unterstützt, auf- und ausgebaut.

Um einen Kommentar zu hinterlassen müssen sie Autor sein, oder mit Ihrem LinkedIn Account eingeloggt sein.

21467

share

Artikel teilen

Top Artikel

Ähnliche Artikel