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

Diese Blog-Serie erweitert die Ideen, die ich in 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 Serie habe ich mich mit "Bestimmen, auf welche Zero-Trust-Säule Sie sich konzentrieren möchten" und "Festlegen der genauen Kontrolle" befasst. Die Auswertung dieser Schritte führte zu den folgenden Eingaben, die Ihnen helfen, die Operationalisierung von Zero Trust voranzutreiben:

• Bestimmen Sie, auf welche Zero-Trust-Säule Sie sich konzentrieren sollten: Sicherheit und Transparenz von Workloads, da das von Ihnen durchgeführte Zero Trust Maturity Assessment diese Säulen als die Säulen 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 des Security Operations Teams ist eine Version des Ereignisses eindeutig überlegen. Die Version mit Kontext bietet ein vollständiges Bild des Ablaufs: Sie können sehen, dass der Production Payments Web Server eine Abhängigkeit vom Production DNS Responder hat, der den benannten Prozess hat, der Verbindungen auf 53/udp empfängt. Als Prüfer können Sie schnell entscheiden, ob es sich um einen Flow handelt, an dem Sie interessiert sind, ob es sich um normalen Traffic handelt oder ob er eine weitere Untersuchung rechtfertigt. Sie können es leicht klassifizieren (oder sogar einige Tools erstellen, um es automatisch zu klassifizieren), und Sie können dies nur aufgrund des zusätzlichen Kontexts tun, den Sie haben.

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 eines Unternehmens oder einer anderen goldenen (oder maßgeblichen) Quelle stammen, um die mit einem Workload verknüpften Labels zu füllen. Diese Bezeichnungen ordnen jeder Workload eine Rolle, eine Anwendung, eine Umgebung und einen Standort zu und helfen uns, eine umfassende Anwendungsabhängigkeitskarte zu erstellen, die Upstream- und Downstream-Abhängigkeiten für jede Anwendung eindeutig identifiziert. Und das versetzt uns in eine großartige Position, um Abläufe zu überprüfen und Richtlinien zu entwerfen.

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.