Archiv der Kategorie: Cloud Security

Botnet Malware-Varianten zielen auf exponierte Docker Server

Originalbeitrag von Augusto Remillano II, Patrick Noel Collado und Karen Ivy Titiwa

Kürzlich entdeckten die Sicherheitsforscher Varianten von zwei existierenden Linux Botnet Malware-Arten, die exponierte Docker-Server im Visier hatten: XORDDoS (Backdoor.Linux.XORDDOS.AE) und Kaiji DDoS (DDoS.Linux.KAIJI.A). Für beide Malware-Arten sind Docker-Server als Ziel neu. XORDDoS war dafür bekannt, Linux Hosts in Cloud-Systemen anzugreifen, und die erst vor kurzem entdeckte Kaiji-Malware griff IoT-Geräte an. Die Hintermänner nutzten normalerweise Botnets für Brute-Force-Attacken, nachdem sie nach offenen Secure Shell (SSH)- und Telnet-Ports gescannt hatten. Jetzt suchen sie auch nach Docker-Servern mit exponierten Ports (2375). Dies ist einer der beiden Ports, die das Docker API nutzt, und dient der nicht verschlüsselten und nicht authentifizierten Kommunikation.

Es besteht jedoch ein bemerkenswerter Unterschied zwischen den Angriffsmethoden der beiden Malware-Varianten. Während der XORDDoS-Angriff den Docker-Server infiltrierte, um alle auf ihm gehosteten Container zu infizieren, setzt der Kaiji-Angriff einen eigenen Container ein, in dem die DDoS-Malware liegt.

Diese Malware-Varianten begünstigen Distributed Denial of Service (DDoS), einen Angriffstyp, der darauf abzielt, ein Netzwerk, eine Website oder einen Dienst zu deaktivieren, zu unterbrechen oder herunterzufahren. Dazu werden mehrere Systeme verwendet, um das Zielsystem mit Datenverkehr zu überlasten, bis es für andere Benutzer unzugänglich wird.

Analyse der beiden Varianten

Die XORDDoS-Infektion begann damit, dass die Angreifer nach Hosts mit exponierten Docker-API-Port suchten (2375). Dann sandten sie einen Befehl, der die auf dem Docker-Server gehosteten Container auflistete. Danach führten die Angreifer eine Befehlsfolge für alle Container aus und infizierten sie alle mit der Malware.

Ähnlich wie bei der XORDDoS-Malware zielt Kaiji auch auf exponierte Docker-Server zur Verbreitung. Der Betreiber scannte auch das Internet nach Hosts mit dem exponierten Port 2375. Nachdem er ein Ziel gefunden hatte, pingt er den Docker-Server an, bevor er einen bösartigen ARM-Container einsetzt, der das Kaiji-Binary ausführt. Die technischen Einzelheiten zu den beiden Angriffen finden Interessierte im Originalbeitrag.

Schutz für Docker-Server

Es zeigt sich, dass die Bedrohungsakteure ihre Werke ständig um neue Fähigkeiten erweitern, so dass sie ihre Angriffe auf andere Eintrittspunkte ausrichten können. Da sie relativ bequem in der Cloud eingesetzt werden können, sind Docker-Server eine immer beliebtere Option für Unternehmen. Sie sind jedoch auch ein attraktiven Ziel für Cyberkriminelle, die ständig auf der Suche nach Systemen sind, die sie ausnutzen können.

Einige Empfehlungen für die Absicherung von Docker-Servern:

  • Absichern des Container Hosts: Dafür eignen sich Monitoring Tools und Host Container in einem auf Container zugeschnittenen Betriebssystem.
  • Absichern der Netzwerkumgebung. Dafür sollte ein Intrusion Prevention System (IPS) und Webfiltering zum Einsatz kommen, um Übersicht zu bieten und den internen sowie externen Verkehr beobachten zu können.
  • Absichern des Management-Stacks. Hier sollte die Container Registry überwacht und gesichert werden sowie die Kubernetes-Installation abgesperrt sein.
  • Absichern der Build Pipeline. Implementieren eines gründlichen und konsistenten Zugangskontrollschemas sowie starker Endpunktkontrollmechanismen.
  • Befolgen der empfohlenen Best Practices.
  • Einsatz von Sicherheits-Tools, um Container zu scannen und zu schützen.

Trend Micro™ Hybrid Cloud Security bietet automatisierte Sicherheit und Schutz für physische, virtuelle und Cloud Workloads. Die Lösung umfasst folgendes:

Gute Produkte und guter Partner – die Kombination ist entscheidend

Originalbeitrag von Greg Young, Vice President for Cybersecurity

Die Marktforscher von Canalys veröffentlichen jährlich ihre Cybersecurity Leadership Matrix. Während die meisten Analysten nur das Sicherheitsprodukt bewerten, betrachtet Canalys auch dessen Wert für Channel-Partner. In der aktuellen Matrix für 2020 führt Canalys Trend Micro im Champions-Quadranten, und würdigt damit die hohen Investitionen und Verbesserungen, die der Hersteller bezüglich seiner Channel-Partner im Laufe des letzten Jahres geleistet hat.

Die meisten Sicherheitsanbieter verkaufen kaum über eine eigene Sales-Mannschaft, und das hat gute Gründe. Channel-Partner haben normalerweise nicht nur ein einziges Produkt im Angebot, zudem kennen sie eine Region, vertikale oder spezifische Kunden am besten und stellen idealerweise den Defacto-Partner der Endanwender dar und einen vertrauenswürdigen Berater. Zudem verkaufen Channel-Partner an kleinere Kunden mehr als nur Cybersicherheit und können somit eine Erweiterung für das CIO-Team sein.

Channel-Partner suchen die Produkte für ihr Portfolio sorgfältig aus, denn in der Regel vertreiben sie diese über einen viel längeren Zeitraum und mit grösserer Verantwortung. Partner müssen ihre Mitarbeiter schulen, tätigen bedeutende Investitionen, arbeiten sich in das Produkt ein und stehen dafür mit ihrem guten Ruf gerade. Daher ist die Bewertung von Funktionen nicht ausreichend. Auch das beste Produkt, das nicht einen Channel-freundlichen Hersteller im Rücken hat, ist ein Albtraum für den Vertriebskanal.

Canalys leistet gute Arbeit bei der Beurteilung des Channel-Aspekts eines erfolgreichen Cybersicherheitsanbieters, vor allem weil sie die Qualitäten eines Produkts mit dem Wert für den Channel kombinieren.

Die neueste Canalys-Matrix sieht Trend Micro im Jahr 2020 von einer „Grower“- zu einer „Champion“-Position aufsteigen, wobei die besten Bewertungen in den Bereichen Produktverfügbarkeit und -lieferung (79,3 Prozent) und einfache Geschäftsabwicklung (75,4 Prozent) liegen. Auch die Nützlichkeit der von Trend Micro bereitgestellten Portale und Tools (72,6 Prozent) wurde von den Partnern hoch eingestuft.

Canalys lobt in seinem Bericht die Investitionen Trend Micros in sein Channel-Programm im letzten Jahr und hebt dabei insbesondere die erfolgten Verbesserungen des Partner-Portals hervor. Dazu zählen erweiterte Deal Registration, Sales Kits, Promotions und Schulungen. Zudem würdigen die Analysten besonders die Erweiterung des Managed Service Provider (MSP)-Programms um eine zentrale Lizenzverwaltungsplattform sowie das Angebot von SOCaaS (Security Operatios Center as a Service) zur Automatisierung von kunden- und produktübergreifenden Bedrohungsanalysen. Die engere Verzahnung mit dem CPPO-Programm (Consulting Partner Private Offer) von AWS wird ebenfalls als wichtiger Schritt hervorgehoben.

