Fallstudie 03 — Sicherheitsarchitektur
Wir haben in Sicherheit investiert — fühlten uns aber trotzdem nicht sicher
Firewall, Endpoint-Schutz und Monitoring waren vorhanden. Budgets waren ausgegeben worden. Dennoch konnte niemand im Unternehmen mit Überzeugung antworten: „Sind wir wirklich sicher?"
Ausgangslage
Firewall, Endpoint-Schutz und Monitoring waren vorhanden. Budgets waren ausgegeben worden. Dennoch konnte niemand im Unternehmen mit Überzeugung antworten: „Sind wir wirklich sicher?" Das Unbehagen hielt an, trotz der sichtbaren Investitionen in Sicherheitswerkzeuge.
Das Unbehagen war berechtigt. Es spiegelte eine reale Lücke zwischen dem Erscheinungsbild von Sicherheit und der tatsächlichen Sicherheitslage wider — eine Lücke, die die Werkzeuge allein nicht schließen konnten.
Das Problem
Sicherheit existierte als Sammlung von Tools — nicht als kohärentes System. Die zugrundeliegende Infrastruktur war flach, ohne echte interne Grenzen. Jedes Werkzeug tat das, wofür es konzipiert war. Aber die Architektur, die diese Werkzeuge schützten, war grundlegend permissiv.
- Keine Netzwerksegmentierung — flache Topologie von Anfang bis Ende, ohne Trennung zwischen Benutzer-Workstations, Servern und sensiblen Systemen
- Laterale Bewegungspfade in der gesamten Umgebung weit offen — jedes kompromittierte Gerät konnte jedes andere Gerät erreichen, ohne eine Sicherheitsgrenze zu überschreiten
- Ein kompromittierter Endpunkt konnte alles im Netzwerk erreichen — die Firewall schützte den Perimeter, aber es gab keinen internen Perimeter
- Werkzeuge waren vorhanden; Architektur fehlte — Sicherheit wurde als Produktkategorie behandelt, nicht als Designproblem
Warum Sicherheits-Tools allein niemals ausreichen
Sicherheitsprodukte sind darauf ausgelegt, innerhalb einer Architektur zu funktionieren. Eine Firewall setzt Regeln an einer Grenze durch — aber wenn es keine internen Grenzen gibt, kann die Firewall nur gegen Bedrohungen schützen, die von außen kommen. Endpoint-Erkennung kann kompromittierte Rechner identifizieren — aber nicht verhindern, dass kompromittierte Rechner andere Systeme erreichen, wenn es keine Netzwerk-Level-Beschränkung dieser Bewegung gibt.
Was FM-NetSec Nordic unternahm
- Ordnungsgemäße Netzwerksegmentierung entworfen, ausgerichtet an Geschäftsfunktion und Risikoprofil — Trennung von Benutzer-Workstations, Servern, sensiblen Systemen und Management-Infrastruktur in abgegrenzte Segmente
- Kontrollierte Vertrauenszonen mit definierten Zugriffsgrenzen eingeführt — interne Perimeter geschaffen, wo zuvor keine existierten
- Laterale Bewegungspfade deutlich reduziert — ein kompromittiertes Gerät in einem Segment konnte Geräte in anderen Segmenten nicht mehr ungehindert erreichen
- Bestehende Tools mit einer kohärenten, durchsetzbaren Architektur verbunden — Firewall, Endpoint-Schutz und Monitoring arbeiten nun innerhalb einer Struktur, die ihre Warnungen umsetzbar macht
Ergebnis
- Klares, erklärbares Sicherheitsmodell, das Stakeholder verstehen und prüfen konnten
- Deutlich reduzierte Angriffsfläche in der gesamten Umgebung
- Tatsächliche, nachweisbare Kontrolle über die Infrastruktur
„Sicherheits-Tools ohne Architektur vermitteln ein falsches Sicherheitsgefühl."
Nach der Behebung konnte der Kunde die ursprüngliche Frage mit Überzeugung beantworten. Nicht weil mehr Produkte hinzugefügt worden waren, sondern weil die Infrastruktur so gestaltet worden war, dass sie verteidigbar war — und die bestehenden Tools nun innerhalb einer Architektur arbeiteten, die ihnen einen sinnvollen Handlungsspielraum gab.
Fragen zu diesem Fall
Warum haben Sicherheits-Tools keine echte Sicherheit geliefert?
Die Tools funktionierten wie konzipiert – aber die Architektur, die sie schützten, war flach und permissiv. Eine Firewall setzt Regeln an Grenzen durch; wenn keine internen Grenzen existieren, kann sie nur gegen externe Bedrohungen schützen. Endpoint-Detection erkennt kompromittierte Geräte, kann aber nicht verhindern, dass diese andere Systeme erreichen, wenn keine Netzwerkebenen-Einschränkungen existieren.
Was bedeutet 'flaches Netzwerk' in diesem Kontext?
Ein flaches Netzwerk hat keine interne Segmentierung – alle Geräte können standardmäßig alle anderen Geräte erreichen. Ein kompromittiertes Gerät, ein böswilliger Insider oder ein Angreifer, der den Perimeter umgeht, hat uneingeschränkten Zugang zu allem.
Was wurde implementiert, um die Architektur zu verbessern?
Netzwerksegmentierung mit definierten Zonen für verschiedene Geräteklassen und Risikostufen, interne Firewall-Regeln nach dem Prinzip der geringsten Privilegien und Zugriffskontrollen, die sicherstellen, dass Geräte nur erreichbar sind, was sie legitim benötigen.
Was ist die wichtigste Erkenntnis für Organisationen, die in Sicherheits-Tools investieren?
Sicherheitsprodukte sind darauf ausgelegt, innerhalb einer Architektur zu funktionieren. In Tools zu investieren, ohne in die Architektur zu investieren, die diese Tools schützen, schafft eine Sammlung von Sicherheitsprodukten – aber kein kohärentes Sicherheitssystem.
