Archiv der Kategorie: Virtualisierung

Grundlagen der Sicherheit für Kubernetes Cluster

Originalbeitrag von Magno Logan, Trend Micro Research

Obwohl Kubernetes noch nicht sehr lange verfügbar ist, steht die Plattform bereits auf Platz drei bei den bei Entwicklern beliebtesten Produkten. Umso wichtiger ist das Wissen darum, wie die Sicherheit von Kubernetes, und in diesem Fall von Clustern, gewährleistet werden kann. Ein früherer Beitrag beinhaltete bereits einen Überblick über die Sicherheit für die 4 Cs (Cloud, Cluster, Container and Code) in Cloud-nativen Systemen. Jetzt geht es um die Darstellung der Massnahmen für die Sicherheit des Master-Knoten, API-Servers, etcd und für Netzwerk-Policies.

Betreibt ein Unternehmen seine Cluster als Managed Services wie etwa Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (Amazon EKS) oder Google Kubernetes Engine (GKE), so muss der Cloud-Anbieter die Kontrolle über die Sicherheit übernehmen. Dennoch ist ein besseres Verständnis der verfügbaren Sicherheitsoptionen hilfreich, um sicherzustellen, dass der Cloud-Anbieter die empfohlenen Best Practices befolgt. Betreibt eine Organisation ihre eigenen Control Planes, ist das tiefgreifende Wissen zur Sicherheit noch wichtiger.

Das Control Plane

Das Kubernetes Control Plane fungiert als Hauptknoten im Cluster und verwaltet die Worker Nodes. Damit geht es um das Gehirn, das dieses komplexe System in einem guten Zustand und am Laufen hält.

Bild 1. Skizze eines Kubernetes Clusters und dessen Komponenten (Quelle: Kubernetes.io)

Die Abbildung zeigt, dass die Hauptkomponenten für den Cluster im Control Plane sitzen und dass die gesamte Kommunikation über den kube API-Server (kube-apiserver) läuft, der letztendlich ein REST API ist, das alle Management- und Betriebsfunktionen definiert und kontrolliert. Böswillige Akteure bemühen sich um Zugriff auf den kube-apiserver und das Control Plane. Sobald diese kompromittiert sind, können sie den gesamten Cluster kompromittieren, indem sie die Pods (in denen die Container platziert sind) manipulieren, neue aufsetzen, bereits laufende bearbeiten oder sogar ganz entfernen.

Eine der grundlegenden Massnahmen zur Sicherung des Control Plane ist die Integritätsüberwachung der kritischen Kubernetes-Dateien. Auf diese Weise kommt sofort über jede Änderung der Konfiguration eine Benachrichtigung. Aus Sicht der Kubernetes-Sicherheit sind kritische Dateien diejenigen, die den gesamten Cluster beeinträchtigen können, wenn sie kompromittiert werden. Eine Liste der wichtigsten Dateien und Verzeichnisse, die das Team ständig überwachen muss, zusammen mit den empfohlenen Ownership- und Berechtigungsebenen sind in der neuesten CIS Kubernetes Benchmark v1.5.1 detailliert aufgeführt. Bei den meisten dieser Werte handelt es sich um die Standardwerte der Kubernetes-Installation. Eine Tabelle ist im Originalbeitrag aufgeführt.

Der API Server

Den API-Server der Öffentlichkeit zugänglich zu machen, ist ein kritischer Fehler, den immer noch viele machen, und es ist der häufigste Einstiegspunkt für Angreifer, die darüber den Cluster übernehmen können. Viele Angreifer und Bots suchen im Internet ständig nach offen zugänglichen Kubernetes-API-Servern.

Der einfachste Test, um festzustellen, ob der Server im Internet zugänglich ist, besteht darin, den API-Server von einer externen IP aus zu treffen. Hier hilft eine curl-Anfrage oder https://my-control-plane-ip:6443/api. Gibt es eine Antwort auf die Anfrage, so ist das API öffentlich erreichbar. In einem solchen Fall gibt es mehrere Möglichkeiten einen Fix aufzubringen, je nachdem wie der Zugriff auf das API erfolgt. Die beste und sicherste Option ist die folgende:

Entwickler sollten das Cluster API nur über das interne Netzwerk (oder Unternehmens-VPN) erreichen können. Dies lässt sich leicht erreichen, indem die entsprechenden Regeln für die Firewall oder Sicherheitsgruppen (im Fall von AWS) festgelegt werden. Hier muss allerdings darauf geachtet werden, dass in einer Notfallsituation, in der der Cluster-Administrator keinen sofortigen Zugriff auf den Firmen-Laptop oder ein VPN hat, der Zugriff auf den Cluster durch eine sichere Auflistung der IP des Cluster-Administrators gewährleistet ist, vorzugsweise auf den spezifischen API-Port.

Der Zugang auf den Cluster auf GKE lässt sich auch über die Einstellungen des Master Authorized Networks einschränken. Damit entsteht eine weitere Schutzebene für den Fall, dass jemand die Firewall-Regeln manipulieren kann. Der folgende Befehl tut dies:

gcloud container clusters create –enable-master-authorized-networks –master-authorized-networks=CIDR

Des Weiteren kann der Admin prüfen, ob der kube-apiserver die empfohlenen Sicherheitseinstellungen aufweist:

ps -ef | grep kube-apiserver

Weitere Informationen dazu umfasst der Originalbeitrag.

RBAC-Autorisierung

Mit RBAC lässt sich festlegen, wer worauf in dem Cluster zugreifen kann. Die Aktivierung der Autorisierung für RBAC im Cluster wird dringend empfohlen, insbesondere für die Produktion. Zudem kann allen Benutzern der Zugriff auf den Kube-System-Namensraum untersagt werden, wo sich alle Pods des Control Planes befinden.

Das RBAC-Autorisierungsmodul ist in den neuesten Versionen standardmässig aktiviert. Es müssen lediglich die geeigneten Rollen festgelegt und diese bestimmten Nutzern zugewiesen werden. Doch können böswillige Nutzer RBAC deaktivieren. Dies lässt sich mit demselben Befehl überprüfen, der für den Check der Kube API Serverkonfigurationen genutzt wird:

ps -ef | grep kube-apiserver

Beim Einsatz der RBAC-Autorisierung lassen sich vier Arten von API-Objekten nutzen:

  • Role: enthält Regeln, die einen Berechtigungssatz innerhalb eines Namensraums repräsentieren.
  • RoleBinding: vergibt Berechtigungen einer Role an einen oder mehrere Nutzer.
  • ClusterRole: enthält Regeln, die einen Berechtigungssatz auf Cluster-Ebene repräsentieren.
  • ClusterRoleBinding: vergibt Berechtigungen für Nutzer auf ClusterRole-Ebene.

Bild 2. Bezug der Nutzer zu Roles über RoleBindings beziehungsweise von ClusterRoles zu ClusterRoleBindings

Weitere technische Einzelheiten beinhaltet der Originalbeitrag sowie die offizielle Dokumentation.

etcd

