Von Netzwerk-Regelchaos zur Application Ownership

Wie DORA den Verantwortungswechsel erzwingt 
– und wie wir ein System gebaut haben, das funktioniert

Mit DORA – dem Digital Operational Resilience Act der EU – ist für Finanzinstitute eine neue Ebene der operativen Kontrolle verpflichtend geworden. Es geht längst nicht mehr nur um Verfügbarkeit oder Datenschutz. Gefordert sind systematische, auditierbare Prozesse – vom Risk Management bis zur Infrastruktur-Security.

In vielen Organisationen werden Firewall-Regeln von Network-Teams angelegt, auf Zuruf von App-Teams implementiert und gelegentlich von Security überprüft. Doch wenn es um Ownership geht – also die Frage: „Wer ist eigentlich verantwortlich dafür, dass diese Regel noch existiert?“ – dann lautet die Antwort oft: niemand.

Und genau dort beginnt das Chaos: Firewalls wachsen über Jahre hinweg zu unübersichtlichen Monstern heran, voll mit Legacy-Regeln, die sich niemand zu löschen traut. Wenn überhaupt, werden Reviews manuell, unregelmäßig und ohne Bezug zum Anwendungskontext durchgeführt.

DORA verlangt, das zu beheben. Nicht nur theoretisch – sondern operativ. Und belegbar.

Artikel 13(h): Firewall-Regeln im Fokus

Ein Abschnitt im Gesetz stellt klar:

„Finanzunternehmen müssen die Rollen und Verantwortlichkeiten sowie die Schritte zur Spezifikation, Implementierung, Genehmigung, Änderung und Überprüfung von Firewallregeln und Verbindungsfiltern definieren...“

Und weiter:

„Für ICT-Systeme, die kritische oder wichtige Funktionen unterstützen, müssen diese Regeln mindestens alle sechs Monate überprüft werden.“

Klingt ambitioniert? Ist es auch – besonders, wenn der aktuelle Prozess aus verstreuten Excel-Dateien, veralteten Tickets oder Vermutungen besteht.

Unsere Antwort auf die zentrale Frage:

„Für welche Applikation existiert diese Firewallregel – und ist sie noch notwendig?“

Wir haben ein System entwickelt, das diese Frage automatisch beantworten kann. Der erste Schritt: die Zusammenführung verteilter Datenquellen – darunter Firewall-Konfigurationen und -Logs, CMDB-Daten, LeanIX zur Applikationszuordnung sowie F5 Load Balancer-Mappings.

Statt all das wieder in Tabellen zu kippen, haben wir die Beziehungen in einer Neo4j graph database modelliert – denn bei Firewall-Regeln geht es um Beziehungen: zwischen Quelle und Ziel, NAT, Services, Zonen und Applikationen.

Das Ergebnis ist eine lebendige Topologie, die zeigt:

• Welche Regeln welche Applikationen betreffen
• Wer für sie verantwortlich ist
• Und welcher Traffic tatsächlich fließt

Image

📷 Illustration: Graph-basierte Visualisierung von Infrastrukturbeziehungen – zeigt, wie ein zentrales Objekt (z. B. eine Firewallregel oder IP-Adresse) mit Dutzenden abhängigen Elementen im realen Netzwerkumfeld verbunden ist.

Review-Prozesse, die wirklich Sinn ergeben

Auf dieser Grundlage haben wir uns dem gewidmet, worauf es DORA besonders ankommt: der Review-Fähigkeit. Application Owner erhalten gezielte Reports, die nur die für ihre Systeme relevanten Regeln anzeigen. Sie müssen keine Firewall syntax beherrschen – sondern nur bewerten, ob eine Verbindung für ihre Applikation sinnvoll ist. Ein einfaches Ja/Nein, gestützt durch reale Traffic-Daten.

Security-Teams bekommen gleichzeitig die volle Sicht auf Regelverwendung und Compliance-Fragen. Sind „any-any“-Regeln verboten? Ist Logging aktiv? Gibt es redundante oder überschattete Regeln? Alles ist nachvollziehbar – mit Timestamp – für die Audits.

Warum dieser Ansatz anders ist – und DORA-ready

Es geht nicht nur um Data Integration oder Automatisierung. Es geht um einen Shift in Ownership: Applikationsteams werden selbst verantwortlich für die Angemessenheit ihrer Firewallregeln – aber mit dem richtigen Kontext und den passenden Tools. Keine Tribal Knowledge mehr. Keine Excel-Archäologie. Kein Rätselraten vor dem Auditor. Das ist echte Operational Resilience: Datenbasiert. Kollaborativ. Auditierbar.

Was wir gelernt haben

Ja, Firewallregel-Reviews lassen sich automatisieren. Aber die eigentlich wichtige Erkenntnis ist: Sobald App-Teams sehen, welche Regeln in ihrem Namen aktiv sind, übernehmen sie Verantwortung.

Klar – nicht jede Applikation ist perfekt in LeanIX modelliert, und manche Konfigurationen haben mehr Legendenstatus als Substanz. Aber mit mehr Sichtbarkeit wächst auch das Verantwortungsgefühl. Und regelmäßige Reviews werden zur Routine – nicht zur Ausnahme.

Was als Nächstes kommt

DORA ist nicht nur eine regulatorische Pflicht – sondern eine echte Chance, Altlasten zu beseitigen, Ownership sauber zu verteilen und Firewall-Reviews endlich effizient zu machen.

Wenn du dich schon mal gefragt hast, was sich wirklich in deiner rulebase versteckt – und wer sich darum kümmern sollte – dann ist jetzt der richtige Zeitpunkt, es herauszufinden.

Lass uns darüber sprechen

Wir haben ein System gebaut, das Firewallregeln sichtbar, reviewbar und zuweisbar macht – und das bereits heute hilft, von reaktiver Bereinigung zu proaktiver Kontrolle zu wechseln.

Aber wir sind auch neugierig:

– Welche Herausforderungen habt ihr beim Mapping von Regeln zu Applikationen erlebt?
– Wie geht ihr mit veralteten Regeln oder zombie configs um?
– Fühlen sich eure App-Teams durch Ownership eher gestärkt – oder überfordert?
– Wie schließt ihr den Kreis zwischen Review und Regelentfernung?
– Und wie DORA-ready fühlt ihr euch wirklich?

Wir freuen uns auf eure Perspektive – oder zeigen euch gerne live, wie unser System funktioniert.

👉 Jetzt Demo mit unserem Engineering Team vereinbaren

Diese Lösung entsteht in enger Zusammenarbeit mit NetworkedAssets – einem in Berlin und Wrocław ansässigen Software-Engineering-Unternehmen, das für seine Expertise in den Bereichen Network Automation, Analytics und Diagnostics bekannt ist.

Durch die Kombination unserer Erfahrung in Connectivity, Security und Hybrid Cloud Architekturen bei Logicalis Connected mit dem pragmatischen, agilen „Software for Complex Systems“-Ansatz von NetworkedAssets haben wir eine Plattform entwickelt, die weit über reine Compliance hinausgeht – und tatsächlich verändert, wie Firewallregeln verwaltet und verantwortet werden.

Image