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.

Durchgängiges Deep Learning für Cybersicherheit

Originalartikel von Spark Tsao, Data Scientist

Die Branche der Cybersicherheit ist eine der vielen Bereiche, die ganz erheblich von KI profitiert haben. Effizient eingesetzt verbessert die künstliche Intelligenz die Fähigkeiten von Cybersicherheitslösungen, ein breites Spektrum der Bedrohungen zu erkennen, einschliesslich brandneuer oder nicht klassifizierter Gefahren. Der Prozess der effizienten Nutzung der KI umfasst unter anderem in der Regel modernste Modelle, eine iterative Methode zur Verbesserung der Genauigkeit des Modells und genau gekennzeichnete Daten.

In vielen Cybersicherheitsunternehmen, die KI einsetzen, werden die genannten Anforderungen – insbesondere der Prozess der genauen Kennzeichnung von Daten – durch Bedrohungsexperten unterstützt. Diese kümmern sich neben anderen manuellen Aufgaben oder Prozessen, die handgefertigte Eingaben produzieren, um die Vorverarbeitung der Daten und die Extraktion sowie Entwicklung der Funktionalität. Im Wesentlichen ermöglichen diese von Experten handgefertigten Eingaben eine eindeutigere Ausführung von Modellen, da die zugrunde liegende Struktur der Daten somit genau dargestellt werden kann, wodurch die Fähigkeiten zur Erkennung von Bedrohungen verbessert werden.

Das Aufkommen neuer Methoden zur Erkennung von Bedrohungen mit Hilfe der KI stellt jedoch den Bedarf an handwerklichem Input von Experten in Frage. Insbesondere beinhalten diese Methoden durchgehende, Deep Learning-Lösungen, die von einigen als der nächste grosse Meilenstein in der Malware-Erkennung angepriesen werden. In solchen Lösungen werden die von Expertenerarbeiteten Eingaben durch solche ersetzt, die von automatisierten Prozessen bereitgestellt werden. Während dies in einigen Industriezweigen, die KI für verschiedene Zwecke einsetzen, wohl immer mehr akzeptiert wird, wirft das Fehlen handwerklicher Eingaben von Experten die Frage auf, ob handwerkliche Eingaben von Experten bei der Entwicklung einer effizienten KI-gestützten Cybersicherheitslösung noch relevant sind oder nicht.

Ein Ansatz untersuchte Malware-Binärdateien, die als Graustufenbilder dargestellt wurden, was die textuellen und strukturellen Ähnlichkeiten und Unterschiede entweder zwischen Binärdateien derselben und anderer Malware-Familien oder zwischen Malware und gutartiger Software aufzeigte. Dadurch wird das manuelle Feature-Engineering vermieden, was Zeit spart und den Arbeitsaufwand für Cybersicherheitsunternehmen verringert. Ein weiterer Ansatz umfasst einen Prozess, bei dem die Engine mit Rohdaten gefüttert wird, die aus Byte-Rohwerten bestehen, und Output erzeugt, der die Klassifizierung einer bösartigen oder gutartigen Datei anzeigt.

Informieren Sie sich eingehender über die Entwicklungen im durchgängigen Deep Learning für Cybersicherheit und über die derzeitige und künftige Effizienz.

Trend Micro Halbjahresbericht 2020: Sicherheit in pandemischen Zeiten

von Trend Micro

Die Covid-19-Pandemie hat die Cybersicherheitslandschaft in der ersten Hälfte 2020 stark geprägt. Während sich die Menschen an neue Arbeits- und Schulumgebungen anpassten, mussten Unternehmen für ihre Mitarbeiter Setups für die Arbeit zu Hause (Work-from-Home, WFH) schaffen und dabei dafür sorgen, dass deren Systeme auch sicher sind. Böswillige Akteure machten sich die Situation zunutze, indem sie das Thema Covid-19 für ihre Angriffe nutzten. Gruppen von Bedrohungsakteuren setzten ihre Kampagnen fort und dehnten ihre Reichweite auf neue Ziele und Plattformen aus, während sich die Betreiber von Ransomware weiterhin auf gezielte Angriffe konzentrierten. Trend Micro gibt in einer Zusammenfassung zur Jahresmitte 2020 den Überblick über die Trends und Ereignisse der ersten Jahreshälfte.