etcd ist der Hauptspeicherort für Daten im Cluster. Alle Clusterobjekte werden hier vorgehalten. Er ist hierarchisch aufgebaut und standardisiert, daher nutzen Kubernetes-Installationen etcd für das Speichern von REST API Objekten sowie für Installationskonfigurationen. Wird etcd exponiert, so könnten kritische Daten verloren gehen. Leider kommen Fehlkonfigurationen häufig vor, wie 2.600 exponierte etcd-Services auf Shodan in diesem Jahr zeigen.

Wie bei jedem Datenspeichersystem sollten die gleichen Sicherheitsprinzipien auf etcd angewandt werden. Sowohl die Verschlüsselung im Transit als auch At-Rest sollte vorhanden sein. Derzeitige Kubernetes Standardinstallationen beinhalten bereits die geeigneten Schlüssel und Zertifikate sowie TLS-Verschlüsselung (siehe CIS Kubernetes Benchmark).

Gelingt es einem Angreifer auf irgendeine Weise, den API-Server zu umgehen und Objekte direkt in etcd zu manipulieren, so wäre es, als hätte er vollen Zugriff auf den gesamten Cluster. Er könnte Pods erstellen, Geheimnisse lesen und sensible Daten wie Anmeldeinformationen einsehen. Um dies zu verhindern, müsste nicht nur die Verschlüsselung während der Übertragung aktiviert sein, sondern auch die Verschlüsselung im Ruhezustand (At-Rest).

Das Netzwerk

Standardmässig können alle Pods in einem Cluster mit jedem anderen Pod auf demselben Cluster kommunizieren, einschliesslich Pods aus verschiedenen Namensräumen, und dies schliesst den Hauptnamensraum des Kube-Systems ein, in dem das Control Plane untergebracht ist. So legt es die Netzwerk-Policy fest, die bei der Kubernetes-Installation konfiguriert wird.

Eine Netzwerk-Policy definiert, wie Gruppen von Pods miteinander und mit anderen Netzwerkendpunkten kommunizieren. NetworkPolicy-API-Ressourcen verwenden Labels, um Pods auszuwählen und Regeln zu definieren, die angeben, welche Art von Datenverkehr für die ausgewählten Pods zulässig ist. Diese Richtlinien können helfen, den Zugriff zwischen Pods oder Namespaces einzuschränken. Der gesamte Zugriff kann über Labels in YAML-Dateien konfiguriert werden, so dass z.B. der Zugriff von Pods auf andere Pods im Namensraum des kube-Systems blockiert werden kann.

Hinweis: Es bedarf einer Netzwerklösung oder eines Container Network Interface (CNI), das das NetworkPolicy-Objekt unterstützt. Andernfalls hat dies keine Auswirkungen auf den Cluster.

Für alle aufgeführten Punkte gibt der Originalbeitrag weitere technische Informationen, und auch eine Kubernetes Security Liste auf GitHub bietet Blogs, Artikel, Tools und Videos zum Thema. In einem weiteren Beitrag werden sich die Autoren mit dem Schutz von Worker Nodes, Kubelet sowie den Pods befassen.

Happy Birthday: 15 Jahre Zero Day Initiative (ZDI)

Originalbeitrag von Brian Gorenc

In diesem Jahr wird die ZDI 15 Jahre alt. Alles begann 2005, als 3Com ein neues Programm namens Zero Day Initiative ankündigte. Geplant war, Forscher, die bisher unbekannte Software-Schwachstellen („Zero-Day-Schwachstellen“) entdecken und sie verantwortungsbewusst offenlegen, finanziell zu belohnen. Die Informationen über die Schwachstelle sollten genutzt werden, um Kunden frühzeitig mithilfe von TippingPoint IPS (Intrusion Prevention System)-Filtern zu schützen, während die ZDI mit dem Hersteller des betroffenen Produkts zusammenarbeitete, um die Schwachstelle zu beheben. In dem Jahr veröffentlichte die ZDI gerade mal ein Advisory zu Symantec VERITAS NetBackup. Fünfzehn Jahre später sind es mehr als 7.500 Advisories, und die ZDI hat sich zum weltweit grössten herstellerunabhängigen Bug-Bounty-Programm entwickelt.

Von einer 15-jährigen Reise zu sprechen, ist eine Untertreibung. Es gab einige Höhen und Tiefen, aber das Programm ist stärker denn je und befindet sich auf Kurs zum bislang erfolgreichsten Jahr des Bestehens. Daher ist es der richtige Zeitpunkt, um einen Blick zurück auf einige der bemerkenswerteren Ereignisse zu werfen.

2005 – 2010

2006 kaufte die ZDI nur zwei Apple-Bugs, 2010 waren es bereits 52. Java-Bugs, insbesondere Sandbox Escapes waren zu der Zeit ebenfalls beliebt. Es fühlt sich etwas merkwürdig an, auf den Wechsel vom Kauf von Bugs in dem, was man einfach „Java“ nannte, solchen in „Sun Microsystems Java“ und schliesslich zu Bugs in „Oracle Java“ zurück zu blicken.

In dieser Zeitspanne fiel auch der erste Pwn2Own-Wettbewerb 2007. Damals galten Apple-Geräte als unüberwindbar. Doch scharfsinnige Sicherheitsforscher wussten es besser, und Dino Dai Zovi bewies dies und gewann ein MacBook sowie 10.000 $. Seither ist der Wettbewerb exponentiell gewachsen. Inzwischen gibt es drei verschiedene Wettbewerbe: Pwn2Own Vancouver, der sich auf Unternehmenssoftware konzentriert; Pwn2Own Tokio, der sich auf Verbrauchergeräte konzentriert und Pwn2Own Miami, der dieses Jahr mit Schwerpunkt auf ICS-SCADA-Produkte eingeführt wurde. Pwn2Own diente auch als „Coming-out“ für viele hochkarätige Forscher, die nach dem Gewinn des Wettbewerbs in verschiedenen prestigeträchtigen Teams und Projekten arbeiten.

2010 – 2015

Dies war eine Übergangszeit für das Programm, da 3Com zusammen mit ZDI von Hewlett-Packard gekauft und später als Teil von Hewlett Packard Enterprise abgespalten wurde. Die Kernprinzipien des Programms damals sind jedoch nach wie vor dieselben wie heute:

  • Fördern der verantwortungsvollen Offenlegung von Zero-Day-Schwachstellen gegenüber den betroffenen Anbietern.
  • Gerechte Anrechnung und Vergütung der teilnehmenden Forscher, einschliesslich jährlicher Boni für Forscher, die innerhalb des Programms besonders produktiv sind.
  • Produktanbieter in die Verantwortung nehmen, indem sie eine angemessene Frist für die Behebung gemeldeter Schwachstellen erhalten.
  • Schutz der Kunden und des Ökosystems.

