Zero Trust operationalisieren — Schritt 4: Vorschreiben, welche Daten benötigt werden

Diese Blogserie erweitert die Ideen, die ich in meinem März-Beitrag vorgestellt habe,“Zero Trust ist nicht schwer... Wenn Sie pragmatisch sind.“

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

Bevor ich anfange, hier eine Auffrischung der sechs Schritte:

Schritt 4: Geben Sie vor, welche Daten benötigt werden

In der letzter Beitrag In dieser Serie habe ich mir die Themen „Bestimmen Sie, auf welche Zero-Trust-Säule Sie sich konzentrieren sollten“ und „Spezifizieren Sie die genaue Steuerung“ behandelt. Die Bewertung dieser Schritte führte zu den folgenden Informationen, die Sie bei der Operationalisierung von Zero Trust unterstützen sollen:

• Legen Sie fest, auf welche Zero-Trust-Säule Sie sich konzentrieren sollten: Workload-Sicherheit und -Transparenz, weil die Zero-Trust-Reifegradbewertung Sie haben diese als die Säulen mit den größten Lücken identifiziert.
• Geben Sie die genaue Steuerung an: Da bei der Bewertung ein übermäßiger Netzwerkzugriff als die größte Sicherheitslücke identifiziert wurde, werden Sie sich auf die Mikrosegmentierung konzentrieren.

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

Fangen wir mit dem gewünschten Endzustand an:

• 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 müssen die Regeln, die Sie erstellen, nur den Zugriff auf und aus Ihren Workloads zulassen, der für die Erfüllung ihrer Geschäftsfunktion erforderlich ist.

Also, was brauchst du dafür? Je nachdem, ob Sie bereits über vorhandene Kenntnisse über die notwendigen Abläufe verfügen oder ob Sie in einer Brachfläche, 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 Vorkenntnisse verfügen: Geben Sie eine Segmentierungsregel an, die auf Quell-IP, Ziel-IP, Port und Protokoll basiert
• Wenn Sie sich in einer Brachfläche befinden: Holen Sie sich Verkehrsprotokolle, um Verkehrsströme zu identifizieren, die relevant sein könnten

Haben Sie schon einmal viele Stunden und Tage damit verbracht, sich die Verkehrsprotokolle von Firewalls anzusehen, um herauszufinden, was eine bestimmte Verbindung tut? Und waren Sie gezwungen, nach Informationen oder Personen zu suchen, die einen wertvollen Kontext zu einem Datenfluss liefern können, sodass dessen Zweck richtig verstanden werden kann? Haben Sie das für die nächste Zeile in den Protokollen wiederholt und für die nächste und die nächste...? Stellen Sie sich jetzt vor, Sie müssten das für alle Anwendungen tun, für die eine Segmentierung in Frage kommt — nicht meine Vorstellung von Spaß. Klingt, als würde man wiederholt „Finde die Nadel im Heuhaufen“ spielen.

Stellen Sie sich nun ein alternatives Universum vor, in dem all diese großartigen Verkehrsdaten plötzlich mehr als nur die üblichen 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, sodass Sie den Kontext von Verkehrsereignissen verstehen könnten, indem Sie ihn sich einfach ansehen? Es ist, als würde man von einem Schwarzweißfilm ohne Ton zu etwas in 4K mit Dolby Atmos-Sound wechseln.

Um dies in einen Zusammenhang zu bringen, lassen Sie uns ein Beispiel verwenden.

Übliches Verkehrsprotokoll:

• Quelle: 10.0.0.1
• Zielort: 192.168.0.1
• Hafen: 53
• Protokoll: UDP
• Aktion: Erlauben

Verkehrsprotokoll mit Kontext:

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

Als Anwendungseigentümer oder Sicherheitsoperationen Teammitglied, eine Version der Veranstaltung ist 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, bei dem der benannte Prozess 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 weitere Untersuchungen erforderlich sind. Sie können ihn leicht klassifizieren (oder sogar einige Tools entwickeln, um ihn automatisch zu klassifizieren), und das ist nur aufgrund des zusätzlichen Kontextes möglich, den Sie haben.

Einer der wichtigsten Aspekte von Zero Trust — und es wird nicht annähernd so viel Beachtung geschenkt, wie es sollte — ist Eine effektive Umsetzung von Zero Trust hängt vom Zugang zu Kontextinformationen oder Metadaten ab, um bei der Formulierung von Richtlinien zu helfen. Wenn Sie also von Mikrosegmentierung im Zusammenhang mit dem Schutz von Workloads sprechen, beschreiben die minimalen Metadaten außerhalb eines Standarddatenverkehrsberichts, 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 goldenen (oder autoritativen) Quelle stammen, um die mit einer Arbeitslast verbundenen Labels auszufüllen. Diese Labels ordnen jedem Workload eine Rolle, eine Anwendung, eine Umgebung und einen Standort zu und helfen uns bei der Erstellung einer umfassenden Abbildung der Anwendungsabhängigkeiten das identifiziert eindeutig Upstream- und Downstream-Abhängigkeiten für jede Anwendung. Und das versetzt uns in eine hervorragende Position, um Abläufe zu überprüfen und Richtlinien zu entwerfen.

In meinem nächsten Beitrag werde ich erläutern, wie eine Zero-Trust-Richtlinie entworfen wird.

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