Böswillige Akteure haben schon immer gesellschaftlich relevante Ereignisse zur Durchsetzung ihrer Pläne genutzt, und bei Covid-19 ist das nicht anders. Die Sicherheitsforscher fanden eine Vielzahl von Vorfällen, in denen Cyberkriminelle pandemiebezogene Köder für ihre bösartigen Aktivitäten einsetzten, von relativ harmlosen Betrugsmaschen bis hin zu destruktiven Kampagnen, die fortgeschrittene Malware verbreiteten.

Der abrupte Wechsel auf WFH-Setups stellte Unternehmen vor zahlreiche Herausforderungen. Abgesehen von der Notwendigkeit, den Mitarbeitern die für die Aufrechterhaltung des Betriebs benötigten Werkzeuge zur Verfügung zu stellen, hatten Unternehmen mit Fragen der Kommunikation, Konnektivität und sogar der Zuweisung von IT-Ressourcen zu kämpfen.

Bild 1. Zahl und Verbreitung von Covid-19-Bedrohungen in der ersten Hälfte 2020

Ransomware-Betreiber konzentrieren sich auf ausgewählte Ziele

Ransomware hat sich von seinen opportunistischen Wurzeln, zu denen nicht personalisierte Spam-Kampagnen gehörten, zu einem gezielteren Ansatz entwickelt, bei dem oft der Diebstahl von Credentials und andere komplexe Techniken eingesetzt werden, um das Zielsystem zu kompromittieren. Die Hauptopfer dabei sind Organisationen, die viel zu verlieren haben und in der Lage sind, hohe Lösegeldforderungen zu erfüllen. Darüber hinaus stellten die Forscher auch einen wachsenden Trend fest, bei dem Betreiber von Ransomware ihren Opfern mit der Veröffentlichung ihrer Daten drohen, falls das Lösegeld nicht bezahlt wird.

Bild 2. Halbjahresvergleich der Anzahl der entdeckten Ransomware-bezogenen Komponenten (Dateien, Emails und URLs)

Schwachstellen sind weiterhin ein relevantes Problem

Mit der Verlagerung hin zur Remote-Arbeit ist das Patching wichtiger denn je. In der ersten Jahreshälfte wurde eine grosse Anzahl veröffentlichter und gepatchter Schwachstellen gemeldet, darunter mehrere kritische Fehler, die bereits in der Praxis ausgenutzt wurden. Für die Unternehmen könnte dies zu einer zusätzlichen Arbeitsbelastung ihres IT-Personals führen, das diese Updates implementieren und darüber hinaus sicherstellen muss, dass die IT-Infrastruktur des Unternehmens unter den neuen Arbeitsumgebungen so nahtlos wie möglich funktioniert.

Zwischen Ende 2019 und Anfang 2020 wurden zwei verschiedene Gruppen von Schwachstellen entdeckt, die Industrial Internet of Things (IIoT)-Geräte betreffen. Solche Sicherheitslücken könnten einen erheblich schädlichen Einfluss auf betroffene Branchen und Organisationen haben und zu möglichen zukünftigen Regelungen für das IIoT im Allgemeinen führen.

Bild 3. Halbjahresvergleich der Anzahl der Schwachstellen, die das ZDI-Programm veröffentlicht hat

Mehrschichtige Sicherheit als Verteidigung vor heutigen vielfältigen Bedrohungen

Die Herausforderungen im Bereich der Cybersicherheit, denen viele Organisationen in der ersten Hälfte des Jahres 2020 ausgesetzt waren, beweisen, dass eine mehrschichtige Lösung, die eine Mischung aus Fähigkeiten zur Bedrohungsabwehr bieten kann, am besten für eine umfassende Sicherheitsimplementierung geeignet ist, die sowohl in Büro- als auch in Privatumgebungen funktioniert.

Weitere Einzelheiten liefert der Report:

Unsichere gRPC-Implementierungen können APIs gefährden

Originalartikel von David Fiser, Security Researcher

Unternehmen setzen immer häufiger Microservice-Architekturen für ihre Anwendungen ein, weil diese Dienste ein effizientes Infrastrukturmanagement ermöglichen, Updates und Verbesserungen können einfacher bereitgestellt und Anwendungen auf Wunsch skaliert werden. Im Zuge dieses Architekturwechsels entsteht auch die Notwendigkeit einer effizienten Kommunikation zwischen den Microservices. Diese kritische und komplexe Kommunikation zwischen Client- und Server-Anwendungen lässt sich mit gRPC, einem universellen Remote Procedure Call (RPC)-Framework, bewerkstelligen. Obwohl es noch recht neu ist (2015 von Google entwickelt), hat das Framework schnell an Popularität gewonnen. Doch können noch Sicherheitsfragen entstehen, wenn Entwickler gRPC in ihre Projekte aufnehmen. Und da gRPC APIs eine wichtige Rolle für die allgemeine Anwendungssicherheit spielen, liefert Trend Micro auch Empfehlungen für den Schutz von gRPC-Implementierungen.

