Experten-Interview: Workload Protection

Mrz 25, 2021 | Solutions

Workloads sind in der Regel nicht mehr nur im eigenen Datacenter. Doch was heisst das in Bezug auf deren Sicherheit? Mario Conrad und Michael Reber sind zwei ausgewiesene Security-Experten, die über Tücken und Stolpersteine Bescheid wissen.

Mario und Michael, klären wir zuerst eine grundlegende Frage: Welche Rolle spielt Workload Protection im Zusammenhang mit Zero Trust?

Es macht durchaus Sinn, den Begriff Zero Trust zuerst isoliert zu betrachten, da unterschiedliche Leute verschiedene Vorstellungen des Begriffs haben. Wir betrachten Zero Trust als eine Sammlung von Konzepten und Ideen für Prozesse, Systemarchitektur und Betrieb, die zur Verbesserung der IT-Sicherheit verwendet werden können. Zero Trust ist ein End-zu-End-Architekturansatz zum Schutz von Unternehmensressourcen und -daten. Je nach Referenz erhält man so z.B. drei, sechs, neun oder sogar noch mehr Kernsäulen. Die einzelnen «Blauklötze» sind dabei grundsätzlich immer herstellerunabhängig zu betrachten. Schauen wir etwas detaillierter auf die Definitionen. NIST (National Institute of Standards and Technology) befindet sich am einen Ende der Skala und definiert direkt jede einzelne Komponente, z.B. Identity Management, SIEM, Threat Intelligence, Vulnerability Management, Compliance etc. Dieser Ansatz macht den Begriff Zero Trust sehr greifbar und ist uns Engineers auch nahe. Cisco hingegen gliedert Zero Trust in drei grosse Säulen, welche verschiedene Komponenten zusammenfassen: Workforce, Workplace und Workload. Dieser Ansatz wiederum bricht die Komplexität herunter und hilft, den Gesamtüberblick zu behalten.

Workload Protection bildet ein Kernelement jeder Zero-Trust-Architektur und schützt, wie der Name bereits aussagt, den Workload. Ob es sich dabei um VM, Bare-Metal-Host, Container oder Serverless handelt, in der Cloud oder on-Prem, ist grundsätzlich irrelevant. Wichtig ist, dass Workload Protection als Teil der gesamten Architektur betrachtet wird, somit seinen Teil zur Sicherheit beiträgt, aber nicht alleiniger Schutzmechanismus sein darf.

Und welche Bedingungen müssen für eine saubere Zero-Trust-Architektur erfüllt sein?

Wir haben bereits die Prozessebene angesprochen. Um Zero Trust sauber umzusetzen, benötigt man ein Zusammenspiel vieler einzelnen Puzzleteile. Diese müssen gut geplant und vor allem getestet werden. Die ursprüngliche Aufteilung in Silos (Netzwerk, Server, Sicherheit, Applikation) ist beim Zero-Trust-Ansatz undenkbar. Es muss teamübergreifend kommuniziert und entschieden werden, welcher Prozess und welches Tool auf welcher Ebene welche Aufgabe erfüllt. Klassisch war der Netzwerk-Admin für die Policy zuständig. Dies wird sich in Zukunft ändern oder hat sich bereits geändert, da Applikationen immer mehr in den Fokus rücken (DevOps). Die Grenzen zwischen Applikationen und Workloads verschmelzen also immer mehr und «Development, Integration und Produktion»-Ansätze gewinnen wieder mehr an Bedeutung.

Weitere Kernelemente für eine saubere Umsetzung der Zero-Trust-Architektur bilden das «Whitelist Policy Model», «Least Privilege-Prinzip», «Application Security» und der ausschliessliche Einsatz von Software, welche gewartet und weiterentwickelt wird. Cloud-Lösungen haben hier oft den Vorteil, dass sie für den Endbenutzer wartungsarm oder im Besten fall sogar wartungsfrei sind.

Zuletzt wäre da doch der Paradigmenwechsel weg von «Systeme schützen» zu «Assume Breach». Konkret heisst dies, dass man nicht davon ausgeht, dass man gehackt werden könnte, sondern es nur eine Frage der Zeit ist, bis man gehackt wird. Die eingesetzten Mechanismen sollen einem in diesem Falle unterstützen, den Angriff möglichst schnell zu isolieren, den Schaden gering zu halten und zurück zur Normalität zu kehren.

Wie eingangs erwähnt, sind Workloads meist nicht nur im Datacenter, sondern auch in der Cloud, als VMs, Container oder sogar Serverless. Wie schütze ich in einem solch komplexen Umfeld meine Workloads und die Infrastruktur richtig?