Mittlerweile war das ZDI gross genug, um einen Einfluss auf das gesamte Ökosystem zu haben. Zu dieser Zeit entwickelte sich die Initiative zum weltgrössten herstellerunabhängigen Bug-Bounty-Programm — sie ist es heute immer noch. 2011 kam es zur ersten öffentlichen Zero-Day-Offenlegung, als ein Anbieter die Patch-Frist nicht einhielt. Im Laufe der Zeit trug die Verpflichtung der Hersteller zur Behebung von Schwachstellen dazu bei, ihre Reaktionszeit von mehr als 180 Tagen auf weniger als 120 zu senken. Obwohl die ZDI die Zeitspanne für die Offenlegung verkürzt hat, ist die Rate der Zero Day-Offenlegung relativ konstant geblieben.

Eine weitere grosse Veränderung war die Zunahme der Forschungsarbeit der vom ZDI-Programm beschäftigten Schwachstellenforscher. Infolge einer Vergrösserung des Teams konnten Mitglieder des ZDI auch ihre eigenen Bugs melden. Sie veröffentlichten zunehmend die Ergebnisse ihrer Arbeit und hielten immer häufiger Vorträge auf hochkarätigen Konferenzen wie Black Hat und DEFCON.

Die Vergrösserung half auch, einige Trends in der bösartigen Ausnutzung zu erkennen. Auch gab es einen Anstieg bei den Reports von Java-Bugs. Nachdem die Browser Click-to-Play implementierten, wurde die praktische Ausnutzung schwieriger. Es gab auch viele Bugs, die Use-After-Free (UAF)-Bedingungen im Internet Explorer missbrauchten, bis Microsoft ohne Aufhebens Isolated Heap und MemGC-Mechanismen einführte. ZDI-Forscher fanden dennoch eine Möglichkeit, diese Mechanismen auszuhebeln und erhielten dafür 125.000 $ von Microsoft. Interessanterweise beschloss Microsoft, nicht alle gemeldeten Bugs zu fixen, sodass ein Teil des Reports als öffentlich gemachter Zero Day endete. Die Forscher spendeten das Geld an verschiedene STEM (Science, Technology, Engineering, Mathematics)-Wohltätigkeitsvereine.

Die Bug-Bounty-Landschaft normalisierte sich und weitete sich aus. Anbieter wie Microsoft und Google starteten ihre eigenen Bounty-Programme. Es entstanden Bug-Bounty-Plattformen, die es Firmen wie Starbucks und Uber ermöglichten, selbst Belohnungen anzubieten. Die Idee der Crowdsourcing-Forschung wurde zum Mainstream. Nicht jedes Programm war erfolgreich, da einige Anbieter plötzlich erkannten, dass das Angebot von Geld für Bug-Reports dazu führt, dass man Bug-Reports erhält. Dadurch hatten einige Unternehmen Mühe, nach dem Start ihres Programms  zu reagieren. Es war definitiv eine Zeit des Wachstums und des Lernens in der gesamten Branche.

2010 erlebte Pwn2Own den ersten erfolgreichen Mobilgerät-Angriff, durchgeführt von Ralf-Philipp Weinmann und Vincenzo Iozzo gegen Apple iPhone 3GS. Anbieter begannen umfangreiche Patches kurz vor dem Wettbewerb zu veröffentlichen. Da die Regeln für alle Angriffe die „neueste Version“ vorschreiben, wurden die Teilnehmer oft kurz vor dem Wettbewerb „aus-gepatcht“. Das bedeutete auch, dass die ZDI sich beeilen musste, um die Ziele mit den neuesten Patches auf den neuesten Stand zu bringen. I2012 kam ein zweiter Wettbewerb – Mobile Pwn2Own – hinzu, der sich auf Telefone und Tablets konzentrierte

2015 – bis heute

2015 kaufte Trend Micro das HP TippingPoint IPS zusammen mit dem ZDI-Programm. Dies eröffnete der ZDI neue Möglichkeiten, da die durch das ZDI-Programm gewonnenen Erkenntnisse über Schwachstellen nun nicht nur der Verbesserung des TippingPoint IPS zugute kamen, sondern auch für andere Produkte innerhalb der Sicherheitslösungen von Trend Micro genutzt werden konnten. Die Zusammenarbeit des ZDI mit Trend Micro führte auch zu einem massiven Anstieg des Interesses an Schwachstellen in den Trend Micro-Produkten selbst. Die Trend Micro-Produktteams scheuten nicht davor zurück, die von unabhängigen ZDI-Forschern eingereichten Fehler zu beheben, und ein gezieltes Targeted Initiative Program nur für ausgewählte Trend Micro-Produkte entstand.

Vor 2015 gab es nur selten eine Adobe Reader-Bug-Meldung ausserhalb von Pwn2Own. In dem Jahr aber waren es mehr als 100. Viele dieser Berichte stammten von ZDI-Forschern. Insgesamt machen interne Funde etwa 20% aller Fälle pro Jahr aus. Auch Deserialisierungs-Bugs und ICS/SCADA-Schwachstellen nahmen stark zu. Home-Router entwickelten sich zu einem beliebten Ziel, da sie massenhaft kompromittiert werden können, um in Botnets und DDoS-Angriffen verwendet zu werden. Infolgedessen passte sich die ZDI an und begann, hardwarebezogene Reports zu akzeptieren, insbesondere solche, die sich auf IoT-Geräte beziehen.

Die Einführung des Wassenaar-Arrangements brachte einige Herausforderungen mit sich – insbesondere beim Kauf von Bug Reports aus den Mitgliedsländern.

2016 wurde beim Pwn2Own die Kategorie Virtualisierung eingeführt. Zum 10. Geburtstag des Wettbewerbs 2017 konnte die ZDI während der drei Tage 51 Zero-Days erwerben. 2019 ging die ZDI eine Partnerschaft mit Tesla ein, sodass Forscher das Infotainment-System des Autos zum Ziel machen könnten. ZDI-Forscher zeigten auch ihren eigenen Einbruch ins Infotainment-System. Auch die Teilnehmer haben sich im Laufe der Jahre verändert. Anfangs nahmen hauptsächlich einzelne Forscher und nur wenige Teams teil. Später waren es in der Mehrheit Teams, die von ihren Arbeitgebern gesponsert wurden.  In den letzten paar Jahren ist dieser Trend wieder rückläufig.

2018 erreichte die ZDI ihren Höchststand von 1.450 veröffentlichten Advisories, und dieses Jahr werden noch mehr. Tatsächlich ist die ZDI seit 13 Jahren als weltweit führende Organisation für Schwachstellenforschung anerkannt. Laut Omdia war das ZDI 2019 für mehr als die Hälfte aller gemessenen Offenlegungen von Schwachstellen verantwortlich, das ist mehr als jeder andere Anbieter.

CLOUDSEC Online: Neue Quelle für fachkundige Inhalte zur Cloud-Sicherheit

Originalartikel von Bharat Mistry

Für Informations-Sicherheitsfachleute bedeutet der radikale Wechsel der letzten Monate in den Unternehmen hin zur Arbeit im Homeoffice eine sehr einschneidende Änderung. Auch traf sie die Absage von Branchentreffen und Veranstaltungen, die dringend benötigte Netzwerk- und Weiterbildungsmöglichkeiten bieten, besonders hart. Deshalb will die CLOUDSEC Online einen Ersatz bieten, ein neues interaktives Zentrum, das von Trend Micro und Partnern betrieben wird, und eine sehr wertvolle Ressource für Cybersicherheits- und IT-Fachleute sein kann.