gRPC kann für das Design neuer Protokolle verwendet werden, die Genauigkeit, Effizienz und Sprachunabhängigkeit erfordern, denn das Framework unterstützt mehrere Sprachen sowohl für Server als auch für Clients. Es handelt sich um ein Cloud Native Computing (CNCF)-Projekt und wird in grossen Unternehmen wie Netflix, dem Finanzdienstleister Square und der Platform-as-a-Service (PaaS) Docker eingesetzt.

gRPC lässt sich mit anderen RPC Frameworks wie SOAP und REST vergleichen. Obwohl RESTful-APIs weit verbreitet sind und typischerweise HTTP verwenden, um Informationen zwischen Anwendungen oder Diensten und dem JavaScript Object Notation (JSON)-Datenformat auszutauschen, haben gibt es Einschränkungen hinsichtlich Leistung und textbasierter Ausrichtung. Viele Unternehmen haben ihre APIs von REST auf gRPC migriert, um die Vorteile des Binärprotokolls von gRPC zu nutzen. gRPC verwendet standardmässig als darunterliegende Schicht HTTP/2, ein binärbasiertes Protokoll. HTTP/2 unterstützt mehrere Streams und Anfragen innerhalb einer TCP-Verbindung. Weitere Einzelheiten bietet der Originalbeitrag.

Bild 1. Arbeitsweise des gRPC Framework in einer Online Shopanwendung mit Produkt- und Bezahlservices, die über ein API interagieren

Mögliche Bedrohungen und Risiken für gRPC

Sicherheitslücken

gRPC unterstützt mehrere Programmiersprachen. Es gibt zwei Arten von Implementierungen, die innerhalb der unterstützten Sprachen verwendet werden: Implementierungen, die die Sprache selbst verwenden, und Wrapper um den von gRPC geschriebenen C-Code.  Diese Wrapper ermöglichen die Übersetzung von in verschiedenen unterstützten Sprachen geschriebenen Aufrufen in C-Aufrufe. Die Wahrscheinlichkeit, dass ein Entwickler eine Schwachstelle in das System einführt, ist hoch, da mehr Funktionen zusammen mit Memory-Managementfunktionen implementiert werden müssen. Auf der anderen Seite verringert die Verwendung von Sprachen wie Java oder Go, die bereits viele Funktionalitäten implementiert haben und sich auch um Fragen der Speicherverwaltung kümmern, die Wahrscheinlichkeit von potenziellen Fehlern. Insbesondere die Bedeutung der Auswahl geeigneter Sprachen könnte eine wichtige Rolle bei der Erhöhung der Sicherheit von Systemen spielen. Eine Übersicht im Originalbeitrag.

Unsichere Datenübertragungskanäle und Zugangsdaten dafür

Es ist sehr wahrscheinlich, dass bei einem Remote Procedure Call Daten zum Zielserver übertragen werden. Deshalb sollten Entwickler auf die Einrichtung sicherer Kanäle für die Datenübertragung achten. Dadurch werden nicht nur Datenlecks verhindert, sondern auch Man-in-the-Middle (MiTM)-Angriffe, über die Angreifer Servicedaten leaken könnten. Ein Data Leak kann Implementierungsdetails zum Service oder zur Infrastruktur öffentlich machen und somit weitere Angriffe ermöglichen oder zur Kompromittierung der Infrastruktur oder des Service führen.

Es liegt in der Verantwortung des Entwicklers, eine sichere Implementierung unter den verschiedenen Authentifizierungsmechanisem zu wählen. Das Kopieren und Einfügen von Patterns mit Schlüsselwörtern wie „InsecureChannelCredentials“ sollte vermieden werden. Eine Code-Suche auf Github.com nach dem Schlüsselwort „InsecureChannelCredentials“ und C++ (für gRPC üblich) gab über 11.000 Code-Ergebnisse. Wahrscheinlich sind diese vielen Suchvorgänge mit Demos und Beispielen verbunden. Dennoch gibt es immer noch einige Projekte, die diese verwenden.

