Cloud-native Sicherheit schonungslos analysiert:Wo Intention und Praxis auseinanderklaffen

22. Juli 2020

Kaum eine Industrie ist so sehr von Buzzwords getrieben wie die der Cyber Security. Selbst für Profis ist es oft schwer Marketing und Markt-Realität auseinanderzuhalten. Eines dieser Schlagworte lautet „Cloud-nativ“. Was aber bedeutet Cloud-nativ?

Eine Anwendung ist Cloud-nativ, wenn sie vom ersten Tag an für die organische Nutzung von API-gesteuerten Plattformen erstellt wurde. Dies ist das genaue Gegenteil von „Lift and Shift“. Wie wirkt sich dieser Wechsel zu Cloud-nativ auf das Risiko für Unternehmen aus? Palo Alto Networks ist dieser Frage kürzlich in einer branchenweit ersten Umfrage unter mehr als 3.000 Fachleuten nachgegangen.

Anzeige
banner digitaler arbeitplatz jetzt v

Es gibt drei interessante Parallelen, die sich bei dieser Umfrage im Vergleich zur alltäglichen Bedrohungsforschung von Palo Alto Networks ergeben haben.

Skalierung und Automatisierung

Die Studie zeigt, dass 45 Prozent der Unternehmen, die als sehr gut vorbereitet bewertet wurden, Sicherheit in die DevOps-Prozesse eingebettet haben. Im Gegensatz dazu haben 21 Prozent der am wenigsten vorbereiteten Unternehmen Sicherheit in DevOps eingebettet.

Sicherheitsexperten sagen oft, dass die Skalierbarkeit das Problem ist. Es hat den Anschein, dass DevOps-Projekte immer unverhältnismäßig schneller wachsen, egal wie viele Personen und Tools versuchen, das Problem der Sicherheit anzugehen. Selbst in den am besten ausgestatteten Sicherheitsteams dürfte dies auch weiterhin der Fall sein, solange die Unternehmen zu wenig in die Automatisierung investieren.

Nach Angaben der Cloud Native Computing Foundation gibt es weltweit schätzungsweise 4,7 Millionen Native-Cloud-Entwickler. (ISC)2 hat nur 2,8 Millionen Cyber-Sicherheitsexperten weltweit gefunden. Das ist das Problem. DevOps-Teams machen starken Gebrauch von der Automatisierung, weil sie dadurch ohne proportionalen Personalbestand skalieren können. Eine Möglichkeit, dies zu erreichen, ist die Verwendung von Infrastructure-as- Code (IaC)-Template. Für Anfänger ersetzen IaC-Templates den manuellen Prozess der Erstellung einer Cloud-Infrastruktur.

Das Schöne daran ist, dass, sobald die Architektur der Anwendung in einem IaC-Template definiert ist, dieses unbegrenzt oft wiederverwendbar ist. Jedes Mal erhält man die gleiche Umgebung. Dieser Ansatz ist skalierbar. Der Nachteil ist: Wird ein Template mit einer Fehlkonfiguration erstellt (z.B. wenn ein sensibler Dienst dem gesamten Internet ausgesetzt wird), wird diese Schwachstelle bei jeder Verwendung des Templates neu erstellt. An dieser Stelle kommt die Automatisierung der Sicherheit ins Spiel.

Beleg: Im Cloud Threat Report vom Frühjahr 2020 stellten die Forscher von Unit 42 fest, dass 42 Prozent aller CloudFormation (CFT)-Dateien mindestens eine unsichere Konfiguration enthielten. Die Forscher fanden auch heraus, dass 22 Prozent aller Terraform-Dateien mindestens eine unsichere Konfiguration enthielten.

Fazit: DevOps-Teams setzen IaC und andere Formen der Automatisierung in großem Stil ein. Das Sicherheitsteam muss dasselbe tun und gleichzeitig mehr Security-Touchpoints in den Softwareentwicklungszyklus einbetten.

Straffung der Tools

Die Umfrage ergab, dass gut vorbereitete Unternehmen erkennen, dass mehr Sicherheitswerkzeuge es schwieriger machen, Risiken zu priorisieren und Bedrohungen zu verhindern. Mit anderen Worten, mehr Sicherheitstools bedeuten nicht weniger Risiko. Der Einsatz mehrerer punktueller Produkte bewirkt sogar das Gegenteil. In einer Untersuchung von Sicherheitstools sowohl für On-Premises als auch die Cloud stellte Palo Alto Networks fest, dass viele kleine Unternehmen bis zu 20 Sicherheitstools einsetzen. Bei mittleren Unternehmen reichte diese Zahl bis zu 60, die größeren, wie etwa große Finanzdienstleistungsunternehmen, setzen sogar rund 130 Tools ein.