Eine vor kurzem von der Zertifizierungsorganisation (ISC)² durchgeführte Branchenumfrage ergab, dass fast die Hälfte (47%) der Sicherheitsfachleute irgendwann von einigen oder allen ihren üblichen Aufgaben freigestellt wurden, um dringendere Anforderungen wie z.B. Remote-Arbeit zu unterstützen. Weitere 15% der Unternehmen scheinen nicht über adäquate Ressourcen zu verfügen, während ein Drittel (34%) vorerst nur mit „ausreichenden“ Mitteln ausgestattet ist. In einer anderen kürzlich durchgeführten Umfrage, diesmal von der Branchenorganisation ISACA, gab nur etwa die Hälfte (59%) an, dass ihr IT-Sicherheitsteam zu Hause über die richtigen Werkzeuge und Ressourcen verfügt, um die Arbeit effektiv zu erledigen.

Warum die CLOUDSEC Online?

Die CLOUDSEC-Konferenz von Trend Micro bietet Branchenfachleuten seit fünf Jahren Zugang zu spannenden Präsentationen von weltweit führenden Experten aus dem gesamten Spektrum der Cybersicherheit. Kurze, aufschlussreiche Keynotes aus dem akademischen Bereich, von Strafverfolgungsbehörden, Non-Profit-Organisationen, CISOs von Unternehmen und Trend Micros eigenen Experten bieten Einblicke in aktuelle Trends bei Bedrohungen und reale Fallstudien von Branchenexperten – das alles an einem einzigen Tag.

Die virtuelle CLOUDSEC soll es Branchenexperten aus ganz Europa ermöglichen, miteinander in Verbindung zu treten und eine Reihe von Ressourcen zur Verfügung zu haben, die eine Cloud-Sicherheitsstrategie in einer Zeit extremer Herausforderungen unterstützen.

Des Weiteren gibt es dort E-Books, Whitepapers, Infografiken, Webinare, Video-Interviews, Lösungsleitfäden, Erfolgsgeschichten von Partnern und vieles mehr. Sie bieten eine breite Palette von Informationen, die von einem besseren Verständnis dateiloser Bedrohungen über Herausforderungen in der hybriden Cloud und nahtlose DevOps-Sicherheit bis hin zur Bekämpfung von Fehlkonfigurationen in der Cloud reichen.

Anmeldungen sind hier möglich.

Serverlose Architekturen und deren Sicherheit

Originalbeitrag von Trend Micro

Der Wechsel zum Serverless Computing nimmt Fahrt auf. Laut einer Umfrage aus dem Jahr 2019 haben 21% der Unternehmen bereits die serverlose Technologie eingeführt, während 39% dies in Erwägung ziehen. Die serverlose Technologie ist für viele Unternehmen attraktiv, da sie es ihnen ermöglicht, sich auf die Erstellung von besserem Code für ihre Anwendungen zu konzentrieren, anstatt die für die Ausführung der Anwendungen erforderliche Infrastruktur zu verwalten und zu sichern. Das Forschungs-Whitepaper von Trend Micro „Securing Weak Points in Serverless Architectures: Risks and Recommendations“ stellt Sicherheitsüberlegungen für serverlose Umgebungen an und unterstützt Anwender dabei, ihre serverlosen Umgebungen so sicher wie möglich zu gestalten. Der Schwerpunkt liegt auf den von der AWS angebotenen Diensten, die über die breiteste Angebotspalette auf diesem Markt verfügt.

Serverless Computing bezeichnet eine Technologie, die Backend-Dienste unterstützt, sodass Unternehmen bestimmte Verantwortlichkeiten auf Cloud Service Provider (CSPs) wie Amazon Web Services (AWS) übertragen können, unter anderem Kapazitätsmanagement, Patching und Verfügbarkeit. Mit serverlosem Computing lassen sich Backend-Anwendungen erstellen, ohne direkt an Verfügbarkeit und Skalierbarkeit beteiligt zu sein. Der Begriff „serverlos“ bedeutet jedoch nicht, dass dieses Computing-Modell überhaupt keine Server einsetzt, sondern dass Unternehmen nicht mehr direkt an der Wartung und Absicherung von Servern beteiligt sein müssen.

Die Sicherheit der infrastrukturellen Rechenkomponenten dieser Architekturen wird zum größten Teil durch die CSPs (Cloud Service Provider) gewährleistet. Aus diesem Grund gilt die serverlose Technologie als relativ sicherer als andere Cloud-Computing-Modelle. Aber wie jede andere bestehende Technologie ist sie nicht immun gegen Risiken und Bedrohungen.

Vernetzte Services in einer serverlosen Architektur

Um zu verstehen, wie eine serverlose Architektur funktioniert, muss man wissen, welche verschiedenen Services daran beteiligt sind. In diesem Beitrag geht es um eine AWS serverlose Architektur.

Bild 1. Beispiele von miteinander verbundenen Services in einer AWS serverlosen Architektur

Amazon S3

Amazon Simple Storage Service (Amazon S3) ist ein Objektspeicher-Service für skalierbare Datenmengen, die eine Vielzahl von Anwendungsfällen unterstützt, wie z.B. mobile Anwendungen, Big Data Analytics und IoT-Geräte. Amazon S3 ermöglicht es Objekte zu verwalten, die dann über APIs in Buckets gespeichert werden.

AWS Lambda

Einer der am weitesten verbreiteten serverlosen Dienste ist AWS Lambda. Er ermöglicht es Unternehmen, Code ohne die mühsame Bereitstellung und Wartung von Servern auszuführen. Entwickler bezahlen dabei nur für die Anzahl der Instanzen, wenn der Code getriggert wird. Mit AWS Lambda müssen sie nicht Hardware verwalten oder sicherstellen, dass das Betriebssystem und alle installierten Anwendungen auf dem neuesten Stand sind.

Amazon API Gateway

Amazon API Gateway erlaubt die einfache und effiziente Erstellung, Veröffentlichung, Wartung, Überwachung und Sicherung von APIs. Der Dienst fungiert als Portal für Anwendungen, die über RESTful-APIs und WebSocket-APIs auf Backend-Service-Funktionen oder Daten zugreifen können.

AWS IAM

Über AWS Identity and Access Management (AWS IAM) können Entwickler Sicherheitsinfos und Berechtigungen managen, um den Zugang zu serverlosen Services und Ressourcen zu bestätigen.

Fehlkonfigurationen und unsichere Coding-Praktiken

Größere CSPs wie AWS wenden bei der Vergabe von Berechtigungen für bestimmte Aufgaben die Least Privilege Policy an. Sie nutzen auch den Ansatz der standardmässigen Verweigerung, der sicherstellt, dass jeder Dienst nur dann kommunizieren kann oder für einen anderen Dienst zugänglich ist, wenn die erforderlichen Berechtigungen erteilt werden. Die manuelle Zuweisung und Überprüfung von Privilegien sorgt für mehr Sicherheit. Dies kann sich jedoch für  Benutzer als schwierig erweisen, insbesondere angesichts einer komplexen Mischung miteinander verbundener Dienste. Infolgedessen könnten sie bei der Sicherheit serverloser Dienste Fehlkonfigurationen und Risiken wie die folgenden einführen oder übersehen.

