Operationalisierung von Zero Trust – Schritt 4: Vorschreiben, welche Daten benötigt werden

Diese Blogreihe erweitert die Ideen aus meinem März-Beitrag „ Zero Trust ist nicht schwer … wenn man pragmatisch ist“.

In diesem Beitrag habe ich sechs Schritte zum Erreichen von Zero Trust skizziert, und hier möchte ich auf einen dieser Schritte eingehen, nämlich die Vorschrift, welche Daten benötigt werden. Ich zeige Ihnen, wie dieser Schritt die Implementierung eines soliden Frameworks unterstützen kann, das von jedem Sicherheitspraktiker genutzt werden kann, um seine Projekte erfolgreicher zu machen, unabhängig von der Größe des Unternehmens.

Bevor ich beginne, hier eine Auffrischung der sechs Schritte:

Schritt 4: Legen Sie fest, welche Daten benötigt werden

Im letzten Beitrag dieser Reihe habe ich mich mit den Themen „Bestimmen, auf welche Säule von Zero Trust man sich konzentrieren soll“ und „Festlegen der genauen Kontrollmaßnahmen“ beschäftigt. Die Auswertung dieser Schritte führte zu folgenden Erkenntnissen, die Ihnen bei der Umsetzung von Zero Trust helfen sollen:

• Ermitteln Sie, auf welche Säule von Zero Trust Sie sich konzentrieren sollten: Workload-Sicherheit und -Transparenz, da die von Ihnen durchgeführte Zero Trust Maturity Assessment diese beiden Säulen als die mit den größten Lücken identifiziert hat.
• Geben Sie das genaue Steuerelement an: Da bei der Bewertung ein übermäßiger Netzwerkzugriff als die größte Sicherheitslücke identifiziert wurde, konzentrieren Sie sich auf die Mikrosegmentierung.

Sobald Sie sich genau darauf konzentriert haben, wofür Sie den Schutz verbessern und welche Kontrollen Sie nutzen möchten, können Sie damit beginnen, die Informationen zusammenzustellen, die für die effektive Implementierung solcher Kontrollen erforderlich sind.

Beginnen wir mit dem gewünschten Endzustand:

• Sie möchten eine Mikrosegmentierungsrichtlinie erstellen, um Ihre Workloads zu schützen.
• Sie möchten, dass diese Richtlinie den Prinzipien von Zero Trust folgt.
• Daher dürfen die von Ihnen erstellten Regeln nur den Zugriff auf und aus Ihren Workloads zulassen, die zum Ausführen ihrer Geschäftsfunktion erforderlich sind.

Also, was brauchen Sie dafür? Je nachdem, ob Sie bereits über Kenntnisse über notwendige Abläufe verfügen oder ob Sie in einer Brownfield-Umgebung, die bereits seit vielen Jahren in Betrieb ist, wirklich bei Null anfangen, haben Sie möglicherweise zwei leicht unterschiedliche Antworten darauf.

• Wenn Sie bereits über Kenntnisse verfügen: Angeben einer Segmentierungsregel basierend auf Quell-IP, Ziel-IP, Port und Protokoll
• Wenn Sie sich in einer Brownfield-Umgebung befinden: Erhalten Sie Traffic-Protokolle, die Ihnen helfen, Flüsse zu identifizieren, die relevant sein könnten

Haben Sie schon einmal viele Stunden und Tage damit verbracht, sich die Datenverkehrsprotokolle von Firewalls anzusehen, um herauszufinden, was eine bestimmte Verbindung tut? Und waren Sie gezwungen, nach Informationen oder Personen zu suchen, die einen wertvollen Kontext für einen Fluss liefern können, damit sein Zweck richtig verstanden werden kann? Haben Sie dies für die nächste Zeile in den Protokollen wiederholt, und die nächste und die nächste...? Stellen Sie sich nun vor, Sie müssten dies für alle Anwendungen im Bereich der Segmentierung tun – nicht meine Vorstellung von Spaß. Klingt so, als würde man immer wieder "die Nadel im Heuhaufen finden" spielen.