Die Zahlen speziell für Cloud-Computing sind unverhältnismäßig kleiner. 42 Prozent der Befragten nutzen elf oder mehr Cloud-Security-Anbieter. Diese Zahl wird im Laufe der Zeit sicherlich noch steigen. Der Grund dafür ist, dass die meisten Sicherheitsteams versuchen, jeder neuen Cyberherausforderung mit einem weiteren Tool zu begegnen. Dieser Ansatz ist nicht nachhaltig, und er wird in der Cloud nicht skalieren.

Beleg: Die Bedrohungsforscher von Unit 42 fanden heraus, dass 65 Prozent der Sicherheitsvorfälle in der Cloud auf Fehlkonfigurationen von Kunden zurückzuführen sind – und nicht auf Zero-Day-Bedrohungen.

Fazit: Wenn Sicherheitsteams mit der Verwaltung von über 99 Sicherheitstools beschäftigt sind, verlieren sie die Transparenz bezüglich der Risiken. Mit den Worten von W. Edwards Deming (dem Vater des Total Quality Management): „Beenden Sie die Praxis der Vergabe von Aufträgen auf der Grundlage des Preisschildes. Stattdessen sollten die Gesamtkosten minimiert werden. Wenden Sie sich an einen einzigen Lieferanten für jedes einzelne Produkt, auf der Grundlage einer langfristigen Beziehung der Loyalität und des Vertrauens.“ Weniger Komplexität ist gleichbedeutend mit größerer Risikotransparenz.

Vereinfachte Architekturen

Unternehmen mit hoher Cloud-Nutzung und großen Cloud-Budgets nutzen nicht immer die meisten Plattformen. Diejenigen, die die Cloud am meisten nutzen, konzentrieren sich stark darauf, welche Plattformen sie nutzen. Dies weist perfekte Parallelen zur Fertigung auf. Die kosteneffektivsten Hersteller versuchen fast immer, Teile über Produktlinien hinweg gemeinsam zu nutzen. Was standardisiert ist, kann automatisiert und kostengünstiger gemacht werden. Wir müssen die Cloud und Cloud-Sicherheit auf die gleiche Weise betrachten.

Wenn ein Unternehmen neu in die Cloud einsteigt, gilt es eiligst „so viel Cloud wie möglich“ einzuführen. Die Leute sind aufgeregt und wollen jede Plattform und jeden Formfaktor ausprobieren. Sobald die Unternehmen ihre Cloud-Strategie verfeinern und kostenbewusster, reifer werden, konzentrieren sie sich auf weniger Cloud-Plattformen. Diese Beschränkung bedeutet nicht, dass sie weniger in der Cloud tun, ganz im Gegenteil. Sie machen tatsächlich mehr – mit weniger Komplexität.

Beleg: Die Mehrheit der intensiven Cloud-Anwender, 61 Prozent, nutzt nur ein bis fünf Cloud-Plattformen.

Fazit: Beim Thema Cloud und Cloud-Sicherheit ist weniger Komplexität das Markenzeichen reifer Cloud-Unternehmen.

Um diese Bedrohungen zu minimieren, sind die folgenden Tipps zu berücksichtigen:

  • Infrastructure-as-Code nutzen,
  • nach naheliegenden Startpunkten suchen, um native Cloud-Sicherheitsplattformen in die Software-Entwicklungspipeline einzufügen sowie
  • auf umfassende native Cloud-Sicherheitsplattformen und nicht auf einzelne Tools konzentrieren, um die Komplexität zu reduzieren.

Zu vermeiden gilt es:

  • zu glauben, mehr Tools bedeuten weniger Risiko,
  • das Verwenden von mehr Cloud-Plattformen, als die Cloud-Reife des Unternehmens es zulässt.
  • der Versuch, Skalierbarkeitsprobleme mit der Anzahl der Mitarbeiter zu lösen. Besser ist es stattdessen Automatisierung zu nutzen. (rhh)

Palo Alto Networks

Lesen Sie auch