Amazon S3

Offen gelassene oder frei zugängliche Amazon S3 Buckets könnten eine Tür für böswillige Akteure sein, um nach sensiblen Daten zu suchen. Kritische Daten oder Codeteile, die nicht öffentlich sichtbar sein sollten, könnten ebenfalls freigelegt werden, wenn Amazon S3-Buckets dazu verwendet werden, Inhalte zu hosten, für die sie nicht vorgesehen sind.

AWS Lambda

AWS-Lambda-Funktionen könnten von böswilligen Akteuren durch Injection-Techniken bei fehlerhaftem oder anfälligem Code ausgenutzt werden. Auch könnten sensible Daten exponiert werden, wenn der Code einer AWS-Lambda-Funktion so gestaltet ist, dass er Variablen zurückgibt und für externe Dienste zugänglich ist. Böswillige Akteure könnten auch die in AWS-Lambda-Funktionen als Variablen gespeicherten Zugangsdaten ausnutzen, um Zugang zum Konto eines Benutzers zu erhalten. Darüber hinaus liesse sich schadhafter Code dazu nutzen,bösartige Tools und Skripts im Ordner /tmp einer AWS Lambda-Ausführungsumgebung zu speichern. Dateien könnten hier persistent genug sein, um Angriffe zu starten oder sensible Daten zu exfiltrieren.

Amazon API Gateway

Sobald ein Amazon API-Gateway-Endpunkt offen und ungeschützt ist, liesse sich darüber einDenial-of-Service (DoS)-Angriff auslösen, um den dahinter liegenden Dienst zu kompromittieren oder abzuschalten. Böswillige Akteure, die einem Unternehmen finanziellen Schaden zufügen wollen, können einen offenen Amazon API Gateway-Endpunkt auch dazu missbrauchen, eine AWS-Lambda-Funktion ununterbrochen abzufragen, um die Rechnung des Unternehmens in die Höhe zu treiben.

AWS IAM

Möglicherweise aus Zeitgründen gestalten Entwickler manchmal die Richtlinien übermässig freizügig, um die Kommunikation zwischen den Systemkomponenten zu gewährleisten. Dies wird durch AWS IAM erleichtert. Aber diese Lockerung der Berechtigungen wirkt sich natürlich auf die Sicherheit der serverlosen Dienste aus, mit denen AWS IAM verwendet wird.

Risiken durch fehlerhaften Code

Um die Risiken der Implementierung von fehlerhaftem Code auf einem serverlosen System noch deutlicher zu machen, haben die Forscher einen Proof-of-Concept erstellt, der eine AWS-Lambda-Funktion mit hohen Berechtigungen beinhaltet. Das folgende Video zeigt, wie schlechte Codierungspraktiken es böswilligen Akteuren ermöglichen, das Timeout der AWS-Lambda-Funktion erfolgreich zu ändern und anschliessend andere Aktivitäten wie die Eskalation von Privilegien und Datenexfiltration durchzuführen.

https://youtube.com/watch?v=vbHdf6WNoO0%3Ffeature%3Doembed

Auswirkungen der Sicherheitsrisiken auf Unternehmen

Serverlose Services beinhalten Stateless-Funktionen, und deshalb bleiben die Daten in diesen Diensten im Cache und werden nicht im Speicher abgelegt. Beim Verschieben von Daten von serverlosen Diensten an externe Standorte müssen Unternehmen darauf achten, wie die Daten verschoben werden, um Datenlecks zu vermeiden. Ein solches Datenleck passierte, als eine Datenbank mit einer halben Million sensibler Rechts- und Finanzdokumente exponiert wurde, weil bei der Änderung der Zugriffsrichtlinien eine Fehlkonfiguration entstand.

Auch ist es wichtig zu wissen, wo Daten gespeichert sind, um Compliance-Problemen aus dem Weg zu gehen, wie denjenigen als z.B. über 36.000 Häftlingsdatensätze aus verschiedenen Justizvollzugsanstalten in den USA bekannt wurden, weil ein mit einer Cloud-basierten Anwendung verbundener Datenspeicher zugänglich war. Die Kompromittierung der Anwendung oder des Dienstes eines Unternehmens könnte auch zu einer Unterbrechung des Geschäftsbetriebs und zu Rufschädigung führen.

Sicherheit für serverlose Services und Installtionen

Das Modell der geteilten Verantwortung, bei dem sowohl der CSP als auch der Anwender Verantwortungsbereiche für die Sicherheit der Cloud-Umgebung übernehmen, gilt auch für das serverlose Computing. Das Forschungsprojekt stellt Möglichkeiten vor, wie serverlose Dienste und Installationen über Best Practices und Sicherheitslösungen vor Risiken und Bedrohungen geschützt werden können.

Weitere Einzelheiten zum Thema liefert das Whitepaper „Securing Weak Points in Serverless Architectures: Risks and Recommendations“.

Das Rennen: Hase und Igel in der IT-Security

Von Richard Werner, Business Consultant bei Trend Micro

Quelle: Wikimedia Commons

Jeder kennt die alte Fabel von den Gebrüdern Grimm. Der Wettlauf zwischen Hase und Igel spielte sich angeblich in Buxtehude ab, in der auch obige schöne Skulptur steht, und die Realität in der IT-Security erinnert stark an diesen ungleichen, ja betrügerischen Wettlauf.

Alle Unternehmen haben bereits in Sicherheitsmassnahmen investiert, ihre Mitarbeiter trainiert und Prozesse optimiert. Dennoch gibt es immer wieder mehr oder weniger ernste Zwischenfälle. Die Lage wird auch dadurch erschwert, dass die IT selbst und mit ihr die Security ständig mit Neuerungen konfrontiert ist, wie z.B. Cloud-Computing und IoT (Internet of Things), oder es werden einfach nur Verfahren optimiert, beispielsweise mit Hilfe von künstlicher Intelligenz. Das bedeutet, alles ist ständig in Bewegung oder mit den Worten des BSI: „Informationssicherheit ist kein Zustand, der einmal erreicht wird und dann fortbesteht, sondern ein Prozess, der kontinuierlich angepasst werden muss.“

Die Gegner in diesem Rennen um IT-Sicherheit sind nicht so sehr andere Firmen sondern vielmehr Leute, sprich Hacker, Cyberkriminelle oder andere Betrüger, die Firmen/Sicherheitsanbieter dazu zwingen, immer schneller zu werden. Diese Personengruppe misst sich nicht im fairen Wettkampf sondern versucht, die Sicherheit der Systeme mit unlauteren Mittel zu verletzen.

Merke: Wir befinden uns in einem Rennen!

Rollenverteilung