In den kommenden Monaten will Trend Micro weltweit Hunderte neuer MSPs (Managed Service Provider) gewinnen und das MSP-Geschäft bestehender Partner ausbauen. Dazu bietet der Hersteller Support-Services und eine höhere Rentabilität. Zudem sollen durch Lösungskampagnen, Promotions, Incentives und seine Self-Service-Plattform zur Nachfrageerzeugung mehr Leads mit Partnern generiert werden.

Sicherheit für die 4 Cs von Cloud-nativen Systemen: Cloud, Cluster, Container und Code, Teil 2

Originalbeitrag von Magno Logan, Threat Researcher

Cloud-native Softwareentwicklung baut auf quelloffene und proprietäre Software, um Anwendungen wie Microservices bereitzustellen, die in einzelnen Containern in isoliert ausführbare Prozesse verpackt sind. Da Unternehmen mehrere Container auf mehreren Hosts laufen lassen, setzen sie Orchestrierungssysteme wie etwa Kurbernetes ein, die über CI/CD-Tools mit DevOps-Methodologien bereitgestellt und verwaltet werden. Wie bei jeder Technologie, die unterschiedliche, miteinander verbundene Tools und Plattformen nutzt, spielt auch beim Cloud-nativen Computing Sicherheit eine entscheidende Rolle. Cloud-native Sicherheit unterteilt die Strategie in vier unterschiedliche Schichten. Nach der Darstellung der Sicherheitsproblematik für die Cloud an sich und für die Cluster (Teil 1) stellt dieser 2. Teil die Sicherheit für Container und Code in den Vordergrund.

Kubernetes nennt dies „The 4Cs of Cloud-native Security“.

Bild 1. Die 4 Cs der Cloud-nativen Sicherheit

Wichtig ist, Sicherheitskontrollen in jeder Schicht anzuwenden, denn jeder Layer liefert eine eigene Angriffsoberfläche und wird nicht zwangsläufig durch andere Layer geschützt. So wird etwa eine unsichere Webanwendung bei einem Angriff über SQL Injection nicht durch äussere Schichten (siehe Bild 1) dagegen geschützt, wenn keine spezielle Sicherheitssoftware vorhanden ist. Sicherheitsverantwortliche müssen jedes mögliche Szenario mit einbeziehen und Systeme auf jede Art schützen. Weitere detaillierte Empfehlungen für die sichere Container-Orchestrierung bietet der Blogeintrag zur Sicherheit von Kubernetes Container-Orchestrierung.

Container-Sicherheit

Für den Betrieb von Containern im Cluster bedarf es der Container Runtime Engines (CREs). Eine der bekanntesten ist Docker, doch Kubernetes unterstützt auch andere wie containerd oder CRI-O. In puncto Sicherheit müssen Unternehmen für diese Schicht drei wichtige Fragen klären:

  • Wie sicher sind die Images? Hier müssen Verantwortliche sicherstellen, dass die Container auf aktuellem Stand und frei von Schwachstellen, die missbraucht werden könnten, sind. Nicht nur das Basis-Image muss abgesichert sein, sondern auch die in den Containern laufenden Anwendungen müssen gescannt und verifiziert sein. Dafür gibt es einige quelloffene Tools, doch nicht alle können Schwachstellen ausserhalb der Betriebssystempakete erkennen. Dafür sollten Anwender auf Lösungen setzen, die auch Anwendungen abdecken, so etwa Deep Security™ Smart Check.
  • Sind die Container vertrauenswürdig? Wurden die Container, die im System laufen, aus den Images in der eigenen Registry erstellt? Wie lässt sich dies gewährleisten? Antworten bieten Image-Signiertools wie TUF oder Notary, mit denen die Images signiert werden können und somit ein vertrauenswürdiges System für die Inhalte der Container erstellt werden kann.
  • Laufen sie mit den geeigneten Privilegien? Hier greift das Prinzip der geringsten Privilegien. Es sollten lediglich Container laufen, wo die Nutzer nur die für ihre Aufgaben erforderlichen Betriebssystemprivilegien haben.

Ein umfassender Leitfaden zu einem höheren Schutz für Container zeigt auch die möglichen Gefahren in jeder Phase der Entwicklungs-Pipeline.

Code-Sicherheit

Hierbei geht es um Anwendungssicherheit. Es ist die Schicht, über die Unternehmen die beste Kontrolle haben. Der Code der Anwendungen stellt zusammen mit den zugehörigen Datenbanken das Kernstück der Systeme dar. Sie sind üblicherweise im Internet zugänglich und werden daher von Angreifern ins Visier genommen, wenn alle anderen Komponenten gut gesichert sind.

Deshalb müssen Unternehmen in erster Linie sicherstellen, dass jegliche Kommunikation TLS-verschlüsselt abläuft, auch wenn es sich um interne Services handelt, wie Load Balancer, Anwendungsserver und Datenbanken. Im Fall eines Orchestrierungstools wie Kubernetes lassen sich dafür Services wie Istio oder Linkerd heranziehen.

Die Angriffsfläche der Systeme kann erheblich verkleinert werden, wenn exponierte Dienste, Ports und API-Endpunkte reduziert und überwacht werden. Hier sollten auch Container Basis-Images und Systeme, auf denen die Cluster laufen, bedacht werden.

Es lassen sich verschiedene Code-Sicherheitsüberprüfungen zur Pipeline hinzufügen, um zu gewährleisten, dass der Code gesichert ist. Hier sind einige davon:

  • Statische Sicherheitsanalyse von Anwendungen. Man spricht auch von „Sicherheitsüberprüfung des Codes“ oder von „Code Auditing“. Die Methode gilt als einer der besten und schnellsten Wege, um Sicherheitsprobleme im Code zu entdecken. Unabhängig von der verwendeten Sprache sollte mindestens ein statisches Analysetool in die Pipeline integriert sein, das bei jedem Commit von neuem Code auf unsichere Kodierungspraktiken prüft. Die Open Web Application Security Project (OWASP) Foundation erstellt eine Liste mit quelloffenen und auch kommerziellen Tools für die Analyse von Quellcode und/oder kompiliertem Code.
  • Dynamische Sicherheitsanalyse von Anwendungen. Obwohl eine dynamische Analyse nur dann durchgeführt werden kann, wenn es eine laufende Anwendung gibt, gegen die getestet wird, ist es ratsam, automatisierte Scans und Checks durchzuführen, um bekannte Angriffe wie SQL Injection, Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF) aufzuspüren. Diese Tools testen auch die Widerstandsfähigkeit der Anwendung, Container und Cluster, wenn auf diese eine Reihe unerwarteter Belastungen und fehlerhafter Anfragen zukommt. OWASP hat ein dynamisches Analysetool, OWASP Zed Attack Proxy (ZAP), das Unternehmen automatisiert und in die eigene Pipeline einfügen können.
  • Analyse der Software-Komposition. 70% bis 90% aller Cloud-nativen Anwendungen umfassen Abhängigkeiten von Bibliotheken und Drittanbietern. Es geht um Codeteile, die wahrscheinlich von jemand ausserhalb des Unternehmens verfasst wurden, und die in den unternehmenseigenen Produktionssystemen laufen. Diese Codes werden im Allgemeinen während der statischen Analyse nicht überprüft. Dafür können Tools wie der OWASP Abhängigkeitscheck genutzt werden, um nach veralteten oder angreifbaren Bibliotheken im Code zu suchen. Snyk wiederum bietet kostenlos Drittanbieterüberprüfung für quelloffene Projekte.

Fazit

Die vier Schichten von Cloud-nativen Systemen sind für die Sicherheit von Anwendungen von entscheidender Bedeutung – und wenn auch nur eine von ihnen Angreifern ausgesetzt ist, kann das gesamte System kompromittiert werden.

Cloud-Sicherheitslösungen von Trend Micro