Probleme bei der Procedure-Implementierung

Die grösste Schwachstellenfläche befindet sich innerhalb der Remote Procedure-Implementierung. Für nicht sehr erfahrene Entwickler empfiehlt es sich, Memory-sichere Sprachen zu verwenden, um Fehler in der Speicherverwaltung wie Buffer Overflows oder UaF-Fehler Used After Free) zu vermeiden, die zu einer Remote Code Execution führen. Doch durch diese Massnahme werden logische Fehler, die im Code auftauchen könnten, nicht vermieden. Dafür müssen Entwickler einen hohen Standard in Entwicklungsprozesse setzen, den Best Practices für sichere Softwareentwicklung folgen und proaktive Kontrollmechanismen installieren, gemäss den OWASP Top 10 Proactive Controls-Empfehlungen in den OWASP Secure Coding Practices.

Ein zentralisierter Authentifizierungsmechanismus für kritische Teile des Systems wird auch innerhalb isolierter Netzwerke oder privater Clouds dringend empfohlen. Im Fall von Fehlkonfigurationen kann die Ausnutzung von Schwachstellen innerhalb der Umgebung als Einstiegspunkt für einen unberechtigten Zugriff dienen, der den gRPC-Dienst erheblich beeinträchtigen könnte.

Die Fachleute raten auch davon ab, gRPC-Authentifizierungsdetails in Supply-Chain-Management-Systemen (SCM), insbesondere in öffentlich zugänglichen Systemen, hart zu codieren oder sie dort vorzuhalten. Sie sollten an einem sicheren Ort gespeichert und nur bei Bedarf abgerufen werden.

Denial-of-Service-Angriffe

gRPC lässt sich sowohl als „versteckter“ Messaging Service in einer isolierten Umgebung als auch als API-Ersatz in der Öffentlichkeit zugewandten REST API-Services einsetzen. Es gibt einen bereits bekannten und dennoch nicht gefixten Bug, der Service-Aufrufe ablehnt, bis der Service neu gestartet wird. Der Fehler wird angestossen, wenn eine höhere Zahl von Verbindungen in kurzer Zeit geöffnet werden. Weitere technische Details und Empfehlungen für einen Workaround bietet der Originalbeitrag.

Sicherheitsempfehlungen für gRPC

gRPC bietet einen umfassenden Leitfaden zu den unterstützten Authentifizierungsmechanismen, die mit dem Protokoll arbeiten, so etwa SSL/TLS mit und ohne Google Token-basierter Authentifizierung. Entwickler können auch ihr eigenes Authentifizierungssystem über das Credentials Plugin-API anschliessen.

Auch sollten Sicherheitslösungen zum Einsatz kommen, die Inhalte prüfen, sodass keine bösartige Payload das System über die Nachrichten, die vom Client auf den Server und umgekehrt gehen, infiltrieren kann. Die Lösungen müssen dafür sorgen, dass kritische Daten in Transit sicher sind, den Status eines Service im Auge behalten und Authentifizierung und Autorisierung durchsetzen.

Trend Micro-Lösungen

Die Service-Plattform Trend Micro Cloud One™ , die Trend Micro™ Hybrid Cloud Security unterstützt, ermöglicht es Entwicklern, Anwendungen auf ihre Art zu entwickeln und zu betreiben. Sie umfasst Mechanismen, die über vorhandene Infrastruktur, Tool-Ketten und Anforderungen hinweg arbeiten.

Application Security von Cloud One liefert diagnostische Einzelheiten zu Code-Schwachstellen sowie Schutz vor automatisierten Angriffen über Bedrohungen wie SQL Injection und RCE zur Laufzeit. Darüber hinaus gibt es eine vollständige Abdeckung und Berichterstattung über jede Angriffsinstanz sowie Einblicke in die Identität eines Angreifers und die Angriffsmethodik.

Cloud One bietet ausserdem die folgenden Cloud-Sicherheitstechnologien an:

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.

Mac Malware infiziert Xcode-Projekte

Originalartikel von Mac Threat Response and Mobile Research Team