Der Tenor der Fabel selbst ist so gesetzt, dass der Leser sich mit dem vermeintlich schwächeren „klugen“ Igel und nicht mit dem „dummen, arroganten“ Hasen identifiziert. Lässt man allerdings die Attribute weg, so ist es eine Erzählung über einen Hasen, der mit Hilfe von übelstem Betrug gehetzt wird und den Wettlauf deshalb nicht gewinnen kann. Diese Beschreibung trifft auch auf die IT Security, also die Verteidigung der IT zu. Alle Anstrengungen führen letztlich dazu, dass wir, die Hasen, bestenfalls nicht verlieren. Gewinnen können wir jedoch nie. Denn das Gegenüber spielt nie fair, und es sind Betrüger im wahrsten Sinne des Wortes.

Merke: Unsere Rolle ist die des Hasen!

Wege aus der Situation

Bei Betrachtung der Situation aus Sicht des Hasen fällt eines auf. Der Hase stellt sich nie die Frage, wie es sein kann, dass ihn der Igel immer wieder besiegt, ohne ihn je zu überholen. Weil der geneigte Leser die Fabel kennt, weiss er auch, was dem Hasen geholfen hätte. Und vielleicht lassen sich diese Ideen auf reale Situation projizieren.

  1. Die erste Option wäre gewesen, ein neues Ziel zu definieren. Der Grund, warum der Igel gewinnen konnte, lag darin, dass der Hase immer zwischen Start und Ziel hin und her lief und damit den Betrug erst ermöglichte. Hätte der Hase nur einmal auf einem anderen Ziel bestanden, wäre der Wettlauf vorbei gewesen. Analog dazu: Auf die Frage, welches die Aufgabe der IT-Security im Unternehmen ist, kommt zumeist die Antwort, „das Unternehmen schützen“. Dies ist das Ziel, dem wir hinterher laufen und bei dem uns der Igel regelmässig sein berühmtes „Ich bin schon da“ entgegenruft. Die Frage ist, ob sich dieses Ziel ändern lässt. Hier ein Vorschlag: Das Ziel wäre, einen erfolgreichen Angriff rechtzeitig zu erkennen. Damit ist er wohlgemerkt nicht verhindert worden. Aber das betroffene Unternehmen hat dann die Möglichkeit, Gegenmassnahmen zu ergreifen, um Schaden abzuwenden. In der IT-Security sind solche Massnahmen unter dem Schlagwort Detection & Response bekannt.
  2. Die zweite Option für den Hasen wäre gewesen, dem Igel einen Vorsprung zu geben. Ihm sozusagen bis zum Ziel hinterher zu laufen, um zu sehen, wie er vorgeht. In diesem Fall hätte der Hase den ganzen Betrug aufdecken und auch die Betrüger entlarven können. Zudem wäre es der Igel gewesen, der plötzlich seine Ressourcen hätte einsetzen müssen. Auch dieses Verfahren kennt die IT-Security. Hier kommen ebenfalls Technologien aus dem Bereich Detection & Response zum Einsatz, mit deren Hilfe ein Angreifer verfolgt werden kann. Die „Gejagten“ versuchen, die Ziele der Angreifer und damit auch Hintergründe zu erforschen, um ggf. auch rechtliche Schritte gegen den/die menschlichen Täter einzuleiten. Das Verfahren birgt allerdings auch jede Menge Risiken und sollte deswegen nur durch Spezialisten und in Zusammenarbeit mit Strafverfolgungsbehörden durchgeführt werden.

Merke: Nur eine geänderte Vorgehensweise ändert auch die Situation.

Umdenken in der IT-Security

Bezüglich der reinen Schutzfunktionen sind die Grenzen in einigermassen gepflegten IT-Umgebungen längst erreicht. Unabhängig davon, ob ein Unternehmen die Security Tools eines oder mehrerer Hersteller für seine Sicherheit einsetzt, lässt sich lediglich ein Schutzniveau unter 100% erreichen. Dabei funktionieren die allermeisten IT Security-Umgebungen wesentlich besser als ihr Ruf. Der Grund, warum es dennoch immer wieder zu erfolgreichen Angriffen kommt und diese in den letzten Jahren sogar zugenommen haben, liegt vor allem darin, dass auch die Igel – pardon Angreifer — aufgerüstet haben. Attacken wie die der Kategorie Emotet verwenden mehrfache fortschrittliche Methoden um ihre Opfer zu kriegen. Hinzu kommt, dass Angriffsmethoden häufig nicht mehr allein von „gewöhnlichen“ Cyberkriminellen erdacht werden, sondern staatliche Institutionen viel Geld investieren, um solche Konzepte zu entwickeln. So lässt sich auch die heutige Emotet-Welle technisch wie auch methodisch auf das Vorgehen der angeblich staatlichen Malware-Varianten Wannacry und NotPetya zurückführen, deren „Vorfahren“ ihrerseits aus dem Leak technischer Informationen der NSA durch eine ominöse Hackergruppe namens Shadow Broker entstammen.

Die Lehre

Die Wahrscheinlichkeit, trotz guter Gegenmassnahmen infiziert zu werden, ist deshalb hoch. Hier ist es dringend geraten, anders als der Hase in der Fabel, die eigenen Ziele zu überdenken. Niemand bestreitet, dass Schutz wichtig ist. Aber das umfassende Erkennen von erfolgreichen Angriffen sowie die Möglichkeit, koordinierte Gegenmassnahmen mit oder ohne Beobachtung des Gegners zu treffen, werden immer essentieller. Es ist deshalb zunehmend wichtiger, Schutzmassnahmen mit Detection & Response-Methoden zu ergänzen. Je umfangreicher Sensoren ein Netzwerk durchleuchten können, desto genauer erkennen sie Methodik und Verbreitung (Detection), und können dadurch umso effektiver gegen die Bedrohung agieren (Response).

Trend Micro bietet daher seinen Kunden XDR an, das neben Standardvorgehen wie „Endpoint Detection und Response“ (EDR) auch die fortschrittliche Koordination von Verteidigungswerkzeugen auf anderen Ebenen eines Unternehmensnetzwerks wie Email, Server oder Cloud-basierte Workloads anbietet. Zusätzlich stellt Trend Micro auch Spezialisten zur Verfügung, die bei der Beurteilung und Auswertung von Erkenntnissen unterstützen können.

Sicherheit für die digitale Transformation – Suite vs. Punktlösungen

Originalartikel von William Malik, CISA VP Infrastructure Strategies

Die digitale Transformation hat durch die Corona-Pandemie an Schwung gewonnen. Die jeweiligen Projekte sind wichtiger denn je, um mehr Effizienz zu erlangen, Kosten sparen zu können und die Geschäftsagilität zu erhöhen. Sicherheit bleibt aber für viele Organisationen ein großer Stolperstein, weshalb es von entscheidender Bedeutung ist, neue Sichtweisen darüber zu gewinnen, wie der Schutz von Anfang an in Pläne eingearbeitet werden sollte. Wo sind die Sichtbarkeits- und Kontrolllücken beim Schutz hybrider Cloud-Workloads? Hat Kompetenzmangel Fehler in der Cloud-Konfiguration wahrscheinlicher gemacht? Und wie sieht Cloud-Sicherheit aus, wenn Unternehmen in eine neue Normalität eintreten? In von Unsicherheit geprägten Zeiten haben die Experten Antworten gegeben, die CISOs benötigen, um besser informierte strategische Entscheidungen treffen zu können. Trend Micros virtuelle Veranstaltung „Perspectives“ wartete mit hochkarätigen Vorträgen auf, unter anderem von Trend Micro CEO Eva Chen, VP of Security Research, Rik Ferguson, AWS Principal Security Architect, Merritt Baer oder IDC VP, Frank Dickson.