Cloud-spezifische Sicherheitslösungen wie die Trend Micro™ Hybrid Cloud Security können zum Schutz von Cloud-nativen Systemen und ihren verschiedenen Schichten beitragen. Unterstützt wird sie von Trend Micro Cloud One™ , einer Sicherheitsdienste-Plattform für Cloud-Entwickler. Sie bietet automatisierten Schutz für die CI/CD-Pipeline und Anwendungen. Sie trägt auch dazu bei, Sicherheitsprobleme früher zu erkennen und zu lösen und die Lieferzeit für die DevOps-Teams zu verkürzen. Die Plattform umfasst:

Sicherheit für die 4 Cs von Cloud-nativen Systemen: Cloud, Cluster, Container und Code, Teil 1

Originalbeitrag von Magno Logan, Threat Researcher

Cloud-native Softwareentwicklung dient der Erstellung und dem Ablauf von skalierbaren Anwendungen in der Cloud – seien es öffentliche, private oder hybride Umgebungen. Der Ansatz baut auf quelloffene und proprietäre Software, um Anwendungen wie Microservices bereitzustellen, die in einzelnen Containern in isoliert ausführbare Prozesse verpackt sind. Da Unternehmen mehrere Container auf mehreren Hosts laufen lassen, setzen sie Orchestrierungssysteme wie etwa Kurbernetes ein, die über CI/CD-Tools mit DevOps-Methodologien bereitgestellt und verwaltet werden. Mithilfe von Cloud-nativen Technologien können Unternehmen das Meiste aus ihren Cloud-Ressourcen herausholen mit weniger Overhead, aber schnelleren Antwortzeiten und einfacherer Verwaltung. Wie bei jeder Technologie, die unterschiedliche, miteinander verbundene Tools und Plattformen nutzt, spielt auch beim Cloud-nativen Computing Sicherheit eine entscheidende Rolle. Es gibt heutzutage kein komplexes Softwaresystem, das vor Hacking gefeit ist und zu 100% undurchdringlich ist. Deshalb stellt das Konzept einer tiefgreifenden Verteidigung ein Muss für die Sicherheit dar.

Die tiefgreifende Verteidigung oder Defense-in-Depth beruht auf mehreren Sicherheitsschichten mit Barrieren über verschiedene Bereiche im Unternehmen hinweg. Damit soll der Schutz gewährleistet sein, auch wenn eine Kontrollschicht versagt. Cloud-native Sicherheit setzt ebenfalls auf dieses Konzept und unterteilt die Strategie für Cloud-native Systeme in vier unterschiedliche Schichten. Kubernetes nennt dies „The 4Cs of Cloud-native Security“.

Bild 1. Die 4 Cs der Cloud-nativen Sicherheit

Wichtig ist, Sicherheitskontrollen in jeder Schicht anzuwenden, denn jeder Layer liefert eine eigene Angriffsoberfläche und wird nicht zwangsläufig durch andere Layer geschützt. So wird etwa eine unsichere Webanwendung bei einem Angriff über SQL Injection nicht durch äussere Schichten (siehe Bild 1) dagegen geschützt, wenn keine spezielle Sicherheitssoftware vorhanden ist. Sicherheitsverantwortliche müssen jedes mögliche Szenario mit einbeziehen und Systeme auf jede Art schützen.

Cloud-Sicherheit

Der Cloud Layer umfasst die Infrastruktur, auf der Server betrieben werden. Beim Aufsetzen eines Servers bei einem Cloud Service Provider (CSP) sind viele unterschiedliche Dienste beteiligt. Und obwohl die Hauptverantwortung für die Sicherung solcher Dienste (z.B. Betriebssystem, Plattformverwaltung und Netzwerkkonfiguration) bei den CSPs liegt, ist der Kunde nach wie vor für die Überprüfung und Konfiguration dieser Dienste sowie für die Überwachung und Sicherung seiner Daten verantwortlich. Dieses Modell der geteilten Verantwortung ist wichtig, wenn ein Unternehmen Ressourcen und Dienste in die Cloud verlagert.

Folgende sind die häufigsten Probleme, die in den heutigen Cloud-Systemen auftreten:

Unternehmen können diese Art von Problemen vermeiden, wenn sie die Empfehlungen ihrer Cloud Provider befolgen und regelmässige Audits durchführen, um sicherzustellen, dass alle Konfigurationen ihre Richtigkeit haben, bevor sie ins Internet gehen.

Der Einsatz von Infrastructure-as-Code (IaC)-Practices stellt eine effiziente Massnahme dar, die gewährleistet, dass Systeme richtig erstellt und ihre Konfiguration korrekt ist. IaC verwendet Code, um die sachgerechte Bereitstellung von IT-Architekturen zu automatisieren. Damit lässt sich die manuelle Bereitstellung durch DevOps-Ingenieure eliminieren, wodurch Versehen und menschliche Fehler minimiert werden, solange bewährte Verfahren befolgt werden. Tools wie Terraform, Ansible und CloudFormation bieten Unterstützung beim Festlegen der Grundeinstellungen für die Infrastruktur, einschließlich derer für die Sicherheit. Auch helfen sie sicherzustellen, dass die Einstellungen unverändert bleiben, es sei denn, jemand genehmigt und stellt den notwendigen Code zur Verfügung, um sie zu ändern.

Der Einsatz von IaC Practices ist mittlerweile die Norm beim Erstellen und dem Aufbau von Cloud-Umgebungen. Es ist tatsächlich nicht mehr nötig, Server manuell einzurichten und zu konfigurieren – Automatisierung ist der Schlüssel zur Sicherung von Cloud-Architekturen.

Wichtig ist es zudem, den Sicherheitsempfehlungen des Cloud Service Providers zu folgen. Einige der bekanntesten Best Practices von CSP:

Zu den Lösungen, die Ein- und Übersichten in Cloud-Architekturen bieten sowie automatisierte Sicherheits- und Compliance-Checks, gehört Trend Micro™ Cloud One – Conformity.

Cluster-Sicherheit

Beim Thema Cluster Security geht es zumeist um Kubernetes, denn dies ist das derzeit am häufigsten eingesetzte Container Orchestrierungs-Tool. Doch die Sicherheitsprinzipien gelten genauso auch für andere Lösungen.

Es gibt drei Cluster-Hauptelemente, um die sich Unternehmen kümmern müssen:

  • Cluster-Komponenten: Dabei geht es um den Schutz der Komponenten, die das Cluster bilden oder bei Kubernetes den Master Node. An erster Stelle bei der Cluster-Sicherheit stehen Themen wie die Kontrolle des API-Server-Zugriffs und die Beschränkung des direkten Zugriffs auf etcd, den primären Datenspeicher von Kubernetes. Um ungewollten Zugang zu Datenspeichern zu vermeiden, sollten Administratoren den standardmässigen Zugriff verbieten und nur expliziten Verkehr zulassen. Kubernetes liefert ein ausführliches Dokument, das die Art und Weise wie Cluster vor unbeabsichtigtem oder bösartigem Zugriff zu schützen sind, beschreibt. Sofern ein Unternehmen nicht über ein großes Team verfügt und/oder strenge Compliance-Anforderungen zu erfüllen hat, empfiehlt sich die Nutzung von Cluster Managed Services wie Azure Kubernetes Service (AKS), Elastic Kubernetes Service (EKS) oder Google Kubernetes Engine (GKE).
  • Cluster Services. Hier geht es um die sachgemässe Konfiguration und die Zugangskontrolle zu den Services, die im Cluster laufen. Zur Absicherung dieser Dienste empfiehlt Kubernetes das Aufsetzen bestimmter Schutzmassnahmen wie Ressourcenmanagement und das Prinzip der geringsten Privilegien für den Ablauf der Services. Des Weiteren sollten geeignete Authentifizierung und Autorisierung für das Cluster vorhanden sein, Verschlüsselung für den Verkehr mit Transport Layer Security (TLS) sowie der Schutz für kritische Informationen. Weitere technische Details zur Sicherheit der Cluster-Services bietet das Center for Internet (CIS) Kubernetes Benchmark.
  • Cluster Networking. In diesem Bereich ist die richtige Zuweisung von Ports wichtig, um die Kommunikation zwischen Containern, Pods und Diensten zu erleichtern. Es muss sichergestellt sein, dass das Kubernetes-Netzwerkmodell mithilfe einer Container-Netzwerkschnittstelle (CNI), die es den Benutzern ermöglicht, den Pod-Verkehr einzuschränken, sicher implementiert wird.