Die Sicherheitsforscher von Trend Micro entdeckten eine ungewöhnliche Infektion im Zusammenhang mit Xcode-Entwicklerprojekten. Weitere Untersuchungen ergaben, dass das Xcode-Projekt eines Entwicklers im Wesentlichen die Quell-Malware enthielt und zu einem Schlupfloch für bösartige Payloads führt. Die bemerkenswerteste Entdeckung waren zwei Zero-Day-Exploits: einer wird zum Diebstahl von Cookies über einen Fehler im Verhalten von Data Vaults verwendet, ein anderer zum Missbrauch der Entwicklerversion von Safari.

Dieses Szenario ist recht ungewöhnlich, denn hier wird bösartiger Code in lokale Xcode-Projekte eingeschleust, so dass dieser beim Aufbau des Projekts ausgeführt wird. Die Bedrohung eskaliert, denn die Forscher entdeckten betroffene Entwickler, die ihre Projekte auf GitHub freigaben. Dies führt zu einem Supply-Chain-artigen Angriff auf Nutzer, die in ihren eigenen Projekten auf diese Repositorys als Abhängigkeiten angewiesen sind. Die Forscher identifizierten diese Bedrohung auch in Quellen wie VirusTotal, was darauf hindeutet, dass es sich um eine weitläufigere Bedrohung handelt.

Interessierte können die die Ergebnisse zur Untersuchung der Bedrohung hier nachlesen und auch einen technischen Bericht mit allen Einzelheiten des Angriffs.

Trend Micro-Sicherheitslösungen

Um Systeme vor dieser Art der Bedrohung zu schützen, sollten Nutzer Apps nur aus offiziellen und legitimen Marktplätzen herunterladen. Eine mehrschichtige Lösung wie Trend Micro Home Security for Mac bietet ebenfalls Schutz für mehrere Geräte. Des Weiteren können Unternehmen auf die Vorteile der Smart Protection Suites zurückgreifen. Sie Lösung setzt auf XGen™-Sicherheit mit High-Fidelity Machine Learning in einer Mischung verschiedener Schutztechniken, um Sicherheitslücken über alle Aktivitäten und Endpunkte hinweg zu schliessen.

Patches für Sicherheitslücken von Adobe, Citrix, Intel und vBulletin

Originalartikel von Trend Micro

Schwachstellen setzen Unternehmenssysteme der Kompromittierung aus. Jetzt, da viele Mitarbeiter von zu Hause aus arbeiten und Geräte ausserhalb der sicheren Büroumgebungen betreiben, ist die Notwendigkeit, Schwachstellen zu beheben, sobald sie entdeckt werden, noch dringlicher geworden. Neben Microsoft haben kürzlich auch die folgenden Anbieter Patches veröffentlicht: Adobe, Citrix, Intel und vBulletin. Es folgt eine Zusammenfassung dieser kürzlich bekannt gewordenen Schwachstellen, und Organisationen sind gut beraten, sofort zu prüfen, ob die von ihnen verwendete Software von diesen Schwachstellen betroffen ist.

Adobe-Sicherheitslücken

26 Lücken in eigenen Produkten wie Adobe Acrobat und Adobe Reader hat der Anbieter Im Rahmen der aktuellen Veröffentlichungen von Fixes behoben. Elf davon sind als „kritisch“ eingestuft worden. Bei den beiden CVE-2020-9696 und CVE-2020-9712 handelt es sich um Security Bypass-Probleme, die die Ausführung beliebigen Codes ermöglichen. Die kompletten Einzelheiten zu den Schwachstellen werden noch veröffentlicht.

Verschiedene Sicherheitsforscher hatten Adobe von den Schwachstellen in Kenntnis gesetzt. Abdul-Aziz Hariri von der Trend Micro Zero Day Initiative (ZDI) entdeckte CVE-2020-9712 sowie vier weitere als „wichtig“ eingestufte Lücken (CVE-2020-9697, CVE-2020-9706, CVE-2020-9707, CVE-2020-9710).

Citrix-Sicherheitslücken

Citrix veröffentlichte ein Security Bulletin, in dem der Anbieter die Entdeckung von fünf Sicherheitslücken in einigen Versionen von Citrix Endpoint Management (CEM), auch als XenMobile bekannt, ankündigte. Die beiden CVE-2020-8208 und CVE-2020-8209 gelten als „kritisch“.