Es gibt nicht nur einen Weg und vieles hängt von der Infrastruktur und bereits eingesetzten Mechanismen ab. Klar ist jedoch, dass neue Lösungen möglichst Infrastruktur-unabhängig sein sollen. Um die Frage zu beantworten, muss man zuerst wissen, vor was oder wem man sich schützen will. Will ich Workloads in der DMZ vor spezifischen Attacken schützen, ist wohl eine NGFW oder IDS/IPS ein Ansatz. Möchte ich einen Ausbruch aus einem Container bei einer Lücke verhindern, kann SELinux unterstützen. Ist mein primäres Ziel, East-West-Traffic zu segregieren, sind Cisco Tetration oder Palo Alto Prisma Cloud mögliche Kandidaten. Wenn eigene APIs in der Cloud vorhanden sind, bieten API Gateways Schutz. Solche Fragen müssen jeweils detailliert im Rahmen eines Kunden-Workshops geklärt werden. Einige der wichtigsten Faktoren sind das Hardening, sowie Configuration und Vulnerability Management. Diese werden noch oft vergessen. Mit kurzlebigen Workloads rücken die Themen aber wieder mehr in den Fokus. Workloads und Applikationen sollen also bereits möglichst sicher bereitgestellt werden.

Heisst das schlussendlich, dass ich mein gesamtes bestehendes Security-Konzept in den Papierkorb werfen und überarbeiten muss?

Ganz und gar nicht. Secure Workload soll Teil des Security-Konzepts sein und nicht dieses ersetzen. Eine genaue Analyse der Risiken und wie allenfalls bestehende Lücken geschlossen werden können, ist ein kontinuierlicher Prozess. Die Anpassung und Erweiterung des Security-Konzepts ist davon nicht ausgenommen. Neue Themen wie API Security, Cloud Workload Protection etc. gehören zu dieser Strategie. Neue Lösungen müssen auf die jeweilige Umgebung zugeschnitten, auf den Kunden adaptiert und entsprechend angepasst werden. Um dies zu erreichen, muss sich die Denkweise im Security-Umfeld hin zu einem iterativen Prozess wandeln. 

Konkret auf Produkte bezogen, welche Lösungen gibt es, um diese Ansätze umzusetzen?

Palo Alto Prisma Cloud und Cisco Secure Workload (ehemals Tetration) decken sehr viele der oben genannten Use Cases ab. Konkret heisst dies, man gewinnt Visibilität in seiner Fabric, kann automatisiert Compliance und Vulnerability Assessments durchführen, wird im Falle einer Attacke bei den forensischen Analysen unterstützt und kann ähnlich einer traditionellen Layer 3 & 4 Firewall Policy auf die Workloads pushen. Egal ob sich diese on-Prem oder in einer Cloud befinden. Beide Lösungen sind ebenfalls on-Prem als auch aus der Cloud beziehbar und somit auch in puncto Transparenz des Datenaufbewahrungsortes flexibel.

Worin unterscheiden sich diese Produkte?

Grundsätzlich bieten beide Produkte Workload Protection an und die Funktionalität überlappt sich an vielen Orten. Die Entscheidung, welches das «bessere» ist, hängt also stark vom Use Case und den Anforderungen ab. Geht es eher um Container-Plattformen, API, Serverless Functions oder um die Integration einer CI/CD Pipeline, punktet die Palo Alto-Lösung. Stehen Flow-Visibilität, Applikationsanalyse in Richtung Performance oder die Integration und das Zusammenspiel mit einer bestehenden Cisco-Infrastruktur im Vordergrund, hat Cisco Secure Workload die Nase vorne.  

Und wo bieten die Produkte keine Unterstützung?

Die weiteren Kernelemente bzw. Säulen der Zero-Trust-Architektur müssen natürlich genau so detailliert umgesetzt werden wie Workload Protection, um einen bestmöglichen Schutz zu garantieren. Security Awareness Training allem voran, denn das schwächste Glied bleibt weiterhin oft der Mensch. Technisch gesehen könnte man meinen, Firewalls werden mit den genannten Lösungen hinfällig. Firewalls bieten jedoch erweiterte Funktionen, welche diese Produkte aufgrund der Architektur nicht unterstützen. Nennenswert sind z.B. Malware Sandboxing oder IPS-Funktionalitäten. Klar ist jedoch, dass mit einem weiteren Werkzeug mehr und neue Möglichkeiten entstehen, wie man Security umsetzen kann.

Gerne helfen Mario Conrad und Michael Reber und unterstützen Sie bei der Auswahl Ihrer richtigen Werkzeuge, damit Ihre Workloads als auch die gesamte Infrastruktur geschützt sind.