Weitere detaillierte Empfehlungen für die sichere Container-Orchestrierung bietet der Blogeintrag zur Sicherheit von Kubernetes Container-Orchestrierung.

Im 2. Teil beschreiben wir, wie Container- und Code-Sicherheit – die nächsten 2C – aussehen sollte.

Report zeigt Cloud als eines der Hauptziele von Angriffen

Der gerade erschienene Data Breach Investigations Report“ (DBIR) von Verizon bietet seit nunmehr 12 Jahren interessante Einblicke in die aktuellen Trend in der Bedrohungslandschaft. Für den aktuellen Report wurden 32.000 „Vorfälle“ und fast 4.000 Diebstähle weltweit analysiert. Ganz allgemein fällt auf, dass 70% der Diebstähle im letzten Jahr von Tätern ausserhalb des Unternehmens begangen wurden – dies widerspricht der der weit verbreiteten Meinung, Innentäter seien die Hauptakteure. Weitere 22% wurden durch menschliche Fehler möglich. Zwei Haupttrends lassen sich aus dem Bericht herauslesen.

Zum einen steigt die Zahl der Cloud-Assets, die von Einbrüchen betroffen sind: In etwa einem Viertel (24%) dieser Vorfälle sind Bestandteile von Cloud-Systemen oder Services mit involviert. In den meisten Fällen (73%) wurde ein Email- oder Web-Anwendungsserver ins Visier genommen und bei 77% der Events nutzten die Angreifer vorher gestohlene Login-Informationen. Persönliche Daten sind immer häufiger betroffen, oder zumindest werden diese Diebstähle aufgrund gesetzlicher Bestimmungen öfter gemeldet. Bei 58% der Verstösse waren personenbezogene Daten beteiligt,  fast doppelt so viel wie letztes Jahr.

Diese große Beliebtheit von Phishing-Angriffen erklärt Verizon damit, dass Cyberkriminelle immer den schnellsten und einfachsten Weg für eine Kompromittierung wählen. Dies stimmt mit den Beobachtungen von Trend Micro überein. Der „Cloud App Security Report 2019“ zeigte einen jährlichen 35-prozentigen Anstieg der Credential Phishing-Versuche ab 2018.

86% der Übergriffe waren finanziell motiviert, wenngleich Spionage und fortgeschrittene Bedrohungen am meisten Aufsehen erregten. Der Credential-Diebstahl, Angriffe über Social Engineering (d.h. Phishing und Business Email Compromise) und Fehler verursachten die Mehrzahl der Einbrüche (67% oder mehr). Ransomware machte 27% der Malware-Vorfälle aus, und 18% der Unternehmen blockten mindestens eine Ransomware.

Auch erweitert sich die unternehmensweite Angriffsfläche, weil immer mehr Geschäftsprozesse und Daten in Cloud-Systeme migriert werden. Deshalb wird es für Unternehmen immer wichtiger, vertrauenswürdige Sicherheitspartner zu finden, die sie dabei unterstützen, den nativen Schutz zu verbessern, den Cloud Service Provider anbieten.

Zum anderen stellt der DBIR eine steigende Tendenz zu Cloud-basierten Datendiebstählen aufgrund von Fehlkonfigurationen fest. Der Bericht geht davon aus, dass 22 % der Einbrüche aufgrund von menschlichen Fehlern möglich waren, viele davon eben durch Konfigurationsprobleme. Typischerweise werden Cloud-Datenbanken oder Dateispeichersysteme infolge eines Fehlers eines Auftragnehmers oder Inhouse IT-Admins im Internet exponiert.

Auch dies ist ein Bereich, den Trend Micro bereits als Bedrohung für Unternehmen hervorgehoben hat. Tatsächlich identifiziert Trend Micro Cloud One – Conformity durchschnittlich 230 Millionen Fehlkonfigurationen täglich.

Der langfristige Trend geht in Richtung einer stärkeren Migration in die Cloud, einer höheren Abhängigkeit von Web-Anwendungen für das Arbeiten an Remote-Standorten und zu mehr Komplexität, da Unternehmen in hybride Systeme von mehreren Anbietern investieren. Das bedeutet ein potenziell höheres Cyberrisiko, das CISOs meistern müssen.

Sicherheitsempfehlungen

In erster Linie sind gerade Cloud-Verantwortliche gut beraten, ein tiefes Verständnis dafür zu entwickeln, wie ihre Unternehmen die Cloud nutzen, um die passenden Sicherheitsrichtlinien und -standards zusammen mit durchsetzungsfähigen Rollen und Verantwortlichkeiten festlegen zu können. Des Weiteren sind Schulungen und Awareness-Programme für Mitarbeiter wichtig. Zudem sollten Best Practices befolgt werden, so etwa die Anwendung von Multi-Faktor-Authentifizierung bei Mitarbeiterkonten, Richtlinien für den Zugang mit den geringsten Privilegien und mehr.

Sicherheitslösungen wie Cloud App Security verbessert den Built-in-Schutz in Office 365, G Suite und für Cloud Dateisharing-Dienste, weil die Lösung Malware und Phishing-Versuche blocken kann. Trend Micro Cloud One – Conformity wiederum liefert automatisierte Sicherheits- und Compliance-Prüfungen, um Fehler bei der Konfiguration zu vermeiden und Cloud Security Posture Management nach Best Practices zu ermöglichen.

Cloud-Sicherheit: Schlüsselkonzepte, Bedrohungen und Lösungen

Unternehmen sind gerade dabei, ihre digitale Transformation auf den Weg zu bringen. Dabei setzen sie auf Vielfalt der heutzutage verfügbaren Cloud-basierten Technologien. Für Chief Security Officer (CSO) und Cloud-IT-Teams kann sich die Verwaltung der Cloud-Computing-Sicherheit für eine bestimmte Installation zuweilen schwierig gestalten, und das gerade wegen der Benutzerfreundlichkeit, Flexibilität und Konfigurierbarkeit von Cloud-Diensten. Administratoren müssen ein Verständnis dafür entwickeln, wie ihre Unternehmen die Cloud nutzen, um die passenden Sicherheitsrichtlinien und -standards zusammen mit durchsetzungsfähigen Rollen und Verantwortlichkeiten festlegen zu können.

Herkömmliche netzwerkbasierte Sicherheitstechnologien und -mechanismen lassen sich nicht einfach nahtlos in die Cloud migrieren. Gleichzeitig aber sind die Sicherheitsprobleme, vor denen ein Netzwerkadministrator steht, meist gleich: Wie lässt sich ein unbefugter Zugriff auf das Netzwerk verhindern und Datenverluste vermeiden? Wie kann die Verfügbarkeit sichergestellt werden? Wie lässt sich die Kommunikation verschlüsseln oder Teilnehmer in der Cloud authentifizieren? Und schliesslich wie kann das Sicherheits-Team Bedrohungen leicht erkennen und Schwachstellen in  Anwendungen aufdecken?

Geteilte Verantwortlichkeiten

Eigentlich hat Amazon die Konzepte „Sicherheit der Cloud“ versus „Sicherheit in der Cloud“ eingeführt, um die gemeinsame Verantwortung von Anbietern und Kunden für die Sicherheit und Compliance in der Cloud zu klären. Anbieter sind hauptsächlich für den Schutz der Infrastruktur verantwortlich, in der alle in der Cloud angebotenen Services ausgeführt werden. Des Weiteren bestimmt eine gestaffelte Skala je nach dem gekauften Cloud-Service die direkten Verantwortlichkeiten des Kunden.