Während über vier der Lücken nur wenige Informationen durchgedrungen sind, handelt es sich bei CVE-2020-8209 um einen Path Transversal-Fehler, der durch eine ungenügende Input-Validierung entsteht. Solche Schwachstellen ermöglichen es Angreifern, beliebige Dateien auf Servern zu lesen. Laut Andrew Menov, Experte bei Positive Technologies, können Bedrohungsakteure sie ausnutzen, indem sie eine URL erstellen und sie unter nichtsahnenden Benutzern verbreiten. Folgen diese der URL, könnten die Angreifer dann auf Dateien einschliesslich Konfigurationsdateien und Verschlüsselungs-Keys ausserhalb des Root-Verzeichnisses des Webservers zugreifen. Weitere Einzelheiten sollen noch folgen.

Intel-Sicherheitslücken

Intel veröffentlichte kürzlich Fixes für 22 Sicherheitslücken mit Bewertungen von „niedrig“ bis „kritisch“. Die kritische Lücke CVE-2020-8708 betrifft Intel Server Boards, Serversysteme und Rechenmodule vor der Version 1.59. Sie ermöglicht es nicht autorisierten Benutzern, die Authentifizierung zu umgehen und die Privilegien über angrenzende Zugriffe zu erhöhen.

Dmytro Oleksiuk, ein Informationssicherheitsforscher und -entwickler, der den Fehler entdeckte, erklärte gegenüber Threatpost, dass dieser Fehler in der Firmware von Emulex Pilot 3 sitzt. Emulex Pilot 3 wird von Motherboards verwendet und hilft dabei, Serverkomponenten in einem einzigen System zusammenzuhalten.

vBulletin-Sicherheitslücken

Eine im letzten Jahr bei der Internetforums-Software entdeckte Sicherheitslücke, die mittlerweile als geschlossen galt, scheint immer noch gefährlich zu sein. Das zeigten Proof-of-Concept Codes des Sicherheitsforschers Amir Etemadieh (Zenofex). Es geht um CVE-2019-16759, ein Fehler in vBulletin Versionen 5.x bis 5.5.4, der Remote Code Execution (RCE) ermöglicht über die Nutzung eines speziellen POST Requests. Zwar wurde schon seit langem ein Patch veröffentlicht, aber die Untersuchungen haben ergeben, dass Angreifer die Schwachstelle immer noch ausnutzen können, und es gibt PoCs in Bash, Python und Ruby. Bislang wurde noch kein offizieller neuer Patch veröffentlicht. Der Forscher hat einen temporären Workaround vorgestellt, den Administratoren anwenden können.

Schutz für Systeme

Folgende Massnahmen können zum Schutz vor Sicherheitslücken beitragen:

  • Systeme sofort patchen.
  • Regelmässige Updates von Software, Firmware und Anwendungen. Installieren der neuesten Versionen, denn diese enthalten auch die neuesten Fixes.
  • Einsatz von Sicherheitslösungen. Ein mehrschichtiger Sicherheitsansatz ist sinnvoll, vor allem in den Fällen, in denen Patches nicht sofort verfügbar sind.

Die folgenden Trend Micro-Lösungen erhöhen ebenfalls den Schutz vor Sicherheitslücken:

Trend Micro Deep Security und Vulnerability Protection schützen Nutzer vor der vBulletin-Sicherheitslücke mithilfe der folgenden aktualisierten Regel:

  • 1010366 – vBulletin ‚widgetConfig‘ Unauthenticated Remote Code Execution Vulnerability (CVE-2019-16759)

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“.

Leitlinien zur Sicherheit in Smart Factories: Konzepte und Managementsysteme im IEC62443-Standard

Originalartikel von Trend Micro

Die Sicherheit eines Industrial Control System (ICS) unterscheidet sich von der der IT. Auch OT Security genannt, betraf sie anfangs kritische Infrastrukturen wie die für Strom, Gas und Wasser. Doch im Zuge der Entwicklung hin zu offenen Systemen und Veränderungen bei den Bedrohungen infolge des Trends zu IIoT und Industry 4.0 sind die Sicherheitsbemühungen in verschiedenen Bereichen hinzugekommen. Es heisst, Stuxnet habe 2010 als globaler Auslöser gewirkt. Während des letzten Jahrzehnts haben verschiedene Länder und Industrien aktiv Richtlinien und Rahmenwerke entwickelt, doch mangelt es ihnen an Kohärenz. Bemerkenswert sind die kürzlich entwickelten zwei globale Standards bezüglich der Sicherheit in Smart Factories, nämlich IEC62443 und die NIST CSF, Serie SP800. Diese beiden sollen auch als typische Beispiele für allgemeine Richtlinien für die ICS- und OT-Sicherheit näher erläutert werden, um die für die Sicherheit in Smart Factories erforderlichen Konzepte besser zu verstehen.

