Archiv für den Monat: August 2020

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-9697CVE-2020-9706CVE-2020-9707CVE-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.

Lost in Translation: Wenn industrielle Protokollübersetzung schiefgeht

Originalartikel von Marco Balduzzi, Luca Bongiorni, Ryan Flores, Philippe Z Lin, Charles Perine, Rainer Vosseler

Die Übersetzung ermöglicht den weltweiten Informationsaustausch, das gilt auch für Industrial Internet of Things (II0T)-Umgebungen, wo verschiedene Geräte wie Schnittstellen, Sensoren und Maschinen mit unterschiedlichen Protokollen eingesetzt werden. Protokoll-Gateways sind für die Übersetzung dieser verschiedenen Protokolle in industriellen Einrichtungen zuständig. Trend Micro hat in einem Forschungsprojekt die Schlüsselrolle der Protokollübersetzung und die der Protokoll-Gateways untersucht.

Dabei geht es um ein kleines Gerät, das die verschiedenen Protokolle übersetzt, die von Maschinen, Sensoren und Computern verwendet werden, die Smart Factories, Staudämme, Kraftwerke und andere Industrieanlagen betreiben.

Bild. Position eines Protokoll-Gateways am unteren Rand des Kontrollnetzwerks

Versagen die Protokoll-Gateways, so bricht die Kommunikation zwischen den Steuerungssystemen und der Maschinenanlage zusammen. Die Bediener können die Übersicht über das System verlieren, so dass sie nicht mehr erkennen, ob Maschinen oder Generatoren ordnungsgemäss laufen. Ein Ausfall der Übersetzung kann den Bediener auch daran hindern, Befehle zur Fehlerbehebung zu erteilen. Das Whitepaper „Lost in Translation: When Industrial Protocol Translation goes Wrong“ fasst die Forschungsergebnisse zu den Risiken im Zusammenhang mit Protokoll-Gateways zusammen, sowie die möglichen Auswirkungen eines Angriffs oder der falschen Übersetzung und zeigt Möglichkeiten für die Sicherheit dieser Geräte auf.

Wichtige Erkenntnisse

Die Forscher fanden vielfältige Sicherheitsprobleme und Schwachstellen in den Gateways, die den Betrieb einer Einrichtung auf verschiedene Weise beeinträchtigen kann:

  • Spezifische Szenarien, in denen ein Angreifer Schwachstellen in der Übersetzungsfunktion ausnutzen könnte, um heimlich Befehle zu erteilen, die den operativen Prozess sabotieren können,
  • Authentifizierungsschwachstellen, die den nicht autorisierten Zugang ermöglichen,
  • Schwache Verschlüsselung, die die Entschlüsselung von Konfigurationsdatenbanken erlaubt,
  • Nicht fachgerechte Implementierung von Authentifizierungsmechanismen, wodurch vertrauliche Informationen exponiert werden könnten und
  • Bedingungen für Denial of Service (DoS).

Diese Sicherheitslücken könnten die Sicherheit, Prozesse und Ergebnisse einer Anlage erheblich beeinträchtigen. Als Folge der Fehler würde ein Angreifer in der Lage sein, Techniken zur Darstellungs- und Kontrollverhinderung für die Ausrüstung des industriellen Kontrollsystems (ICS) hinter dem Protokoll-Gateway anzuwenden. Dadurch wäre die Integrität des Befehls-, der Daten und des Kontrollprozesses in Gefahr. Bedrohungsakteure könnten über die Lücken Ingenieure daran hindern, Fabriken, Kraftwerke und andere kritische Einrichtungen zu steuern oder zu überwachen, sodass letztendlich die angegriffenen Anlagen wesentliche Leistungen wie Strom und Wasser nicht mehr liefern oder die Qualität und Sicherheit der Produkte einer Fabrik beeinträchtigt werden.

Anwendungsbereich und Auswirkungen

Das Forschungsprojekt ist für ein breites Fachpublikum konzipiert und beschränkt sich nicht lediglich auf die, die einen Betriebstechnik (OT)-Hintergrund haben. Auditoren und Berater können sich auch über die geschäftlichen Auswirkungen der damit verbundenen Schwachstellen und Angriffsszenarien informieren. Die Forschungsteilnehmer verwendeten das MITRE ATT&CK-Framework für industrielle Steuerungssysteme, um mögliche Angriffstechniken sowie die entsprechenden Auswirkungen darzustellen. Alle Einzelheiten liefert das Whitepaper „Lost in Translation: When Industrial Protocol Translation goes Wrong“.

Empfehlungen

Ausführliche Empfehlungen und eine Sicherheits-Checkliste sollen sicherstellen, dass die Verantwortlichen alle und Schwachstellen angehen können:

  • Beim Kauf der Geräte sollten die Design-Aspekte von Protokoll-Gateways, wie z.B. Unterschiede in den Filterfähigkeiten, berücksichtigt werden.
  • Fachgerechte Konfiguration und Absicherung des Gateways. Diese Geräte können in der Gesamtsicherheit einer Industrieanlage leicht übersehen werden.
  • Protokoll-Gateways sollten als kritische OT-Geräte behandelt werden, um einen besseren Rahmen für einen Sicherheitsplan für ihre Funktion zu schaffen und zu verhindern, dass sie bei den Verteidigungsmassnahmen übersehen werden.