Praktisch bestimmen die verschiedenen Cloud Service-Modelle — Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS) – welche Komponenten (von der physischen Infrastruktur, die die Cloud hostet, bis zu den Daten, die in der Cloud erstellt, verarbeitet und gespeichert werden) in der Verantwortung des Betreibers und welche in der des Kunden liegen, und wer demzufolge für die Sicherheit zu sorgen hat.

In einem PaaS-Modell wie Google App Engine, Microsoft Azure PaaS oder Amazon Web Services Lambda, kaufen Entwickler die Ressourcen für das Erzeugen, Testen und Ablaufen von Software. Daher sind sie als Nutzer generell für Anwendungen und Daten verantwortlich, während der Anbieter für den Schutz der Container-Infrastruktur und des Betriebssystems sorgen muss – mit einem unterschiedlichen Mass an Verantwortung, je nach der erworbenen spezifischen Dienstleistung.

Bild 1. „Sicherheit der Cloud“ versus „Sicherheit in der Cloud“

Die Sicherheit der Cloud gehört zum Angebot des Cloud Providers. Dies wird durch vertragliche Vereinbarungen und Verpflichtungen, einschließlich Service-Level-Agreements (SLAs) zwischen dem Verkäufer und dem Kunden, sichergestellt. Leistungskennzahlen wie Betriebszeit oder Latenzzeit sowie Erwartungen hinsichtlich der Lösung eventuell auftretender Probleme, dokumentierter Sicherheitsfunktionen und unter Umständen sogar Strafen für mangelnde Leistung können in der Regel von beiden Parteien durch die Festlegung akzeptabler Standards gemanagt werden.

Die wichtigsten Herausforderungen für die Sicherheit

Unternehmen migrieren möglicherweise einige Bereiche in die Cloud, indem sie diese vollständig in der Cloud (auch bekannt als „cloud-nativ“) starten oder setzen ihre ausgereifte Cloud-basierte Sicherheitsstrategie um. Unabhängig davon, in welcher Phase sich ein Unternehmen auf seinem Weg in die Cloud befindet, sollten Cloud-Administratoren in der Lage sein, Sicherheitsoperationen durchzuführen, wie z.B. das Management von Schwachstellen, die Identifizierung wichtiger Netzwerkvorfälle, Incident Response aufzusetzen sowie Bedrohungsinformationen zu sammeln und entsprechende  Maßnahmen festzulegen – und das alles unter Einhaltung der relevanten Industriestandards.

Verwalten der Komplexität

Cloud-Implementierungen greifen nicht auf dieselbe Sicherheitsinfrastruktur zu wie On-Premises-Netzwerke. Die Heterogenität der Dienste in der Cloud macht es schwierig, kohärente Sicherheitslösungen zu finden. Cloud-Administratoren müssen jederzeit versuchen, eine hybride Umgebung zu sichern. Die Komplexität der Aufgabe ergibt sich aus der Tatsache, dass die Risiken bei Cloud Computing je nach der spezifischen Cloud-Bereitstellungsstrategie variieren. Dies wiederum hängt von den spezifischen Bedürfnissen der Cloud-Benutzer und ihrer Risikobereitschaft bzw. der Höhe des Risikos ab, welches sie zu übernehmen bereit sind. Aus diesem Grund ist Risikobewertung wichtig, und zwar nicht lediglich gemäss der veröffentlichten Best Practices oder der Einhaltung von Vorschriften entsprechend. Compliance-Richtlinien dienen jedoch als Grundlage oder Rahmen, der dazu beitragen kann, die richtigen Fragen zu den Risiken zu stellen.

Übersicht erhalten

Infolge der Möglichkeit, Cloud-Dienste einfach zu abonnieren, geht der Wechsel innerhalb der Unternehmen immer schneller, und Kaufentscheidungen liegen plötzlich nicht mehr im Zuständigkeitsbereich der IT-Abteilung. Dennoch bleibt die IT-Abteilung weiterhin für die Sicherheit von Anwendungen, die mit Hilfe der Cloud entwickelt wurden, verantwortlich. Die Herausforderung besteht darin, wie sichergestellt werden kann, dass die IT-Abteilung jede Interaktion in der Cloud einsehen und sichern kann, und der Wechsel und Entwicklung trotzdem effizient bleiben.

Sicherheitsrisiken und Bedrohungen in der Cloud

Die Trend Micro-Untersuchung der bekanntesten Sicherheitsfallen in Cloud-Implementierungen ergab, dass Fehlkonfigurationen die größte Schwäche für Cloud-Sicherheit darstellen. Das bedeutet, dass Cloud-Anwender beim Aufsetzen ihrer Cloud-Instanzen häufig wichtige Einstellungen übersehen oder diese unsicher ändern.

Bedrohungsakteure nutzen diese Fehlkonfiguration für verschiedene bösartige Aktivitäten aus – von allgemeinen bis zu sehr gezielten Angriffen auf eine bestimmte Organisation als Sprungbrett in ein anderes Netzwerk. Auch über gestohlene Login-Daten, bösartige Container und Schwachstellen in einem der Software Stacks können sich Cyberkriminelle Zutritt zu Cloud-Implementierungen verschaffen. Zu den Cloud-basierten Angriffen auf Unternehmen zählen auch folgende:

  • Cryptojacking: Bedrohungsakteure stehlen Unternehmen Cloud-Computing-Ressourcen, um nicht autorisiertes Kryptowährungs-Mining zu betreiben. Für den aufkommenden Netzwerkverkehr wird das Unternehmen zur Kasse gebeten.
  • E-Skimming: Dabei verschaffen sich Kriminelle Zugang zu den Webanwendungen eines Unternehmens, um bösartigen Code einzuschleusen, der finanzielle Informationen der Site-Besucher sammelt und damit schliesslich dem Ruf des Unternehmens schadet.
  • Nicht autorisierter Zugang: Dies führt zu Datenveränderungen, -diebstahl oder -exfiltrierung. Der Zweck dieser Aktionen kann der Diebstahl von Betriebsgeheimnissen sein oder Zugang zu Kundendatenbanken, um die dort geklauten Informationen im Untergrund zu verkaufen.

Die zu sichernden Bereiche in der Cloud

Bei der Festlegung der Anforderungen an ihre Cloud, sollten Cloud Builder bereits von Anfang an Sicherheit mit berücksichtigen. So lassen sich die Bedrohungen und Risiken vermeiden. Durch die Absicherung jedes der folgenden Bereiche, sofern relevant, können IT-Teams aktuelle und zukünftige Cloud-Implementierungen sicher steuern.

Netzwerk (Traffic Inspection, Virtual Patching)

Ein kritischer Teil des Sicherheitspuzzles, die Netzwerkverkehrs-Inspektion, kann die Verteidigungslinie gegen Zero-Day-Angriffe und Exploits für bekannte Schwachstellen bilden sowie über virtuelles Patching schützen. Eine Firewall in der Cloud unterscheidet sich nur geringfügig von einer herkömmlichen, da die Hauptherausforderung bei der Ausführung darin besteht, die Firewall so zu implementieren, dass Netzwerkverbindungen oder vorhandene Anwendungen nicht unterbrochen werden, unabhängig davon, ob es sich um eine virtuelle private Cloud oder ein Cloud-Netzwerk handelt.

Bild 2. Netzwerksicherheit in der Cloud muss den gesamten Unternehmensverkehr „sehen“ können, unabhängig von dessen Quelle.

Cloud-Instanz (Workload-Sicherheit zur Laufzeit)

Die Begriffe in der Sicherheit und die Paradigmen ändern sich, um dem Verständnis der zu schützenden Komponenten Rechnung zu tragen. In der Cloud bezeichnet das Konzept der Workload eine Einheit von Fähigkeiten oder das Arbeitsaufkommen, das in einer Cloud-Instanz ausgeführt wird. Der Schutz von Workloads vor Exploits, Malware und unbefugten Änderungen stellt eine Herausforderung dar, da sie in Server-, Cloud- oder Container-Umgebungen ausgeführt werden. Workloads werden nach Bedarf dynamisch gestartet, aber jede Instanz sollte sowohl für den Cloud-Administrator sichtbar sein als auch durch eine Sicherheitsrichtlinie geregelt werden.