Überblick über IEC62443

IEC62443 besteht aus einem Satz von 14 Dokumenten, die Spezifikationen für Sicherheitstechnologien in allgemeinen industriellen Steuerungssystemen (IACS: in dieser Norm Industrial Automation Control System genannt) enthalten. Der Standard wurde von der International Society of Automation (ISA) und der International Electrotechnical Commission (IEC) entwickelt. 8 der 14 Dokumente sind bisher veröffentlicht, und die Überarbeitung und Entwicklung ist im Gange.

IACS behandelt nicht nur technische Aspekte einschliesslich des Systems und der Ausrüstung, die ein System ausmachen, sondern auch organisatorische und verfahrenstechnische Punkte. Es heisst auch, dass Organisationen und Prozesse rund um Technologien als Teil eines Systems betrachtet werden. Die 14 Dokumente sind in Teildokumente mit Unternummern unterteilt: 1-1~4 General, 2-1~5 Policies & Procedure, 3-1~3 System und 4-1~2 Component. Zum Beispiel werden in 4 Component die Anforderungen an die Prozesse in einer Organisation, die ein Produkt entwickelt, und die Anforderungen an das Produkt selbst getrennt wie folgt angegeben: 4-1 Anforderungen an den Lebenszyklus der Sicherheitsproduktentwicklung und 4-2 Technische Sicherheitsanforderungen für IACS.

Bild 1: Übersicht über IEC62443 (Quelle: Trend Micro, auf Basis von IEC-Dokumenten)

Die Themen lassen sich in drei Klassen einteilen, wobei jede Aufgabe von den folgenden drei Parteien durchgeführt werden muss: Nutzerunternehmen, das ein System managt/betreibt (Asset Owner), Systemintegrator/Service Provider, der ein System entwirft/baut und Produktlieferant, der die Geräte und Instrumente, die ein System bilden entwickelt/liefert.

<1: General> umfasst die allgemeinen Konzepte und Referenzmodelle.

<2: Policies & Procedure> umfasst die Organisationen und Prozesse für Asset Owner.

<3: System> umfasst Systemdesignverfahren und Funktionsanforderungen für Systemintegratoren.

<4: Component> für Produktlieferanten.

Diese Klassifikation ist allgemein gehalten. In konkreten Fällen kann es vorkommen, dass die Rolle einer Systemregion in 3 von dem Nutzerunternehmen wahrgenommen wird, und in einem anderen Fall wird der Prozess in 2 von einem Systemintegrator oder Dienstleister unter dem Gesichtspunkt des Betriebs und der Wartung abgewickelt.

Bild 2. Asset Owner, Systemintegrator und Produktanbieter (Quelle: Trend Micro, auf Basis von IEC-Dokumenten)

Konzept: Defense in Depth

IEC62443-1-1 beinhaltet mehrere Konzepte und Modelle. Unter anderen geht es auch um Defense in Depth, ein wohlbekanntes Konzept in der Welt der Informationssicherheit. Doch es handelt sich nicht um eine einfache Massnahme, über die mehrere Gegenmassnahmen-Technologien zusammen verwendet werden. Es gilt vielmehr, Massnahmen nach Sicherheitsaspekten in Schichten zu trennen und diese dann in unabhängigen Layern zu stapeln. Neben der Technologie sind auch Massnahmen für Personal, Organisationen und Prozesse in verschiedenen Schichten umzusetzen. Wichtig ist, Cybersicherheit in allen Bereichen zu implementieren. Technologisch empfiehlt es sich auch, die Netzwerkumgebung von IACS in Zonen und Leitungskanäle zur Verbindung der Zonen zu separieren und dann die Anlagen durch Trennung in Gruppen mit gemeinsamen Sicherheitsstufen zu verwalten. (mehr dazu in Teil 2).

Managementsystem: Cyber Security Management System (CSMS)

IEC62443-2-1 spezifiziert den Rahmen von Management und Betrieb für Asset Owner. Es handelt sich um einen so genannten PDCA-Zyklus, der mit der Analyse von schwerwiegenden Risiken beginnt, gefolgt von der Risikoanalyse spezifischer Fälle, dem Entwurf von Richtlinien, Umstrukturierung von Organisationen, Schulung, Umsetzung von Managementmassnahmen, Audit und Review. Ein Mechanismus zur Aufrechterhaltung/Verwaltung dieser Sicherheit wird als CSMS bezeichnet, und es gibt auch ein Zertifizierungssystem.