Sehr aufschlussreich waren zudem die Antworten, die von den mehr als 5000 weltweiten Teilnehmern zu zwei Schlüsselfragen zur eigenen Strategie und der digitalen Transformation kamen.

Erstens: Wie sieht Ihre aktuelle Strategie für die Absicherung der Cloud aus?

33% der Befragten verlassen sich komplett auf die nativen Sicherheitsfähigkeiten der Cloud-Plattform (AWS, Azure, Google…), 13% ergänzen die Sicherheit mit auf bestimmte Bereiche (Schutz für Workloads und Container …) ausgerichteten Produkten, und 54% vertrauen auf eine Sicherheitsplattform mit mehrfachen Fähigkeiten, um die Komplexität zu verringern.

Diese Ergebnisse bestätigen die Feststellung von IDC-Analyst Frank Dickson, wonach die meisten Cloud-Kunden mit einer Suite, die eine Reihe von Sicherheitsfunktionen für mehrere Cloud-Umgebungen bietet, besser aufgestellt sind. Für die 15 bis 20 Prozent der Unternehmen, die sich auf nur einen Cloud-Anbieter verlassen, kann der Kauf einer Sicherheitslösung von diesem Hersteller eine ausreichende Abdeckung bieten. Die Suche nach Punktlösungen (die auch Best-of-Breed-Produkte sein können) führt zu zusätzlicher Komplexität über mehrere Cloud-Plattformen hinweg und kann Probleme überdecken, Cybersicherheitsanalysten und Geschäftsanwender irritieren, die Kosten erhöhen und die Effizienz. Die umfassende Suite-Strategie ergänzt den hybriden Multi-Cloud-Ansatz der meisten Organisationen.

Zweitens: Wie setzen Sie sichere digitale Transformation in der Cloud um (Multiple Choice)?

Die Antworten machen deutlich, dass Cloud-Benutzer für viele verfügbare Lösungen zur Verbesserung der Cloud-Sicherheit offen sind. Das Anwendungsmuster folgt den traditionellen Bereitstellungsmodellen für Sicherheit Onpremise. Die am häufigsten angeführte Lösung, Network Security/Cloud-IPS, zeigt, dass Kommunikation mit allem in der Cloud ein vertrauenswürdiges Netzwerk erfordert. Dies ist eine sehr vertraute Praxis, die in Onpremise-Umgebungen bis zur Einführung von Firewalls in den frühen 1990er Jahren von Anbietern wie CheckPoint zurückreicht und durch akademische Forschung unterstützt wird.

Die Häufigkeit der Gefährdung von Daten durch falsch konfigurierte Cloud-Instanzen ist sicherlich ausschlaggebend für das Cloud Security Posture Management. Und dies wird durch die einfache Bereitstellung von Tools wie Cloud One Conformity unterstützt. Die Neuartigkeit von Containern in der Produktionsumgebung erklärt den relativ geringen Einsatz von Container-Sicherheit heute. Doch müssen Unternehmen keine Vielzahl von Einzelprodukten zur Lösung eines Problems in einer Umgebung einsetzen und verwalten. Der Suite-Ansatz vereinfacht die heutige Realität und positioniert die Organisation für die Herausforderungen von morgen.

Die Vorträge können unter Perspectives auch im Nachhinein abgerufen werden.

Ähnliche Artikel:

  1. Einheitliche, automatisierte Sicherheit für die Hybrid Cloud
  2. Sicherheit für die 4 Cs von Cloud-nativen Systemen: Cloud, Cluster, Container und Code, Teil 2
  3. Sicherheit für die Cloud-vernetzte Welt im Jahr 2020
  4. IDC erkennt Trend Micro als Marktführer beim Schutz von SDC-Workloads an
  5. Cloud-Sicherheit: Schlüsselkonzepte, Bedrohungen und Lösungen

Sicherheit für die Cloud-vernetzte Welt im Jahr 2020

Originalbeitrag von Ross Baker

Für CISOs war 2019 ein hartes Jahr. Die letzten zwölf Monate fuhren einen neuen Rekord ein bei Datenschutzverletzungen, Cloud-Fehlkonfigurationen und Sicherheitsbedrohungen auf DevOps-Ebene. Angriffe durch Ransomware, dateilose Malware und auch die Bedrohungen durch Business Email Compromise (BEC) nahmen weiterhin zu. Allein Trend Micro blockte in der ersten Hälfte 2019 mehr als 26,8 Mrd. einzigartige Bedrohungen. Die Situation wird sich in diesem Jahr nicht verbessern, und die Verantwortlichen für Cybersicherheit müssen sicherstellen, dass sie mit vertrauenswürdigen Partnern zusammenarbeiten – Anbietern mit einer klaren Zukunftsvision. Während des letzten Jahres hat eine überzeugende Mischung aus Produktinnovation, Übernahmen und die Anerkennung durch unabhängige Branchengremien Trend Micro als einen solchen Partner qualifiziert.

Risiken durch digitale Medien

Wenn es heute um digitale Transformation geht, so heißt das zumeist Cloud-Computing-Systeme. Die Investitionen in Plattformen wie AWS, Azure und andere haben den Unternehmen enorme Vorteile gebracht, denn sie unterstützen Organisationen dabei, skalierbarer, effizienter und agiler zu werden. Cloud-Plattformen geben Entwicklern die Flexibilität, die sie benötigen, um DevOps und Infrastructure-as-Code (IaC)-Initiativen voranzutreiben, um innovative Kundenerlebnisse zu bieten, und die Plattformen mit wenigen Klicks an die Marktanforderungen anzupassen.

Die Kehrseite davon bedeutet aber, dass diese IT-Transformation die Organisationen einer Reihe neuer Risiken ausgesetzt hat. Bei so vielen potenziell lukrativen Kundeninformationen, die in Cloud-Datenbanken liegen, sind sie zu einem Hauptziel für Hacker geworden. Trend Micro prognostiziert für 2020 eine Flut von Angriffen gegen Cloud-Anbieter über das Einschleusen von Code. Des Weiteren werden Schwachstellen in Container- und Microservices-Architekturen auftauchen, viele davon durch die Wiederverwendung von quelloffenen Komponenten. Fast 9 Prozent der 2018 weltweit heruntergeladenen Komponenten enthielten einen Fehler. Recherchen ergaben, dass 30 Prozent davon kritisch waren.