Bild 3. Workloads sollten auf Bedrohungen überwacht werden, unabhängig von ihrer Art oder dem Ursprung.

DevOps (Container-Sicherheit)

Der Container hat sich in den letzten Jahren zur zentralen Software-Einheit in Cloud-Services entwickelt. Durch die Verwendung von Containern wird sichergestellt, dass Software unabhängig von der tatsächlichen Computing-Umgebung zuverlässig ablaufen kann. Deren Replikation kann kompliziert werden, wenn beispielsweise bestimmte Codes, Werkzeuge, Systembibliotheken oder sogar Softwareversionen auf eine bestimmte Art und Weise da sein müssen.

Bild 4. Container bestehen aus verschiedenen Code Stacks und Komponenten und sollten nach Malware und Schwachstellen gescannt werden.

Insbesondere für Entwickler und Operations-Teams wird die Integration der Sicherheit während der Softwareentwicklung immer wichtiger, da zunehmend Cloud-first App-Entwicklung eingesetzt wird. Das bedeutet, dass Container auf Malware, Schwachstellen (auch in Softwareabhängigkeiten), Geheimnisse oder Schlüssel und sogar auf Compliance-Verletzungen gescannt werden müssen. Je früher diese Sicherheitsüberprüfungen während des Builds stattfinden, — am besten im Continuous-Integration-and-Continuous-Deployment-Workflow (CI/CD) — desto besser.

Applikationen (Serverlos, APIs, Web Apps)

Auf einigen serverlosen oder Container-Plattformen lässt sich traditionelle Sicherheit nicht einsetzen. Dennoch müssen einfache und komplexe Anwendungen selbst genauso gut gesichert werden wie die anderen Bereiche. Für viele Unternehmen stellt die schnelle und effiziente Programmierung und Bereitstellung neuer Anwendungen einen wichtigen Treiber für ihren Weg in die Cloud dar. Aber diese Anwendungen sind auch möglicher Eintrittspunkt für Laufzeitbedrohungen wie das Einschleusen von Code, automatisierte Angriffe und Befehlsausführung aus der Ferne. Finden Angriffe statt, so müssen Cloud-Administratoren auf die Details zugreifen können.

Dateispeicher

Unternehmen betrachten die Cloud hauptsächlich oder teilweise als Möglichkeit, Storage von den On-Premise-Servern dahin auszulagern. Cloud-Speicher für Dateien oder Objekte können zur Quelle für Infektionen werden, wenn aus irgendeinem Grund eine bekannte bösartige Datei hochgeladen wurde. Deshalb sollte Scanning für jede Art von Datei, unabhängig von deren Grösse, verfügbar sein und zwar idealerweise bevor sie gespeichert wird. Nur so lässt sich das Risiko minimieren, dass andere Nutzer auf eine bösartige Datei zugreifen und sie ausführen können.

Compliance und Governance

Datenschutzregularien wie die europäische Datenschutz-Grundverordnung (DSGVO), Industriestandards wie der Payment Card Industry Data Security Standard (PCI-DSS) und Gesetze wie Health Insurance Portability and Accountability Act (HIPAA) haben direkte Auswirkungen auf Unternehmen, die Daten vor allem in der Cloud verarbeiten und speichern. Cloud-Administratoren müssen die Compliance-Anforderungen mit den Vorteilen der Agilität der Cloud abgleichen. Dabei muss Sicherheitstechnologie Unternehmen die Gewissheit geben, dass ihre Installationen den besten Sicherheitspraktiken entsprechen; andernfalls können die Geldstrafen, die sich aus unbeabsichtigten Verstössen ergeben können, die Kosteneinsparungen leicht zunichtemachen.

Cloud-Sicherheitstechnologien

Bei so vielen „beweglichen“ Teilen muss ein Unternehmen, das über eine Cloud-Sicherheitsstrategie nachdenkt, darauf achten, die notwendigen Sicherheitstechnologien zu straffen, vom Schutz vor Malware und Intrusion Prevention bis hin zu Schwachstellenmanagement und Endpoint Detection and Response. Die Gesamtsicherheitslösung muss die Anzahl der Tools, Dashboards und Fenster, die als Grundlage für die IT-Analyse dienen, klein halten. Gleichzeitig muss sie in der Lage sein, die abstrakten Netzwerkgrenzen des ganzen Cloud-Betriebs des Unternehmens überzeugend zu visualisieren — unabhängig davon, ob eine Aktivität, wie z.B. die On-the-Fly-Tool-Entwicklung durch einen der Entwickler, von der IT bewilligt wurde oder nicht.

Trend MicroTM Hybrid Cloud Security kann beispielsweise DevOps-Teams dabei unterstützen, sicher zu entwickeln, schnell zu liefern und überall auszuführen. Die Lösung bietet funktionsstarke, schlanke, automatisierte Sicherheit innerhalb der DevOps Pipeline und liefert mehrere XGenTM Threat Defense-Techniken für den Schutz von physischen, virtuellen und Cloud-Workloads zur Laufzeit. Sie wird von der Cloud OneTM Platform unterstützt, die Unternehmen eine einheitliche Übersicht über die hybriden Cloud-Umgebungen liefert, sowie Sicherheit in Echtzeit durch Netzwerksicherheit, Workload-Sicherheit, Container-Sicherheit, Anwendungssicherheit, File Storage Security sowie Conformity-Dienste.

Unternehmen, die Security as Software für Workloads, Container Images sowie Datei- und Objektspeicher zur Laufzeit benötigen bietet Deep SecurityTM und Deep Security Smart Check Scans für Workloads und Container Images nach Malware und Schwachstellen während der Entwicklung-Pipeline.

Sicherheit bei Smart Manufacturing

In Zeiten von Industrie 4.0 setzen Unternehmen zunehmend auf intelligente Fertigungstechnologien (Smart Manufacturing). Dies bringt zahlreiche Vorteile mit sich, wie z.B. eine höhere Produktivität bei geringeren Kosten, aber damit gehen auch neue Angriffsvektoren einher, über die Bedrohungsakteure in intelligenten Fertigungsanlagen Fuss fassen oder sich lateral bewegen können. Im aktuellen Bericht „Attacks on Smart Manufacturing Systems: A Forward-looking Security Analysis“ analysiert das Trend Micro Forward-Looking Threat Research Team in Zusammenarbeit mit dem Politecnico di Milano (POLIMI) die Angriffsoberflächen für Industrie 4.0 sowie die Vielfalt spezifischer Angriffe auf heutige Roboter und die möglichen Folgen der Angriffe.

Smart Manufacturing beruht auf einer engen Integration zwischen IT- und Operational Technology (OT)-Systemen. Enterprise Resource Planning (ERP)-Software hat sich in Richtung Supply Chain Management (SCM) weiterentwickelt, das über Unternehmens- und Ländergrenzen hinweg alle Arten von Input sammelt und Endprodukte, Zahlungen und Funktionalität auf globaler Ebene liefert.

Supply Chain und Softwareentwicklung in Industrie 4.0

Jede Synergie erfüllt ein Geschäftsziel: Optimierung knapper Ressourcen über verschiedene Quellen hinweg; Minimierung der Herstellungs-, Liefer- und Lagerhaltungskosten über Regionen hinweg, Kontinuität des Betriebs durch Diversifizierung der Lieferanten oder Maximierung des Verkaufs über mehrere Lieferkanäle. Die Supply Chain beinhaltet nicht nur Rohmaterialien für die Fertigung, sondern auch Zulieferer von Komponenten, externe Mitarbeiter für nicht zum Kerngeschäft gehörende Funktionen, Open-Source-Software zur Optimierung der Entwicklungskosten und Subunternehmer für die Ausführung spezieller Konstruktions-, Montage-, Test- und Vertriebsaufgaben. Jedes Element der Supply Chain stellt eine Angriffsfläche dar.