Die Beziehung zwischen IEC62443-2-1 und CSMS-Zertifizierung ist die gleiche wie die Beziehung zwischen ISO27001 und ISMS-Zertifizierung in der Informationssicherheit. Da das CSMS auf der Grundlage des ISMS entwickelt wurde, sind viele Gemeinsamkeiten zwischen ihnen vorhanden, und der Rahmen für den PDCA-Zyklus ist derselbe. Andererseits sind die beiden auf unterschiedliche Ziele ausgerichtet. Die Ziele des ISMS sind alle Information Assets, während für das CSMS nicht nur Informationen, sondern auch das IACS darin enthalten sind. Ein weiterer Unterschied besteht hinsichtlich des vorausgesetzten Vorfalls, denn für ISMS ist das wichtige Anliegen der Verlust der Vertraulichkeit, Integrität und Verfügbarkeit von Informationen, und CSMS hält die Verfügbarkeit für besonders wichtig.

Bei einer Organisation, die bereits eine ISMS-Zertifizierung erworben hat, kann davon ausgegangen werden, dass ihr das Konzept des CSMS bekannt ist. Es hängt jedoch von der individuellen Situation ab, ob sie eine Zertifizierung erwerben kann.

Bild 3: CSMS (Quelle: Trend Micro, auf Basis von IEC-Dokumenten)

IEC und ISO

Wie schon der Name ahnen lässt, liefert International Electrotechnical Commission (IEC) technologische Standards in der Elektrotechnik und Elektronik. Die International Organization for Standardization (ISO) beschäftigt sich mit anderen Bereichen. Als bekannte Beispiele sind die Normen für Trockenzellenbatterien der IEC und die Normen für Schrauben der ISO zu nennen. Im Bereich der Fertigungsindustrie gibt es viele Normen für die Sicherheit im Sinne von Safety. Beispielsweise kommen von der IEC Safety-Standards für elektrische Geräte (IEC60204), Normen für funktionale Safety (IEC61508) und von der ISO die allgemeinen Grundsätze für das Safety-Design von Maschinen (ISO12100) sowie Normen für Systeme und Teile (ISO13849). Darüber hinaus werden in der ISO die Regeln und Mechanismen einer Organisation auch als Managementsystem standardisiert. Neben der ISO27001 (Informationssicherheitsmanagement) werden auch bekannte Themen wie ISO9001 (Qualitätsmanagementsystem) und ISO14001 (Umweltmanagement) sowie allgemeinere Themen wie ISO31000 (Risikomanagement) behandelt.

In der IEC und ISO gibt es viele industrielle technologiebezogene Safety-Normen sowie Leitfäden zur Beschreibung dieser Normen (ISO/IEC Guide 51: 2014 „Safety Aspects – Guidelines for Their Inclusion in Standards“). In diesen Normen wird Risiko als die „Kombination der Wahrscheinlichkeit des Auftretens eines Schadens und der Schwere dieses Schadens“ definiert und Sicherheit als „Vermeiden von Risiken, die nicht tolerierbar sind“. Die Grundhaltung zu Risiken lässt sich folgendermassen beschreiben: Unter der Annahme, dass das Risiko niemals 0 wird, ist zu bestimmen, welche Risiken akzeptiert werden können und bis zu welchem Grad ein Risiko tragbar ist. Dann ist zu überlegen, was getan werden sollte, um inakzeptable Risiken auf ein annehmbares Niveau zu reduzieren.

Fazit

IEC und ISO-Standards sind im Einklang mit Änderungen in der Technologie und der Gesellschaft permanent überarbeitet/weiterentwickelt worden. In einer relativ neuen Richtlinie (ISO Guide 73: Risk Management) wird Risiko als „der Effekt von Unsicherheit auf ein Objekt“ definiert. In der industriellen Welt ist es auch von Bedeutung, wie Sicherheit und Safety integriert und gehandhabt werden sollten. Es gibt den Vorschlag einer neuen Norm (IEC TR 63069: Industrial-Process Measurement, Control and Automation – Framework for Functional Safety and Security).

Ein nächster Teil wird die Level in System-Design und Sicherheit der IEC62443 behandeln.