Stellen Sie sich nun ein alternatives Universum vor, in dem all diese großartigen Verkehrsdaten plötzlich mehr als nur die standardmäßigen 5 Tupel an Informationen liefern. Was wäre, wenn Sie stattdessen den Kontext einer Verbindung sofort erfassen könnten, ohne diese Suche durchführen zu müssen, so dass Sie den Kontext eines Verkehrsereignisses einfach durch Betrachten verstehen können? Es ist, als würde man von einem Schwarz-Weiß-Film ohne Ton zu einem Film in 4K mit Dolby Atmos-Sound wechseln.

Um dies in einen Kontext zu setzen, verwenden wir ein Beispiel.

Übliches Verkehrsprotokoll:

• Quelle: 10.0.0.1
• Ziel: 192.168.0.1
• Anschluss: 53
• Protokoll: UDP
• Aktion: Zulassen

Verkehrsprotokoll mit Kontext:

• Quelle: 10.0.0.1
• Quellkontext: Webserver, Zahlungsanwendung, Produktion, Großbritannien
• Ziel: 192.168.0.1
• Ziel: Kontext: DNS-Responder, DNS-Infrastruktur, Produktion, Großbritannien
• Zielprozess: benannt
• Anschluss: 53
• Protokoll: UDP
• Aktion: Zulassen

Als Anwendungsbesitzer oder Mitglied eines Sicherheitsbetriebsteams ist eine Version des Ereignisses eindeutig überlegen. Die Version mit Kontext bietet ein vollständiges Bild des Ablaufs: Man kann sehen, dass der Production Payments Web Server eine Abhängigkeit vom Production DNS Responder hat, der den benannten Prozess besitzt, der Verbindungen auf Port 53/udp empfängt. Als Prüfer können Sie schnell entscheiden, ob es sich um einen für Sie interessanten Datenfluss handelt, ob es sich um normalen Datenverkehr handelt oder ob eine weitere Untersuchung erforderlich ist. Man kann es leicht klassifizieren (oder sogar ein Werkzeug entwickeln, um es automatisch zu klassifizieren), und das ist nur wegen des zusätzlichen Kontextes möglich, der Ihnen zur Verfügung steht.

Einer der wichtigsten Aspekte von Zero Trust – und er erhält nicht annähernd so viel Abdeckung, wie er sollte – ist, dass eine effektive Implementierung von Zero Trust auf den Zugriff auf Kontextinformationen oder Metadaten angewiesen ist, um die Formulierung von Richtlinien zu unterstützen. Wenn Sie also über Mikrosegmentierung im Zusammenhang mit dem Schutz von Workloads sprechen, beschreiben die minimalen Metadaten außerhalb eines Standard-Traffic-Berichts, die Sie benötigen, Workloads im Kontext Ihrer Rechenzentrumsanwendungen und -umgebungen.

Illumio Core verwendet diese Metadaten, die aus der CMDB einer Organisation oder einer anderen maßgeblichen (oder autoritativen) Quelle stammen, um die einem Workload zugeordneten Labels zu füllen. Diese Bezeichnungen verknüpfen jede Arbeitslast mit einer Rolle, einer Anwendung, einer Umgebung und einem Standort und helfen uns, eine umfassende Anwendungsabhängigkeitskarte zu erstellen, die die vorgelagerten und nachgelagerten Abhängigkeiten für jede Anwendung klar identifiziert. Und das versetzt uns in eine hervorragende Position, um Abläufe und Designrichtlinien zu überprüfen.

In meinem nächsten Beitrag werde ich erörtern, wie man eine Zero-Trust-Richtlinie entwirft.

Sind Sie bereit, den nächsten Schritt auf Ihrem Weg zu Zero Trust zu gehen? Besuchen Sie unsere Seite darüber, wie Sie Ihre Zero-Trust-Strategie mit Mikrosegmentierung operationalisieren können.