Softwareentwicklung ist seit langem eine Teamleistung. Nicht nur die Designs müssen im gesamten Team klar sein, auch das Testen erfordert eine enge Zusammenarbeit zwischen Architekten, Designern, Entwicklern und der Produktion. Teams identifizieren Geschäftsanforderungen und stellen dann eine Lösung aus Komponenten zusammen, die aus öffentlich zugänglichen Bibliotheken stammen. Diese Bibliotheken können weitere Abhängigkeiten von Fremdcode unbekannter Herkunft enthalten. Vereinfachtes Testen hängt von der Qualität der gemeinsam genutzten Bibliotheken ab, aber gemeinsam genutzte Bibliotheksroutinen können nicht entdeckte (oder absichtlich versteckte) Fehler aufweisen, die erst in einer anfälligen Produktionsumgebung zum Vorschein kommen. Wer testet GitHub? Das Ausmass dieser Schwachstellen ist gewaltig.

Industrieroboter als Gefahr

Innerhalb des Herstellungsbetriebs legt die Verschmelzung von IT und OT zusätzliche Angriffsflächen frei. Industrieroboter liefern ein deutliches Beispiel. Diese Präzisionsmaschinen sind darauf programmiert, anspruchsvolle Aufgaben schnell und fehlerfrei auszuführen. Programmierbare Roboter können verschiedene Materialkonfigurationen ohne Unterbrechungen produzieren. Sie werden überall in der Fertigung, im Lager, in Distributionszentren, in der Landwirtschaft, im Bergbau und bald auch in Lieferfahrzeugen eingesetzt. Die Supply Chain ist automatisiert worden.

Die Protokolle, von denen Industrieroboter abhängen, gehen von der Annahme aus, dass die Umgebung isoliert ist, und ein Controller die Maschinen an einem Standort steuert. Da die Verbindung zwischen dem Controller und den gesteuerten Robotern fest verdrahtet war, war eine Identifizierung des Operators oder eine Überprüfung der Nachricht nicht erforderlich. Jedes Gerät ging davon aus, dass alle seine Verbindungen extern verifiziert wurden. Die Protokolle enthielten keine Sicherheits- oder Datenschutzkontrollen. Dann übernahm Industrie 4.0 die drahtlose Kommunikation.

Die Angriffe

Zu den möglichen Eintrittspunkten für einen Angriff auf ein Smart Manufacturing-System zählen Engineering Workstations (ein von Domänen-Usern gemeinsam genutztes System, das mit der Produktionshalle verbunden ist), kundenspezifische industrielle Internet-of-things (IIoT)-Geräte mit besserer Automatisierungsflexibilität als klassische Automatisierungshardware wie PLCs oder auch Manufacturing Execution System (MES)-Datenbanken mit kritischen Daten (die DB ist implizit für den Rest des Systems vertrauenswürdig).

Dieser Wechsel zur drahtlosen Kommunikation, der die Kosten für die Kabelverlegung in der Fabrik einsparte, öffnete die Netzwerke für alle Arten von Angriffen. Die Bedrohungsakteure fälschen Befehle, modifizieren Spezifikationen, ändern oder unterdrücken Fehleralarme, modifizieren Ausgabestatistiken und schreiben Logs neu. Die Folgen können gewaltig und doch nahezu unbemerkt sein.

Sicherheitsempfehlungen

Unternehmen müssen konkrete Schritte unternehmen, um ihre Systeme zu schützen:

  • Auf Netzwerkebene sollte Deep Packet Inspection eingesetzt werden, die die wichtigen, relevanten OT-Protokolle unterstützt, um verdächtige Payloads zu entdecken.
  • Auf den Endpunkten sollten regelmässige Integritätsüberprüfungen stattfinden, um bei jeder modifizierten Softwarekomponente Alerts zu erhalten.
  • Für IIoT-Geräte sind Code-Signaturen erforderlich. Sie sollten sich jedoch nicht nur auf die endgültige Firmware beschränken, sondern auch alle anderen Abhängigkeiten einschliessen, um sie vor Bibliotheken Dritter zu schützen, die bösartige Funktionen verbergen könnten.
  • Die Risikoanalyse für Automatisierungssoftware sollte je nach Bedarf massgeschneidert werden. In Systemen, in denen z.B. kollaborative Roboter Seite an Seite mit Menschen arbeiten, sollte die Sicherheit auf der Firmware-Ebene implementiert werden.

Darüber hinaus ist es empfehlenswert, dass Unternehmen sich nicht nur vor aktuellen, sondern auch vor möglichen künftigen Bedrohungen schützen, indem sie das gleiche Level für die Sicherheitsvorkehrungen wählen, wie auch bei den sicheren Coding-Praktiken und Abwehrmassnahmen für Nicht-OT-Software wie mobile Anwendungen, Webanwendungen und Cloud-Umgebungen.

Cloud One Webinare von Trend Micro

Mit Cloud One stellt Trend Micro seine Version einer zukunftsfähigen Security Plattform vor, die nicht nur die technischen Probleme seiner Kunden angeht, sondern auch konzeptionell Flexibilität und Agilität demonstriert und ermöglicht.
Um die neue Lösungsplattform detailliert zu erklären und Ihre Vorteile vorzustellen, haben wir eine Reihe von Live-Webinaren zu diversen Use Cases vorbereitet. Melden Sie sich an und erleben Sie Cloud One in Aktion!

Cloud One Workload Security – The Art of „Lift & Shift“
13.05.2020 | 14:00 Uhr – 14:30 Uhr

Die Grundlage der Workload Security Komponente im Cloud One Service Portal stellt Deep Security as a Service (DSaaS) mit seinen bewährten Modulen dar. Da Schutz- und Überwachungsmodule sowohl in lokalen Rechenzentren, als auch in der Cloud eingesetzt werden können, ergibt sich eine Vielzahl von Use Cases, die einfach adaptiert werden können.
Jetzt anmelden

Cloud One für DevOps und Cloud-native Anwendungen
19.05.2020 | 14:00 Uhr – 14:30 Uhr

In diesem Webinar sprechen wir über diese Themen:
Wie Sie Sicherheitsprobleme in Ihrer DevOps-Umgebung frühzeitig erkennen
Wie Sie Schwachstellen, Malware sowie sensible Daten Ihren Docker Container-Images zeitnah aufspüren
Wie Sie ausschließlich richtlinienkonforme Container betreiben
Und wie Sie in nur zwei Minuten codebasierte Sicherheit in Anwendungen integrieren können, ohne dass zusätzliche Codeänderungen oder Regeln erforderlich sind
Jetzt anmelden

Cloud One Conformity – Sicherheit und Datenschutz über mehrere Cloud-Umgebungen hinweg
26.05.2020 | 14:00 Uhr – 14:30 Uhr

Zentrales Thema vieler Betriebe ist das Konzept Hybrid Collaboration: Business Kommunikation und die Zusammenarbeit von Teams auf der ganzen Welt. Doch dieser Ansatz will gut durchdacht sein, um keine Risiken in Sachen Datenschutz und Compliance einzugehen. Im Webinar reden wir über:
– Cloud Operation best practice
– AWS Well Architected Framework
– Automatic Security & Compliance Posture Remediation
Jetzt anmelden

Cloud One – Netzwerk Sicherheit
28.05.2020 | 14:00 Uhr – 14:30 Uhr

Mit der Cloud One Network Security Komponente steht Ihnen die Funktionalität, und bei Bedarf auch die Performance, der bewährten TippingPoint IPS Lösung in der Cloud zur Verfügung. Wenn Sie Netzwerkzugriffe unabhängig von Systemen und Verfahren auch in der Cloud überwachen bzw. absichern müssen, ist das Cloud One Network Security Modul die erste Wahl.
Jetzt anmelden