Die Komplexität von Multi- und hybriden Cloud-Systemen erhöht den Druck auf IT-Admins. Wenn so viel auf dem Spiel steht, ist es unvermeidlich, dass dies zu menschlichen Fehlern führt. Fehlkonfigurationen sind im Jahr 2019 zu einer der Hauptnachrichten geworden. Die Untersuchungen von Trend Micro im vergangenen Jahr ergaben auch, dass über die Hälfte der DevOps Teams in globalen Organisationen nicht über die geeigneten Werkzeuge verfügen, um ihre Arbeit richtig machen zu können.

Sicherheit einfach gestalten

Trend Micro will die Kunden bei ihrem Weg durch diese instabile Landschaft zur Seite stehen. Nur ein paar Beispiele dessen, was der japanische Anbieter zum Schutz der Kunden unternimmt:

Cloud Conformity: Die Übernahme dieses führenden Anbieters von Managementlösungen für Cloud-Sicherheit bietet globalen Anwendern dringend benötigte Fähigkeiten für die permanente Überprüfung. Am auffälligsten ist die Fähigkeit von Cloud Conformity, komplexe Cloud-Umgebungen zu durchleuchten und aufzuzeigen, wo Fehlkonfigurationen existieren und einfache Schritte zur Abhilfe zu ergreifen.

SnykTrend Micro arbeitet mit diesem entwicklerorientierten Open-Source-Sicherheitsanbieter zusammen mit dem Ziel, die Risiken von DevOps zu verringern, die sich aus gemeinsam genutztem Code ergeben. Trend Micro Container-Image-Scans zeigen Schwachstellen und Malware in der Software-Build-Pipeline auf, und virtuelles Patching schützt gegen deren Ausnutzung zur Laufzeit. Mit Snyk Applications Security Management können Entwickler diese Fehler in ihrem Code schnell und einfach beheben.

CloudOne: Trend Micro kombiniert alle Cloud-Sicherheitsfähigkeiten in einer schlanken Plattform, und deckt damit CSPM, Anwendungssicherheit, Container-, Workload-, Cloud-Netzwerk- und Dateispeicher-Sicherheit ab. Die Plattform stellt eine automatisierte, flexible, einheitliche Lösung dar, die die Komplexität von modernen hybriden und Multi-Cloud-Umgebungen vereinfacht.

Anerkennung durch Analysten: Kürzlich hat etwa IDC Trend Micro im neuesten „Worldwide Software Defined Compute Workload Security Market Shares, 2018“ als „dominanten Leader“ aufgeführt. Trend Micro hält mehr als zwei Fünftel der Marktanteile im SDC Workload-Sicherheitsmarkt, nahezu dreimal so viele wie der nächste Mitbewerber.

IDC erkennt Trend Micro als Marktführer beim Schutz von SDC-Workloads an

Von Richard Werner, Business Consultant bei Trend Micro

Moderne Unternehmen setzen auf die Hybrid Cloud und DevOps, um schneller auf sich ändernde Marktanforderungen reagieren zu können. Aber dieses durch Innovation voran getriebene digitale Wachstum können sie nur mit einem starken und sicheren Fundament erreichen. Trend Micro hat als einer der ersten Anbieter bereits vor einem Jahrzehnt diesen Trend und die damit einhergehenden Sicherheitsherausforderungen erkannt, und ist heute als Marktführer anerkannt. IDC führt Trend Micro im aktuellen Bericht „Worldwide Software Defined Compute Workload Security Market Shares, 2018“ als „dominant Leader“ beim Schutz von Software-Defined Compute (SDC)-Workloads und die Nummer 1 nach Marktanteilen.

Der IDC-Bericht stellt fest, dass SDC eine Vielzahl von Abstraktionstechnologien über den Software-Stack hinweg umfasst. Vom technischen Standpunkt ist SDC Workload-Sicherheit ein Unterbereich der Endpunktesicherheit. Doch sie ist in erster Linie auf den Schutz von virtuellen Maschinen (VMs), Containern und Cloud-Systemsoftware ausgerichtet und wird daher häufig im Kontext von Cloud-Umgebungen eingesetzt. Zu den Tools dieser Kategorie gehören unter anderen Anti-Malware, Firewall, Host-Intrusion Detection, Application Control und Integritätsüberwachung.

Die Cloud aber, und damit VMs und Container, werden zunehmend für die Entwicklung und Unterstützung der Anwendungen auf Microservice-Basis genutzt. Diese Umgebungen rücken somit noch weiter in den Fokus von Hackern. Cloud-Plattformen laufen Gefahr, vor allem über Code Injection angegriffen zu werden, sei es direkt oder über Drittanbieter-Bibliotheken, während Container und serverlose Architekturen aufgrund von angreifbaren Shared Code-Komponenten ausgenutzt werden können. Für Unternehmen, deren Cloud-Systeme und Anwendungen gehackt werden, kann dies eine Verzögerung oder gar den Stillstand auf ihrem digitalen Wachstumspfad bedeuten.

Eine stetige Entwicklung

IDC zufolge liegt der Anteil von Trend Micro am SDC Workload-Sicherheitsmarkt bei mehr als zwei Fünftel. Das ist nahezu dreimal so viel wie der Anteil des nächsten Wettbewerbers. Diese dominante Position ist auch unserem über Jahre hinweg stetigen Aufbau von Schutzmechanismen für diesen Sicherheitsbereich zu verdanken. Bereits 2009 übernahm Trend Micro einen zu der Zeit wenig bekannten Anbieter namens Third Brigade eines Host-basierten Intrusion-Prevention Systems und einer Firewall. Dies war der Beginn einer langen stetigen Weiterentwicklung unserer Fähigkeiten für virtuelle, Hybrid Cloud- und Container-Umgebungen.

Heute bietet Trend Micro umfassende Sicherheit über physische, virtuelle und Hybrid Cloud-Umgebungen hinweg, und dies aus einer einzelnen, übersichtlichen Schnittstelle heraus und mit enger Integration in AWS, Azure und GCP. Trend Micro richtet das Augenmerk auch auf Automatisierung und Security-as-Code, um nahtlosen Schutz in DevOps-Pipelines zu gewährleisten, einschließlich des Scannens von Container-Images vor der Ausführung.

Vor kurzem veröffentlichte Trend Micro XDR mit der Möglichkeit, Daten über E-Mail-, Netzwerk-, Endpunkt-, Server- und Cloud-Workloads hinweg zu korrelieren, um bösartige Workload-Aktivitäten zu erkennen und zu blockieren. Darüber hinaus übernahmen wir den führenden Anbieter von Cloud Security Posture Management Cloud Conformity, dessen Technologie das Aufspüren von Fehlkonfigurationen und Compliance/Governance-Problemen unterstützt.

All diese und weitere Funktionen werden in Kürze als Teil einer ganzheitlichen Cloud One-Lösung angeboten, die es Unternehmen ermöglicht, automatisierten Schutz über eine einzige Konsole zu erhalten – und damit Risiken, Verwaltungskosten und Abrechnungsprobleme zu minimieren. Wir bei Trend Micro blicken immer einen Schritt voraus, um Schutz dort zu bieten, wo er gebraucht wird.