Prinzipien für die Cloud Migration – das „Was“ bei der Sicherheit

Originalbeitrag von Jason Dablow

Analysten gehen davon aus, dass mehr als 75 Prozent der mittleren und großen Unternehmen bis 2021 eine Workload in die Cloud auslagern werden. Der Erfolg einer solchen Migration hängt von vielen Faktoren ab — nicht zuletzt von den umgesetzten Sicherheitskonzepten für diese „neue“ Welt: Nach der Verteilung der Verantwortlichkeiten für Cloud-Security stellt der Blogeintrag die prinzipiellen Bereiche dar, die zur Sicherheit gehören und bereits vor der Inbetriebnahme von Workloads abgedeckt werden müssen.

Als Grundlage für die Ausführungen dient der Grundpfeiler „Security“ des Well-Architected Framework von AWS Amazon. Hier werden die Sicherheitskonzepte für ein Cloud-Design dargestellt.

Bild. Die fünf Grundpfeiler des Well-Architected Framework von AWS

Das Sicherheits-Framework umfasst sieben Prinzipien:

  • Eine starke Identitätsgrundlage aufbauen
  • Nachvollziehbarkeit ermöglichen
  • Sicherheit in allen Schichten anwenden
  • Automatisieren von Best Practices für die Sicherheit
  • Schutz für Daten In-Transit und At-Rest
  • Personen von Daten fernhalten
  • Auf Sicherheitsvorfälle vorbereitet sein

Eine Reihe dieser Prinzipien lässt sich mit Hilfe nativer Cloud-Services umsetzen, die auch am einfachsten zu implementieren sind. Das Framework liefert aber keine Anregungen dazu, wie diese Services aufzusetzen oder zu konfigurieren sind. So mag das Framework Multifaktor-Authentifizierung als erforderlichen Schritt für die Identity und Access Management-Policy nennen, doch ist dies nicht standardmäßig aktiviert. Das Gleiche gilt für Dateiobjekt-Verschlüsselung. Sie kann eingesetzt werden, ist aber nicht unbedingt bereits aktiviert.

Hilfe bietet hier eine Trend Micro-eigene Wissensdatenbank mit Hunderten von Cloud-Regeln, die auf das Well-Architected Framework (und andere) abgestimmt sind. Zur Multifaktor-Authentifizierung etwa gibt es dort einen Artikel, der die vier „R“ beschreibt: Risiko, Reason (umfasst das Was der Regel), Rationale (umfasst das Warum) und Referenzen dazu, warum Multifaktor-Authentifizierung (MFA) eine Sicherheits-Best Practices ist. Weitere Details zu diesem Beispiel enthält der Originalbeitrag.

Ungesicherte Redis-Instanzen werden für Remote Code Execution missbraucht

Originalartikel von David Fiser und Jaromir Horejsi, Threat Researcher

Die Sicherheitsforscher von Trend Micro hatten kürzlich mehr als 8.000 ungesicherte Redis-Instanzen (weit verbreiteter Open-Source In-Memory-Schlüsselwert-Datenstrukturspeicher) entdeckt, die in verschiedenen Teilen der Welt betrieben werden, sogar welche in öffentlichen Clouds. Cyberkriminelle können diese Instanzen für Remote Code Execution (RCE) missbrauchen. Die bösartigen Dateien wandeln sie in Kryptowährungs-Mining Bots um und können auch weitere angreifbare Instanzen über ihre „wurmartigen“ Verbreitungsfunktionen infizieren.

Redis war den Entwicklern zufolge ursprünglich allein auf den Einsatz in vertrauenswürdigen Umgebungen ausgerichtet und beinhaltet seit der Version 4.0 eine Protected Mode-Konfiguration. Der Speicher soll gerade auf die neue Version Redis 6.0 upgedatet werden. Diese bringt neue Sicherheitsfähigkeiten mit, wie etwa Access-Control Lists (ACLs).

Momentan jedoch sind Redis-Instanzen ohne TLS-Verschlüsselung (Transport Layer Security) oder Passwortschutz anfällig für Angriffe, wobei Cyberkriminellen über 200 Befehle zur Verfügung stehen, sobald sie in die Umgebung eindringen. Gegenwärtig ist bei Redis die Authentifizierung nicht standardmäßig eingestellt. Und selbst wenn ein Passwort gesetzt ist, ist es wichtig, sich vor Augen zu halten, dass das Passwort stark genug sein sollte, um gegen Brute-Force-Angriffe resistent zu sein.

Die Sicherheitsforscher setzten mögliche Szenarien in einem Honeypot ein, um Angreifer anzulocken und überwachen zu können. Dabei geht es um den Missbrauch des config-Befehls oder der slaveof-Fähigkeit. Die Forscher konnten auch einige bemerkenswerte Malware-Samples sammeln, die in exponierten Redis-Instanzen über eine der oben genannten Methoden verbreitet wurden: einen plattformübergreifenden Shell-basierten Wurm, der Kryptowährungs-Miner installiert, oder Kinsing-Malware, die sowohl Scanning- als auch Backdoor-Fähigkeiten besitzt. Die technischen Einzelheiten dazu liefert der Originalbeitrag.

Fazit und Sicherheitsempfehlungen

Insbesondere im Umfeld der DevOps, sollten angemessene Sicherheitsmaßnahmen vorhanden sein. Dass exponierte Redis-Instanzen für Kryptowährungs-Mining eingesetzt werden können, ist möglicherweise nicht die einzige Art des Missbrauchs, da die Fähigkeit, Code auszuführen, sozusagen der „heilige Gral“ eines Angreifers ist.

Entwickler können die Umgebung über folgende Best Practices besser schützen:

  • Beim Betrieb von Software auf dem Server ist sicherzustellen, dass sie nicht unter root läuft. Auch beim Einsatz von Containern müssen Nutzer Best Practices befolgen und das Prinzip der Mindestprivilegien anwenden.
  • Die Software immer auf aktuellem Stand halten und starke Passwörter wählen. Keine Verbindung zum Internet ohne geeignete Sicherheitsmaßnahmen.
  • Die Überprüfung von Redis Logs zeigt gerade stattfindende Angriffe.

Cloud-Sicherheitslösungen von Trend Micro

Die Trend Micro Hybrid Cloud Security bietet in einer Lösung die Breite, Tiefe und Innovation, die für den Schutz der Cloud erforderlich sind und zusätzlich die benötigte Übersicht über führende Umgebungen wie Amazon Web ServicesMicrosoft AzureGoogle Cloud und Docker. Zu der Funktionalität zählen automatisierte Installation und Inbetriebnahme, breite API-Integration sowie Sicherheitstechnologie für betriebliche Effizienz und Compliance-Anforderungen.

Die Trend Micro Cloud One SaaS-Plattform Sicherheit für die Cloud-Infrastruktur in Echtzeit – mit optimalem Schutz und Unterstützung der Compliance für Workloads, Anwendungen, Container, serverlose Dateispeichersysteme und Netzwerke sowie die Übersicht über die hybriden Cloud-Umgebungen im Unternehmen. Deep Security und Deep Security Smart Check unterstützen Unternehmen durch das Scannen von Container-Images vor und während der Laufzeit.

Cloud One schließt auch Cloud One – Conformity mit ein. Die Lösung liefert automatische Kontrollmechanismen für AWS ElasticCache (einer In-Memory Datenspeicher-Technologie für Redis). Sie stellt sicher, dass Redis nicht über den Default Port läuft und bietet auch Datenverschlüsselugn in Transit und At-Rest.

Trend Micro™ Deep Security™ und Vulnerability Protection schützt Anwender über folgende Regeln:

  • 1010231 – Redis Cron Remote Code Execution Vulnerability
  • 1009967 – Redis Unauthenticated Code Execution Vulnerability