Archiv der Kategorie: Hacking

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.

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.

Risiken und Massnahmen für die Anwendungssicherheit

Von Trend Micro

Anwendungen spielen heute eine integrale Rolle, und viele Unternehmen und Benutzer sind auf eine breite Palette von Anwendungen für Arbeit, Bildung, Unterhaltung, Einzelhandel und andere Zwecke angewiesen. Daher spielen Entwicklungsteams eine Schlüsselrolle, um sicherzustellen, dass Anwendungen den Benutzern eine hohe Benutzerfreundlichkeit und Leistung sowie Sicherheit vor Bedrohungsakteuren bieten, die immer auf der Suche nach Schwachstellen, Verwundbarkeiten, Fehlkonfigurationen und anderen Sicherheitslücken sind, die sie zur Durchführung böswilliger Aktivitäten missbrauchen können. Die Sicherheitsrisiken sind sogar noch ausgeprägter geworden, da die Unternehmen Anwendungen schnell auf den Markt bringen müssen, um ihre geschäftlichen und Umsatz generierenden Prozesse aufrechtzuerhalten.

Die schwerwiegenden Risiken, die von unsicheren Anwendungen ausgehen, verdeutlichen die Notwendigkeit der Anwendungssicherheit in der Design-, Entwicklungs- und Bereitstellung-Phase. Deswegen ist es nötig, die Sicherheitsrisiken und -bedrohungen zu erörtern, denen Anwendungen ausgesetzt sein könnten, sowie die Möglichkeiten für Organisationen angemessene Cybersicherheitsschutzmassnahmen in ihre DevOps-Pipeline zu integrieren.

Sicherheitsrisiken für Anwendungen

Die zunehmende Komplexität der Anwendungen und ihre Abhängigkeit von Drittbibliotheken machen sie u.a. anfällig für Sicherheitsbedrohungen. Ein Forrester-Bericht von 2020 stellt fest, dass die Mehrzahl der externen Angriffe durch Ausnutzung einer Software-Schwachstelle oder einer Web-Anwendung erfolgt. Der Bericht nennt Open-Source-Software als ein Hauptproblem für die Sicherheit von Anwendungen und verweist auf den 50%igen Anstieg von Open-Source-Sicherheitslücken seit dem letzten Jahr.

Auch die zunehmende Verbreitung von Containern und die erforderlichen APIs bringen zusätzliche Risiken. Ein 2020 Snyk Report stellt fest, dass neun von zehn der Top-10 offiziellen Container-Images mehr als 50 Schwachstellen umfassen. Ein F5 Report von 2019 fand heraus, dass API-Einbrüche entweder bedingt durch grosse Plattformen zustande kommen, die viele Drittanbieter-Integrationen enthalten, oder durch mobile Applikationen und infolge der Fehlkonfigurationen der Anwendungen.

Die Open Web Application Security Project (OWASP) Foundation stellt eine umfassende Liste der Risiken für Webanwendungen und APIs zur Verfügung. Es ist wichtig, dass sich die Entwickler der häufigsten Anwendungssicherheitsrisiken bewusst sind – in der Regel durch unsicheren Code entstanden – damit sie die Bereiche überprüfen können, die sie in jeder Phase der Entwicklungspipeline abdecken müssen. Dies sind die häufigsten Risiken für Anwendungen:

  • Einsatz von Komponenten mit bekannten Schwachstellen. Entwickler verwenden Komponenten wie Bibliotheken, Frameworks und andere Softwaremodule in ihren Anwendungen, um redundante Arbeit zu vermeiden und die benötigte Funktionalität bereitzustellen. Bedrohungsakteure wiederum suchen nach bekannten Schwachstellen in diesen Komponenten, um die Abwehr von Anwendungen zu untergraben und verschiedene Angriffe durchzuführen.
  • Daten-Lecks und Exponierung. Webanwendungen und APIs mit nur ungenügendem Schutz für sensible Daten könnten Bedrohungsakteuren böswillige Aktivitäten ermöglichen, wie Daten- oder Identitätsdiebstahl und Kreditkartenbetrug.
  • Schwache Zugangskontrolle zum Backend. Schwache Backend-Zugangskontrollen sind das Ergebnis unsachgemäss durchgesetzter Einschränkungen der für authentifizierte Benutzer erlaubten Aktionen. Bedrohungsakteure können diese Schwachstellen ausnutzen, um auf nicht autorisierte Funktionen zuzugreifen. Dazu gehören der Zugriff auf andere Benutzerkonten, die Anzeige sensibler Dateien, die Änderung anderer Benutzerdaten und die Änderung von Zugriffsrechten..
  • Injection. SQL, NoSQL, OS und LDAP sind für Einschleusungstaktiken anfällig, die für Angriffe missbraucht werden können, wenn nicht vertrauenswürdige Daten über eine Formulareingabe oder andere Datenübertragungsmethoden an einen Code-Interpreter gesendet werden. Bedrohungsakteure können „feindliche“ Daten verwenden, um den Interpreter dazu zu bringen, bösartige Befehle auszuführen oder nicht autorisierten Datenzugriff zu ermöglichen.
  • Sicherheitsfehlkonfiguration. Dies ist die häufigste Sorge hinsichtlich der Sicherheit von Webanwendungen. Diesbezügliche Probleme treten aufgrund unsicherer Standardkonfigurationen, falsch konfigurierter HTTP-Header, unvollständiger oder Ad-hoc-Konfigurationen, Open-Cloud-Speicher und zu wortreicher Fehlermeldungen auf, die sensible Informationen enthalten. Betriebssysteme, Bibliotheken, Frameworks und Anwendungen sollten aber auch rechtzeitig gepatcht werden.
  • Nicht korrekte Authentifizierung und Autorisierung. Wenn Anwendungsfunktionen hinsichtlich Authentifizierung und Session-Management nicht korrekt implementiert sind, können Bedrohungsakteure diese missbrauchen, um Passwörter und Schlüssel oder Session-Token zu kompromittieren. Sie können auch Benutzer- oder Administratorkonten kapern, über die ein ganzes System kompromittiert werden könnte.
  • Cross-Site Scripting XSS. Angreifer können XSS-Fehler dazu missbrauchen, Skripts in einem Browser auszuführen und Benutzer-Sessions zu kapern, Websites zu entstellen oder den Benutzer auf bösartige Websites umzuleiten. XSS-Fehler treten auf, wenn eine Anwendung nicht vertrauenswürdige Daten in eine neue Webseite einfügt ohne ordnungsgemäße Validierung. Sie können auch zustande kommen, wenn eine Anwendung eine bestehende Webseite mit vom Benutzer bereitgestellten Daten über ein HTML- oder JavaScript-erzeugendes Browser-API aktualisiert.
  • Unichere Deserialisierung. Dieser Fehler, d.h. die unsachgemässe Rückkonvertierung serialisierter Daten in Objekte, die von der Anwendung verwendet werden können, führt häufig zu Remote Code Execution (RCE). Dadurch können Bedrohungsakteure auch Replay-, Injection- und Privilegieneskalations-Angriffe durchführen.
  • Unzureichendes Logging und Monitoring. Beides unterstützt Angreifer dabei, Daten zu ändern, zu extrahieren oder zu vernichten sowie weitere Systeme zu attackieren, Persistenz aufrecht zu erhalten und weitere Systeme ins Visier zu nehmen.

Integration adäquater Sicherheitsebenen in die DevOps-Pipeline

Entwickler, die in traditionellen Entwicklungsteams arbeiten, tendieren dazu, Sicherheit erst im Nachhinein zu bedenken, weil sie sich zu sehr auf die Erstellung von Anwendungen und die Einhaltung von Terminen konzentrieren. Herkömmliche Prozesse führen zu unzureichender Sicherheit und Kommunikationslücken zwischen Entwicklungs- und Sicherheitsteams. Die Behebung von Schwachstellen, die in der Implementierungsphase aufgedeckt werden, kann zudem mehr als sechsmal so teuer sein wie die der in der Entwurfsphase festgestellten, so eine Untersuchung von IBM.

Entwicklungsteams sollten deshalb adäquate Cybersecurity Layer integrieren, die unter anderem Container, Source Code und Abhängigkeiten analysieren. Vor allem die folgenden Aufgaben sind wichtig:

  • Container Scanning. Container-Technologie bringt bei allen Vorteilen auch eine Vielfalt an potenziellen Risiken und Gefahren mit. Werkzeuge zur Analyse von Container-Images können Entwicklungsteams dabei helfen, in allen Phasen des Software-Entwicklungslebenszyklus (SDLC) nach bekannten Schwachstellen, geheimen Schlüsseln, Compliance-Checklisten und Malware-Varianten zu suchen. Solche Tools können Einsichten in die Sicherheitsbelange innerhalb des Containers liefern, bevor diese in die Produktionsumgebung übertragen werden. Um die Risiken weiter zu minimieren, sollte auch der Einsatz von nicht verifizierbarer Software von Drittanbietern reduziert werden, um sicherzustellen, dass keine Schadsoftware in die Container-Umgebung eindringt.
  • Analyse der Software-Zusammensetzung. Code-Blöcke, die möglicherweise von ausserhalb der Organisation stammen und im Allgemeinen während der statischen Analysephase nicht überprüft wurden, sind häufig in die DevOps-Umgebung integriert und werden dort ausgeführt. Mit Tools wie OWASP Dependency-Check lässt sich nach veralteten oder angreifbaren Bibliotheken im Code suchen. Snyk liefert ebenfalls kostenlose Drittanbieter-Verifizierung für quelloffene Projekte.
  • Statisches Application Security Testing (SAST). Auch als Security Code Review oder Code Auditing bekannt, unterstützt SAST Entwickler dabei, in einer frühen Phase Schwachstellen und andere Sicherheitsprobleme im Anwendungscode zu finden.
  • Dynamic Application Security Testing (DAST). DAST, auch Black-Box-Tests genannt, kann Sicherheitslücken und Schwachstellen in Anwendungen finden, und zwar durch den Einsatz von Fault Injection-Techniken wie SQL Injection, Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF). DAST-Lösungen können dazu beitragen, die Belastbarkeit von Anwendungen, Containern und Clustern zu testen, wenn sie bösartigen Techniken ausgesetzt sind.
  • Interactive Application Security Testing (IAST). IAST führt Laufzeittests für Webanwendungen durch, um Sicherheitslücken zu erkennen. Bereiche, die SAST und DAST möglicherweise nicht abdecken können, lassen sich durch IAST bearbeiten, da dieses Testen Elemente beider Ansätze kombiniert und dadurch mehr Code abdecken, genauere Ergebnisse liefern und eine breitere Palette von Sicherheitsregeln überprüfen kann. Die IAST-Lösungen führen ihre gesamte Analyse in der Anwendung in Echtzeit und überall in den folgenden Bereichen durch: Entwicklungsprozess IDE, QA, kontinuierliche integrierte Umgebung oder sogar in der Produktion.

Best Practices

Im Folgenden sind einige Best Practices über die gewährleistet werden kann, dass Anwendungen sicher entwickelt werden.

  • Anwenden des Prinzips der Least Privilege (PLOP). Diese Richtlinie begrenzt die Zugriffsrechte für Benutzer auf die Berechtigungen, die für die Erfüllung ihrer Aufgaben erforderlich sind, wodurch das Risiko des Kontomissbrauchs oder der Entführung von Konten und der Preisgabe sensibler Daten verringert wird.
  • Anwenden automatisierten Testens.  Die Zahl der Software-Schwachstellen hat sich seit 2017 erhöht. Deshalb ist automatisiertes Testen bereits früh im Entwicklungsprozess sehr wichtig, weil damit Fehler oder Lücken gefunden werden, solange sie noch einfach zu beheben sind.
  • Regelmässiges Scannen nach Schwachstellen. Entwickler verwenden häufig externe Bibliotheken oder Packages aus Open-Source-Projekten, wenn sie Software entwickeln. Diese Bibliotheken aber enthalten bekannte Schwachstellen. Um diese so früh wie möglich zu erkennen und  zu beheben, sollten sie regelmässig gescannt werden.
  • Einsatz von Runtime Application Self-Protection (RASP)-Lösungen. Diese Lösungen überwachen den Verkehr der Anwendungen, Container und serverlosen Architekturen, um Angriffe in Echtzeit zu erkennen. Der Einsatz von RASP-Lösungen ermöglicht das Abfangen aller Arten von Datenverkehr, einschliesslich solchen, der auf böswilliges Verhalten hinweist, wie SQL-Injection, Cross-Site-Scripting (XSS), Schwachstellen, Bots und andere Angriffe auf Webanwendungen.
  • Schulungen für funktionsübergreifende Teams bezüglich einer DevSecOps-Kultur. Die DevSecOps-Kultur sollte innerhalb der Organisationen gefördert werden. Dies kann durch die Bildung funktionsübergreifender Teams erreicht werden, die sich auf die Schulung von Entwicklern auf dem Gebiet der Sicherheitsdisziplin sowie auf die Schulung von Sicherheitsexperten zum Software-Entwicklungsprozess spezialisieren. Dadurch können Sicherheitsteams Programmiersprachen besser verstehen und mehr darüber erfahren, wie APIs zur Automatisierung einfacher Prozesse eingesetzt werden können. Solche Fertigkeiten reduzieren zudem letztlich ihre Arbeitsbelastung.
  • Einbeziehen der Anwendungssicherheit in die Datenschutz-Compliance-Strategie. Anwendungssicherheit ist Teil der allgemeinen Bestrebungen einer Organisation, Datenschutzbestimmungen und IT-Standards einzuhalten. Unternehmen können eine effiziente Compliance-Strategie anwenden, die dem „Privacy by Design“-Ansatz folgt. Beispielsweise schliesst eine  adäquate Compliance-Strategie für die Europäische Datenschutz-Grundverordnung (DSGVO) die Durchführung von Vertraulichkeits- und Sicherheitsüberprüfungen mit ein, über die Implementierung von Identitäts- und Authentifizierungs-Massnahmen sowie geeignete Zugangskontrollen, Datenschutz über PLOP und Verschlüsselung u.a.

Regelmässiges Scannen und der Einsatz von fortschrittlichen Sicherheits-Tools, um Malware, Schwachstellen und andere Bedrohungen zu erkennen, ist von entscheidender Bedeutung. Ebenso müssen Unternehmen Richtlinien einführen, die eine strenge Sicherheitskultur ermöglichen.

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:

Pwn2Own Tokio im Herbst – diesmal live aus Toronto

Originalbeitrag von Brian Gorenc

Während der letzten Jahre fand die Herbstveranstaltung des Pwn2Own-Wettbewerbs immer im Rahmen der PacSec Applied Security Conference in Tokio statt. Da in diesem Jahr die Konferenz nur virtuell abgehalten wird, musste auch die ZDI einen Weg finden, die Pwn2Own wie schon im Frühjahr in den virtuellen Raum zu verschieben. Das Problem dabei bestand darin, dass sich die Herbstveranstaltung auf Geräte wie Mobiltelefone, Fernseher, smarte Lautsprecher und drahtlose Router konzentriert – also physische Geräte, deren Hacking virtuell schwierig ist. Dennoch gelang es den Mitarbeitern der ZDI, ein perfektes Setting für den Wettbewerb aufzustellen, sodass das Event vom 3. – 5. November live aus Toronto kommt und zwar gleichzeitig mit der virtuellen PacSec-Konferenz (1. – 6. November). Als Hacking-Ziele stehen 20 Geräte zur Verfügung und mehr als 500.000 US-Dollar als Preisgeld.

Wie schon bei der Frühjahrsveranstaltung des Pwn2Own ist die Remote-Teilnahme wieder möglich, wenn Teilnehmer Reiserestriktionen unterworfen sind, oder Sicherheitsgründe die Präsenz verhindern. Diese Teilnehmer müssen sich trotzdem bis zum 29. Oktober registrieren und ein ausführliches Whitepaper einreichen, in dem sie den kompletten Exploit-Ablauf erklären und Anleitungen für die Ausführung geben. Ein Mitarbeiter der ZDI wird den Exploit durchführen, der gefilmt wird und dem Teilnehmer sowie dem Anbieter zur Verfügung steht. Auf Wunsch arbeitet der ZDI-Mitarbeiter mit Remote-Teilnehmern zusammen, um den Hacking-Versuch in Echtzeit per Telefonanruf oder Videochat zu überwachen. Es gilt zu beachten, dass Änderungen an Exploits/Skripts/etc. nicht möglich sind, was die Gewinnchancen im Falle eines unerwarteten Ereignisses verringern könnte. Ansonsten läuft der Wettbewerb so ab, als ob er in Tokio stattfinden würde. Wer Fragen dazu hat, kann über zdi@trendmicro.com Kontakt aufnehmen.

Facebook kehrt als Partner für die diesjährige Veranstaltung zurück und bietet erneut Oculus Quest und Portal von Facebook-Geräten als Ziele an. Niemand hatte die Geräte während ihrer Eröffnungsshow ins Visier genommen, daher wird es interessant sein zu sehen, ob sich das diesmal ändert. Die Teilnahme von Anbietern bleibt eine Schlüsselkomponente für den Erfolg dieser Wettbewerbe. Wie auch bei den anderen Pwn2Own-Wettbewerben versucht Pwn2Own Tokyo (Live aus Toronto), diese verbraucherorientierten Geräte und ihre Betriebssysteme zu härten, indem Schwachstellen aufgedeckt werden, die dann den Herstellern zur Kenntnis gebracht werden. Wie immer ist es das Ziel, diese Fehler zu beheben, bevor sie aktiv ausgenutzt werden.

Zu den angebotenen Hacking-Zielen gehören unter anderem Mobiltelefone (Google Pixel 4, Samsung Galaxy S20, Apple iPhone 11, Huawei P40 sowie Xiaomi Mi 10), Wearables, drahtlose Router und Fernseher. In diesem Jahr sind Network Attached Storage (NAS)-Server hinzugekommen. Die komplette Liste der Geräte beinhaltet der Originalbeitrag. Der Wettbewerb wird wieder in verschiedenen Kategorien ausgetragen, und es wird auch wieder einen Master of Pwn geben. Alle Einzelheiten zum Pwn2Own Tokyo 2020 liefert die ZDI.

Das Rennen: Hase und Igel in der IT-Security

Von Richard Werner, Business Consultant bei Trend Micro

Quelle: Wikimedia Commons

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

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

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

Merke: Wir befinden uns in einem Rennen!

Rollenverteilung

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

Merke: Unsere Rolle ist die des Hasen!

Wege aus der Situation

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

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

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

Umdenken in der IT-Security

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

Die Lehre

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

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

Infrastructure as Code: Sicherheitsrisiken kennen und vermeiden

Originalbeitrag von David Fiser (Cyber Threat Researcher)

Ständig steigende Anforderungen an IT-Infrastrukturen und die Zunahme von Continuous Integration and Continuous Deployment (CI/CD)-Pipelines haben den Bedarf an konsistenter und skalierbarer Automatisierung erhöht. Hier bietet sich Infrastruktur als Code (IaC) an. IaC liefert die Bereitstellung, Konfiguration und Verwaltung der Infrastruktur durch formatierte, maschinenlesbare Dateien. Anstelle der manuellen Einrichtung von Onpremise- und Cloud-Umgebungen können Administratoren und Architekten diese einfach mit IaC automatisieren. IaC arbeitet gut mit Infrastructure as a Service (IaaS) zusammen und besticht durch die schnellere und kostengünstigere Entwicklung und Bereitzustellung von skalierbaren Cloud-Implementierungen.

Das IaC-Konzept weist Ähnlichkeiten mit Programmierskripts auf (die ebenfalls IT-Prozesse automatisieren), doch verwendet IaC eine beschreibende Sprache für die Kodierung von anpassungsfähigeren Bereitstellungen und Implementierungen (d.h. die Software selbst ist für die Einleitung von Infrastrukturänderungen verantwortlich). IaC gilt als besonders wichtig für Cloud Computing und DevOps.

Es gibt zwei Arten von IaC-Werkzeugen: Orchestrierungswerkzeuge dienen der Bereitstellung, Organisation und Verwaltung von Infrastrukturkomponenten (z.B. CloudFormation und Terraform). Konfigurationsmanagement-Tools wiederum ermöglichen die Installation, Aktualisierung und Verwaltung laufender Software in Infrastrukturkomponenten (z. B. Ansible, Chef, Puppet und SaltStack). Diese Tools entheben Entwickler und Cloud-Architekten von manuellen, fehleranfälligen Aufgaben und vereinfachen die Konfiguration und Verwaltung.

Sicherheitsrisikobereiche in IaC-Implementierungen

Zu den Herausforderungen, die IaC mit sich bringt, zählen etwa ungepatchte Schwachstellen in einem IaC-Tool als Eintrittspunkt für Bedrohungen in die Kerninfrastruktur. Schwachstellen könnten es Angreifern ermöglichen, Verfahren zu umgehen, Code auf gehackten Servern auszuführen oder sogar Kryptowährungs-Miner einzusetzen. IaC-Templates mit Fehlkonfigurationen könnten auch sensible Daten offen legen oder Schlupflöcher für Angriffe öffnen.

Speicherung von sensiblen Daten

Das allgemeine IaC-Prinzip sieht vor, dass eine einzige Anwendung mehrere in den Konfigurationsdateien beschriebene Umgebungen verwalten kann, die als Code vorliegen und den Code (auch bösartig) auch innerhalb der Zielumgebungen ausführen. Eine IaC-Anwendung kann verschiedene Ansätze zur Beschreibung der Zielumgebung verwenden; das Gemeinsame ist die Konfiguration selbst, ihre Speicherung und insbesondere die geheimen Informationen, die für die Verbindung mit der verwalteten Infrastruktur erforderlich sind.

Die Speicherung von solchen Informationen ist wichtig, weil es um sensible Daten geht, wie etwa Anwendungs-Token für die Authentifizierung, Secure Shell (SSH)-Schlüssel und Passwörter. Die Speicherung dieser Daten in Storing Source Code Management (SCM)-Systemen (z.B. Git) oder Klartextdateien ist eine gefährliche – und aus Sicherheitssicht unverantwortliche – Praxis, da sie leicht zugänglich gemacht werden können. Beispielsweise könnten Bots, die öffentliche SCM-Sites durchforsten und nach sensiblen Informtionen suchen, diese schnell ausnutzen und die Infrastruktur gefährden (z.B. durch das Ausbringen von Kryptowährungs-Minern). Es empfiehlt sich daher, Vaults für die Speicherung von Geheimnissen zu verwenden und diese in den Konfigurationsdateien zu referenzieren.

Kommunikationskanal des Masters

Einige IaC-Konfigurationsmanagement-Tools (z. B. SaltStack) verwenden eine Master-Node-Architektur, bei der die Knoten von einem Master-Knoten aus verwaltet werden. Beim Zugriff auf eine verwaltete Infrastruktur von einem einzigen Punkt aus (d.h. von einem Master) ist es im Allgemeinen entscheidend, diesen einzelnen Punkt zu sichern, da er die gesamten Infrastruktur- oder Einsatzspezifikationen enthält und die Kompromittierung der Sicherheit die gesamte Infrastruktur gefährden würde.

Die Verwendung entsprechend vorbereiteter Umgebungen innerhalb der Cloud reduziert das Risiko von Kompromittierungen durch Fehlkonfigurationen und das Risiko, Infrastrukturen von Grund auf neu zu konfigurieren.

Bild 1. Ein Überblick über eine Master-Node-Architektur

Der Master muss über einen sicheren Kommunikationskanal verfügen, um mit den Knoten zu kommunizieren und sie steuern zu können. Es gibt zwei verschiedene Ansätze für das Management:

  • Installation eines benutzerdefinierten Agenten für das Management des Knotens, der bestimmte Aufgaben ausführt,
  • Einsatz allgemein verfügbarer Software und Kommunikationsprotokolle für das Management von Knoten (auch als „agentenlos“ bekannt), so etwa Bash-Skriptausführung via SSH-Protokoll.

Vom Standpunkt der Sicherheit stellt die Verwendung eines benutzerdefinierten Netzwerkprotokolls eine weitere Angriffsfläche dar. Möglicherweise rücken sogar mögliche Schwachstellen in den Vordergrund, wie im Fall von CVE-2020-11651 und CVE-2020-11652, Schwachstellen im Salt-Management-Framework von SaltStack, das in Rechenzentren und Cloud-Servern eingesetzt wird.

Bei Missbrauch von CVE-2020-11651 könnte ein nicht authentifizierter Nutzer aus der Ferne Code in der ganzen Infrastruktur ausführen. Die Path Traversal Vulnerability CVE-2020-11652 wiederum ermöglicht es Dritten, beliebige Dateien zu lesen. In beiden Fällen können Böswillige sich den Root-Schlüssel verschaffen und Zugang zum Master erlangen und damit zur gesamten Infrastruktur. Einzelheiten dazu liefert auch ein Trend Micro-Forschungsbeitrag.

Benutzerprivilegien

Benutzerprivilegien sind ein weiterer sicherheitsrelevanter Aspekt. Wird eine IaC-Anwendung zur Verwaltung der Anwendungsbereitstellung genutzt, ist es unwahrscheinlich, dass dafür Root-Rechte auf dem Zielrechner erforderlich sind. Das Prinzip der geringsten Privilegien sollte hier das Risiko einer Kompromittierung mindern.

Dasselbe Prinzip gilt auch für den Einsatz innerhalb öffentlicher Clouds wie Amazon Web Services (AWS). Wird ein Account oder eine Rolle nur für einen bestimmten Zweck zugewiesen (z.B. das Erstellen virtueller Maschinen), sollte diese mit eingeschränkten Fähigkeiten verwendet werden. Die Weitergabe von Zugangsdaten von Cloud-Providern mit Administrator-Zugriff für weniger privilegierte Aufgaben ist eine unsichere Praxis.

IaC-Templates

IaC-Templates sind für die agile Bereitstellung über Provisioning und die Verwaltung der Cloud-Infrastruktur wichtig. Es sind maschinenlesbare Definitionsdateien, mit deren Hilfe die Umgebungen aufgebaut werden, in denen Code aus externen Quellen bereitgestellt und ausgeführt wird. Sie sind jedoch nicht ohne Risiken. Diese Templates sind Teil von IaC-Prozessen und könnten unbeabsichtigt Betriebssystem- oder Container-Images aus nicht vertrauenswürdigen Quellen verwenden, die dann Bedrohungen wie Backdoors und Kryptowährungs-Miner Tür und Tor öffnen.

IaC-Vorlagen beinhalten möglicherweise auch Schwachstellen und unsichere Standardkonfigurationen, die zu einer Gefährdung von Daten führen. Betreiber sollten deshalb IaC-Vorlagen zu Beginn des Entwicklungsprozesses zunächst auf unsichere Konfigurationen und andere potenzielle Schwachstellen überprüfen. Regelmässiges Scannen mit Hilfe eines Cloud Security Posture Management Service hilft ebenfalls, Fehlkonfigurationen zu erkennen und zu beheben.

Lehren ziehen, Best Practices anwenden

IaC gehört zu den wichtigsten DevOps-Praktiken für die agile Softwareentwicklung. Mit IaC wird die Infrastruktur innerhalb von Textdateien (Code) definiert. Fehlkonfigurationen stellen eines der grössten Sicherheitsprobleme in Cloud-Umgebungen dar.

Die folgenden Empfehlungen helfen beim Absichern von hybriden und öffentlichen Cloud-Umgebungen:

  • Durchsetzen des Prinzips der geringsten Privilegien. Account-Privilegien in Cloud-Services sollten eingeschränkt werden, vor allem wenn sie an öffentliche Cloud-Provider gebunden sind. Die Berechtigungen und der Zugang zu Tools sollten eingeschränkt werden, um zu verhindern, dass Angreifer in den Knoten Fuss fassen können. Auf diese Weise werden IaC-Konfigurationen sicher gespeichert und Datenverluste verhindert.
  • Einsatz von IaC Sicherheits-Plugins. Diese Plugins in integrierten Entwicklungsumgebungen können mögliche Probleme in IaC-Templates vor der Installation verhindern.
  • Update der Infrastruktursoftware auf die neueste Version. Sicherheits-Patches sollten immer sofort aufgespielt werden.
  • Nie ein zentrales System exponieren. Zentrale Server sollten nie im Internet exponiert sein, um so zu verhindern, dass eine mögliche Kompromittierung auf weitere Komponenten übergeht.
  • Haltung zur Sicherheit und Compliance verbessern.  Um den Schutz in der Pipeline zu gewährleisten, sollte Echtzeit-Sicherheit, die Fehlkonfigurationen bei Anbietern von Cloud-Diensten erkennt, eingesetzt werden. Lösungen, die über eine automatische Korrekturfunktion verfügen, können auch bei der Behebung von Ausfällen helfen.

Weitere Empfehlungen zur Sicherheit der IAC-Pipeline gibt es hier.

Cloud Sicherheitslösungen von Trend Micro

Trend Micros Lösung Hybrid Cloud Security unterstützt die DevOps Pipeline mit mehreren XGen Threat Defense-Techniken und kann physische, virtuelle und Cloud-Workloads zur Laufzeit schützen. Trend Micro™ Cloud One™ – Conformity ist ein Cloud Security and Compliance Posture Management Service, der automatisierte Sicherheits- und Compliance-Überprüfungen bietet, sowie Übersicht und einfaches Reporting.

Für Unternehmen, die Sicherheit als Software für Runtime-Workloads, Container-Images sowie Datei- und Objektspeicher suchen, können Deep Security™ und Deep Security Smart Check Workloads und Container-Images in jedem beliebigen Intervall in der Entwicklungs-Pipeline auf Malware und Schwachstellen überprüfen.

Weitere Informationen finden Interessierte im Originalbeitrag.

Im Kreuzfeuer: Verteidigung der Geräte in der Schlacht der Botnets

Von Trend Micro

Botnets, diese Netzwerke aus infizierten Geräten (in Bots verwandelt), sind umso erfolgreicher in ihren Angriffen und bösartigen Aktivitäten, je höher die Zahl der Bots ist. Mit der Verbreitung des Internet of Things (IoT) ist eine neue Domäne entstanden, in der die Betreiber der Botnets um Bots kämpfen. Dieser so genannte „Wurmkrieg“ wird von den Benutzern unbemerkt geführt, und die können die Kontrolle über ihre Geräte verlieren, egal welcher Cyberkriminelle am Ende eine Schlacht gewinnt. Die Nutzer müssen die Techniken und Taktiken verstehen, die beim Aufbau von Botnets und der Umwandlung gängiger IoT-Geräte wie Router in Bots zum Einsatz kommen. Trend Micro hat einen Forschungsbericht „Worm War: The Botnet Battle for IoT Territory“ veröffentlicht, in dem die Welt der IoT-Botnets eingehend dargestellt wird.

Der Blog gibt eine Vorschau auf die Hauptfunktionen von Botnet-Malware anhand der drei Quellcodebasen von Botnets, die den Weg für viele Botnet-Malware-Varianten geebnet haben und die Grundlage für den anhaltenden Revierkampf bilden.

Kaiten

Kaiten, auch als Tsunami bekannt, ist die älteste der drei. Die Kommunikation mit den Command-and-Control (C&C)-Servern basiert auf dem IRC-Protokoll (Internet Relay Chat), wobei infizierte Geräte Befehle von einem IRC-Kanal empfangen. Das Skript von Kaiten ermöglicht es der Malware auch, auf mehreren Hardware-Architekturen zu arbeiten, und damit wird sie ein relativ vielseitiges Werkzeug für Cyberkriminelle. Darüber hinaus können neuere Varianten konkurrierende Malware ausschalten und somit ein Gerät vollständig in Beschlag nehmen.

Qbot

Die Malware ist auch als Bashlite, Gafgyt, Lizkebab oder Torlus bekannt und stellt eine relativ alte Familie dar. Dennoch ist sie für Botnet-Entwickler immer noch wichtig. Bemerkenswert im Zusammenhang mit Qbot ist die Tatsache, dass deren Quellcode aus nur ein paar Dateien besteht. Anfänger haben Schwierigkeiten in der Handhabung, deshalb gibt es in cyberkriminellen Foren viele Tutorials und Leitfäden dazu. Qbots Quellcode kann ebenso wie Kaiten mehrere Architekturen unterstützen, doch die Kommunikation mit den C&C-Servern basiert auf TCP und nicht IRC. Neuere Varianten können zudem auch rivalisierende Malware killen.

Mirai

Mirai ist die jüngste Malware unter den dreien. Dennoch ist sie sehr bekannt, weil die Familie zahlreiche Varianten hervorgebracht hat. Sie wurde darauf zugeschnitten, als Distributed Denial-of-Service (DDoS)-Tool angeboten zu werden. Nach Veröffentlichung des Quellcodes wurde Mirai zu einem Wendepunkt für IoT-Malware. Die Botnet-Malware machte sich schnell einen Namen durch den Angriff auf Dyn, einen DNS-Hosting-Provider (Domain Name System), der zur Beeinträchtigung weit verbreiteter Websites und Dienste führte.

Botnet-Kampftaktiken

Kaiten, Qbot und Mirai präsentieren die Fähigkeiten, mit denen Botnet-Malware um die Vorherrschaft über angeschlossene Geräte konkurrieren kann. Um ein Botnet zu entwickeln und seine Grösse aufrechtzuerhalten, müssen Botnet-Malware-Familien und -Varianten in der Lage sein, so viele Geräte wie möglich zu infizieren und gleichzeitig andere Angreifer fernzuhalten. Botnet-Malware kann nach anfälligen Geräten suchen und bekannte Taktiken wie Brute-Force anwenden, um die Kontrolle über ein Gerät zu erlangen. Um die Übernahme zu festigen, eliminiert Botnet-Malware konkurrierende Malware, die möglicherweise bereits auf dem Gerät vorhanden ist, sowie neue Schadsoftware, die darauf abzielen könnte, die Kontrolle über das Gerät zu stehlen.

Alle drei Bot-Quellcodebasen verfügen über diese Fähigkeiten. Und da sie quelloffen sind, ermöglichen sie es böswilligen Akteuren, die Bedrohungslandschaft weiterhin mit konkurrierenden Varianten zu bevölkern.

Bild. Zusammenfassung der drei wichtigsten IoT-Bot-Quellcodebasen

Verteidigung gegen IoT-Botnets

Über welch machtvolle Gerätearmeen Botnets verfügen können, zeigte der berüchtigte Mirai-Angriff 2016, der zum Absturz bekannter Websites führte (etwa Netflix, Twitter und Reddit) und auch den bekannten Sicherheitsblogs „Krebs on Security“ lahmlegte. In kleinerem Rahmen vereinnahmen Botnets IoT-Geräte und -Ressourcen einzelner Nutzer, die ihnen das Leben bequemer und ihre Arbeit leichter machen sollen. Diese Geräte haben an Bedeutung gewonnen, vor allem in einer Zeit, in der das Arbeiten von zu Hause aus zur neuen Norm für Organisationen geworden ist.

Die beste Verteidigungsstrategie gegen feindliche Botnets besteht darin, ihr Schlachtfeld einzugrenzen und Cyberkriminellen die Ressourcen zu verweigern, die ihre Botnets mächtig machen würden. Benutzer können ihren Teil dazu beitragen, indem sie dafür sorgen, dass ihre IoT-Geräte sicher sind. Sie können damit beginnen, diese Schritte zu befolgen:

  • Verwalten von Schwachstellen und Aufspielen der Patches so schnell wie möglich. Schwachstellen sind die wichtigste Art und Weise, wie Malware Geräte infiziert. Die Anwendung von Patches, sobald sie veröffentlicht werden, kann die Chancen für potenzielle Angriffe einschränken.
  • Anwenden sicherer Einstellung. Benutzer müssen sicherstellen, dass sie die sicherste Konfiguration für ihre Geräte verwenden, um die Möglichkeiten für eine Kompromittierung einzuschränken.
  • Starke, schwer zu erratende Passwörter aufsetzen. Botnet-Malware nutzt schwache und gängige Passwörter aus, um Geräte zu übernehmen. Benutzer können diese Taktik umgehen, indem sie Standardpasswörter ändern und starke Passwörter verwenden.

Weitere Einzelheiten zu den IoT-Botnets finden Sie im Whitepaper Worm War: The Botnet Battle for IoT Territory.

Bösartige Chrome Extensions und Domänen führen zum Datendiebstahl

Google Chrome Extensions und Communigal Communication Ltd. (Galcomm)-Domänen sind in einer Kampagne ausgenutzt worden, die darauf abzielt, Aktivitäten und Daten der Nutzer zu tracken. Awake Security hatte in den letzten drei Monaten 111 bösartige oder gefälschte Chrome Extensions gefunden, die Galcomm-Domänen als Command-&-Control (C&C)-Infrastruktur einsetzen. Es gab mindestens 32 Millionen Downloads dieser bösartigen Extensions. Die Kampagne nutzte nahezu 15.160 auf Galcomm registrierte Domänen, um Malware und Browser-gestützte Überwachungs-Tools zu hosten. Das sind nahezu 60% der bei diesem Registrar erreichbaren Domänen. Galcomm versichert, darin nicht verwickelt zu sein. Die Angriffe vermieden erfolgreich die Entdeckung durch Sandboxen, Endpoint-Sicherheitslösungen, Domain-Reputationsdienste und andere. Betroffen waren die Finanzbranche, Öl und Gas, Medien, Einzelhandel, Bildung und Behörden.

Trend Micro berichtete bereits über diese Chrome Extensions als Teil des Ökosystems dieser Kampagne. Die Sicherheitsforscher fanden auch bösartige Extensions, die Firefox-Nutzer im Visier hatten. Der Bericht hob hervor, dass einige Code von entfernten Servern laden können, sowie dass Calcomm möglicherweise einen Bezug zum Angriff habe. Awake Security veröffentlichte zudem eine ausführliche Liste mit den verwendeten App IDs. Weitere Einzelheiten beinhaltet der Originalbeitrag.

Empfehlungen

Bösartige Extensions werden immer bedrohlicher. Im Laufe der Zeit kommen weitere Verschleierungstechniken hinzu, wie die Umgehung traditioneller Sicherheitsmechanismen und das Laden von Code von entfernten Servern. Neben der Konzentration auf die Erkennung sollten Organisationen die von diesen Bedrohungen angewandten Taktiken, Techniken und Verfahren langfristig überwachen, um ein besseres Verständnis ihres Verhaltens zu erhalten und Erkenntnisse darüber zu gewinnen, wie Eintrittspunkte gegen sie verteidigt werden können.

Trend Micro XDR kann ein System schützen, indem Daten aus Emails, Enpoints, Servern, Cloud Workloads und Netzwerken gesammelt und korreliert werden. Dabei kommt KI und Sicherheitsanalysen zum Einsatz, die nicht nur eine frühe Erkennung ermöglichen, sondern auch tiefgehende Einsichten in die Quelle und das Verhalten dieser Angriffe bieten.

Trend Micro™ Managed XDR-Service liefert fachmännisches Monitoring und Analysen durch die erfahrenen Managed Detection and Response-Analysten. Die Experten können ein vollständiges Bild des Angriffs und seiner Ausbreitung im Unternehmen erstellen und so einen klaren Überblick über Ursache und Auswirkungen einer Bedrohung geben.

ISO/SAE 21434: Cyberbedrohungen für vernetzte Autos ausbremsen

Originalartikel von William Malik, CISA VP Infrastructure Strategies

Vernetzte Fahrzeuge sind die Zukunft. Weltweit soll ihre Zahl von 2018 bis 2022 um 270% zulegen, und in ein paar Jahren geschätzte 125 Millionen erreichen. Diese Fahrzeuge ähneln zunehmend eher Hochleistungscomputern mit Rädern als herkömmlichen Autos und beinhalten Fähigkeiten wie Internetzugang, applikationsbasiertes Remote Monitoring und Verwaltung, fortschrittliche Fahrerunterstützung und autonome Fahrfähigkeiten. Dadurch sind sie aber auch dem Diebstahl sensibler Daten und der Fernmanipulation ausgesetzt, was zu ernsthaften physischen Sicherheitsproblemen führen könnte. Ein neuer Forschungsbericht von Trend Micro stellt dar, was die Branchenbeteiligten tun müssen, damit die Cybersecurity-Lücke für das gesamte Automotive-Ökosystem geschlossen wird. Ein neuer Standard liefert Leitlinien für die Cybersicherheit.

Download

Moderne Automobile leisten weit mehr, als nur ihre Insassen von A nach B zu transportieren. Sie sind vollgepackt mit Rechenleistung, Sensoren, Infotainment-Systemen und Konnektivität, um das Fahrerlebnis, die Verkehrssicherheit, die Fahrzeugwartung und vieles mehr zu verbessern. Unter anderem verfügen sie über Systeme, die eine Verbindung zu anderen Fahrzeugen, mobilen Geräten, Verkehrsinfrastrukturen und Cloud-Systemen für verschiedene Zwecke herstellen, wie Sicherheitsüberwachung des Verkehrs und Fußgänger, Remote Monitoring und Verwaltung der Fahrzeuge oder Notfall-Benachrichtigungssysteme. All dies schafft eine Komplexität, die wiederum zu neuen Cyber-Sicherheitslücken führt.

Zum Beispiel gibt es heute in vielen modernen Fahrzeugen mehr als 100 Motorsteuergeräte (Engine Control Units, ECUs), vollgepackt mit Software, die alles vom Motor über die Aufhängung bis hin zu den Bremsen kontrolliert. Kapert ein Angreifer die Ausführung eines beliebigen Steuergeräts, könnte er sich lateral auf ein beliebiges Ziel im Fahrzeug zubewegen und damit möglicherweise aus der Ferne lebensbedrohliche Unfälle verursachen.

Der Bericht zeigt die drei grundlegenden Probleme auf, die die Sicherheit von vernetzten Autos zur Herausforderung werden lässt:

  • Schwachstellen: Die Branche arbeitet mit einem stark gegliederten Supply Chain-System. Wenn eine Schwachstelle in einer Komponente entdeckt wird, müssen alle beteiligten Ebenen einen Fix veröffentlichen, bis er den Originalausrüstungshersteller (OEM) erreicht. Diese Fehlerbehebungen müssen auch auf Interoperabilität geprüft werden, was bedeutet, dass die Firmware aller Steuergeräte aktualisiert werden müsste. Dies führt nicht nur zu Verzögerungen bei der Bereitstellung von Updates, sondern ein Software-Update für ein Fahrzeug kann auch bis zu 20 Stunden dauern.
  • Protokolle: Einige der Protokolle, die für ECU-Verbindungen verwendet werden, sind nicht für Cybersicherheitsfunktionen ausgelegt. Beispielsweise sind die Datenübertragungen nicht verschlüsselt, und Sender und Empfänger sind nicht authentifiziert.
  • Unsichere Produkte und Dienstleistungen auf dem Sekundärmarkt: Internet of Vehicles (IoV)-Geräte, die in Autos installiert sind, wie z.B. Bluetooth- oder Wi-Fi-fähige Multimediageräte, sind einfach erhältlich. Die meisten dieser Geräte laufen jedoch mit ungesicherter oder veralteter Firmware, sodass Angreifer die nicht gepatchten Systeme zum Eindringen ausnutzen und sich lateral bewegen können, um bösartigen Code an die Systeme des Fahrzeugs zu senden.
    Darüber hinaus können einige inoffizielle Werkstätten die ECU modifizieren, um die Motorleistung zu erhöhen. Die Manipulation der Software – trotz der vorhandenen Industriestandardverfahren zum Schutz der Diagnosesoftware – kann eine Reihe von Schwachstellen während und nach der Änderung der Codes entstehen lassen.

Diese Schwachstellen wurden bereits vor Jahren in Forschungsarbeiten aufgezeigt, doch nun da die Zahl der vernetzten Fahrzeuge zunimmt, zeichnen sich nun Angriffe aus der realen Welt ab. Die Angriffsszenarien zielen auf alles, von Benutzeranwendungen über Netzwerkprotokolle bis hin zum CAN-Bus, der On-Board-Software und mehr.

Standards als Abhilfe

Intelligente Transportsysteme (ITS) erfordern eine Abstimmung zwischen den Herstellern, um in der realen Welt eine Chance auf Erfolg zu haben. Kein grosser Autohersteller, multimodaler Anbieter oder MaaS-Anbieter (Mobility as a Service) wird es riskieren, in eine Lösung eines einzigen Anbieters zu investieren. Erfolgreiche ITS erfordern interoperable Komponenten, insbesondere für das Management von Fragen der Cybersicherheit.

Hier setzt ein neuer Standard an. ISO/SAE 21434 Road vehicles – Cybersecurity engineering ist ein langes und detailliertes Dokument zur Verbesserung der automobilen Cybersicherheit und Risikominderung in der gesamten Supply Chain – vom Fahrzeugdesign und -Engineering bis hin zur Stilllegung.

Als langjähriger Mitstreiter in der Automobilindustrie begrüsst Trend Micro den neuen Standard als eine Möglichkeit, Security-by-Design in einem Bereich zu verbessern, der zunehmend von Angreifern unter die Lupe genommen wird. Tatsächlich haben acht der zehn weltweit führenden Automobilunternehmen Lösungen von Trend Micro für ihre Unternehmens-IT übernommen.

Um ISO/SAE 21434 zu folgen und die vernetzten Autos zu schützen, benötigen Organisationen eine umfassende Visibilität und Kontrolle über das gesamte vernetzte Auto-Ökosystem, einschliesslich Fahrzeug-, Netzwerk- und Backend-Systeme. Unernehmen sollten auch die Schaffung eines Vehicle Security Operations Center (VSOC) in Erwägung ziehen, um die aus allen drei Bereichen eingehenden Benachrichtigungen zu verwalten und einen Überblick über das gesamte Ökosystem aus der Vogelperspektive zu erhalten.

Empfehlungen

In jedem dieser Schlüsselbereiche sollten die folgenden Fähigkeiten in Betracht gezogen werden:

Fahrzeug: Erkennung fahrzeuginterner Schwachstellen und deren mögliche Ausnutzung, einschliesslich der Schwachstellen in kritischen Geräten, die das fahrzeuginterne Netzwerk mit externen Netzwerken verbinden, z.B. fahrzeuginterne Infotainment-Systeme (IVI) und telematische Steuereinheiten (TCUs).

Netzwerk: Anwendung von Netzwerksicherheitsrichtlinien, Überwachung des Datenverkehrs, um Bedrohungen zu erkennen und zu verhindern, einschliesslich Verbindungen zwischen Fahrzeug- und Backend-Cloud und Datenzentren.

Backend: Sichern der Rechenzentren, Cloud und Container vor bekannten und unbekannten Bedrohungen und Bugs, ohne die Leistung zu beeinträchtigen.

Fahrzeug-SOC: Schnelle und effektive Massnahmen ergreifen durch Korrelation der am Endpunkt, Netzwerk und Backend erkannten Bedrohungen mit individuellen Benachrichtigungen von jedem einzelnen Punkt, so dass umfassende Elemente aus der Vogelperspektive betrachtet werden können.

In unsicheren Zeiten für die Branche zahlt es sich aus, allen möglichen Änderungen in den lokalen Gesetzen, die durch die neue ISO/SAE-Norm kommen könnten, einen Schritt voraus zu sein.

Incident Response Playbook: Schnell und gezielt reagieren ist entscheidend

von Trend Micro

Um heutzutage wettbewerbsfähig zu sein, müssen Unternehmen mit den neuesten technologischen Trends Schritt halten. Ohne die parallele Entwicklung einer Sicherheitsinfrastruktur und einem klaren Prozess für eine Reaktion auf Angriffe könnten diese Technologien jedoch zum fatalen Vektor für Cyber-Bedrohungen werden. Im Falle eines Cyberangriffs kann ein starker Incident Response-Plan ein Unternehmen mit nur minimalem Schaden wieder zum Laufen bringen. Ein gutes Playbook stellt eine große Hilfe beim Aufsetzen des Incident Response-Ablaufs dar.

Laut einer von IBM und Ponemon durchgeführten Studie kostet ein Datendiebstahl das betroffene Unternehmen durchschnittlich 3,92 Millionen Dollar. Diese Kosten können variieren, je nachdem, wie schnell ein Unternehmen einen Datendiebstahl entdeckt und darauf reagiert.

Der 2020 Data Breach Investigations Report von Verizon kam zu dem Ergebnis, dass die meisten Datenschutzverletzungen im Jahr 2019 zwar nur Tage oder weniger dauerten, doch immerhin ein Viertel der Fälle zog sich über Monate oder länger hin. Die Eindämmung wiederum brauchte im Durchschnitt etwa gleich lang.

Insgesamt zeigen die Zahlen im Bericht im Vergleich zu den Vorjahren eine Verbesserung bei der Aufdeckung von Dateneinbrüchen und der Reaktion darauf. Der Bericht weist aber auch darauf hin, dass diese Verbesserung darauf zurückzuführen sein könnte, dass mehr von Managed Security Service Providern (MSSPs) entdeckte Verletzungen in ihre Untersuchungen einbezogen wurden.

Organisationen sollten natürlich danach streben, die Einbrüche zu verhindern. Gleichzeitig ist die Vorbereitung auf solche Vorfälle und die Erstellung von Abläufen zur Verkürzung der Dauer eines Dateneinbruchs jedoch ein wesentlicher und realistischer Ansatz für den Umgang mit aktuellen Bedrohungen.

Vorbereitung auf die Bedrohungen

Das Wissen darüber, womit ein Unternehmen zu rechnen hat, ist der erste Schritt bei der Vorbereitung und die Reaktion auf potenzielle Cyberangriffe. In der Vergangenheit waren die Bedrohungen viel einfacher gestrickt und weitgehend durch die von ihnen ausgenutzten Technologien definiert. Doch nun, da Unternehmen auf fortschrittlichere Netzwerk- und Dateninfrastrukturen zurückgreifen, ist die Angriffsfläche grösser, und die Auswirkungen der Bedrohungen haben sich verstärkt.

Der Sicherheitsbericht für 2019 von Trend Micro weist auf die Komplexität und Persistenz der heutigen Bedrohungen hin. Ransomware-Angriffe zielen immer häufiger auf hochkarätige Ziele, wobei die Kriminellen weniger neue Familien entwickeln. 2019 gab es mit 95 neuen Ransomware-Familien weniger als die Hälfte im Vergleich zu 2018 (222). Auch Phishing-bezogene Aktivitäten nahmen ab.

2019 gab es eine Reihe Aufsehen erregender Angriffe auf E-Commerce Sites wie Magecart Group 12 und FIN6, wobei tausende Online-Shops infiziert wurden, um Zahlungsinformationen der Kunden zu stehlen.

Bild 1: Angriffskampagne auf E-Commerce Site Magecart Group 12 und FIN6

Obige Bedrohungen verdeutlichen die Sicherheitslücken in den heute verwendeten Technologien. Sie zeigen auch, wie Trends und Schwächen von Branchen, Geräten oder Plattformen die Bedrohungslandschaft prägen. Organisationen haben eine Vielzahl von Grundlagen abzudecken, wenn sie neue Anwendungen und Software einführen, die Abläufe verbessern und Innovationen vorantreiben sollen. Neben der Kenntnis der aktuellen Bedrohungen sollten die Mitarbeiter auch alle von ihrer Organisation verwendeten Technologien genau verstehen lernen.

Während ein vielschichtiger Schutz bei der Erkennung und Verhinderung von Cyberattacken helfen kann, sollten alle Mitarbeiter, die für die Wartung der Unternehmensinfrastruktur zuständig sind, auch über Kenntnisse darüber verfügen, wie sie auf einen Einbruch und einen aktiven Angriff reagieren sollen.

Incident Response

Bedrohungen, die die Verteidigungslinien von Unternehmen angreifen, erfordern eine effektive Strategie zur Reaktion auf Vorfälle (Incident Response). Es ist der Prozess oder der Plan, den Organisationen als Leitfaden für die Handhabung und Eindämmung von Verstössen oder Cyberangriffen verwenden.

Das Ziel von Incident Response besteht darin, das Unternehmen nach einem Angriff wieder zum Laufen zu bringen. Dazu gehört die Identifizierung und Qualifizierung der Bedrohung, die ihre Verteidigungsmechanismen überwunden hat. Ein Störfall impliziert auch, dass die Präventionsmechanismen der Organisation versagt haben und verstärkt werden müssen.

Ein charakteristisches Merkmal von Incident Response ist, dass die Reaktion erfolgreich sein kann, ohne den Bedrohungsakteur hinter dem Angriff identifizieren zu müssen. Incident Response erfolgt „live“ oder während eines laufenden Angriffs mit der Absicht, diesen zu stoppen. Im Gegensatz dazu erfolgt etwa Computer-Forensik im Nachhinein und kann in die Tiefe gehen, weil die Bedrohung zurückgegangen ist.

Es gibt zwei weithin als Standard akzeptierte Incident Response Frameworks: NIST (National Institute of Standards and Technology) und SANS (SysAdmin, Audit, Network, and Security). Sie sind einander sehr ähnlich und decken eine breite Basis ab, von der Vorbereitung auf einen Angriff bis zum Sicherstellen, dass sich der Vorfall nicht wiederholt.

SANS

NIST

Bild 2: Incident Response-Schritte bei SANS und NIST

Der zweite Teil beschreibt ein Playbook mit den einzelnen konkreten Schritten, die ein Unternehmen beim Aufsetzen von Incident Response gehen muss.

Ähnliche Artikel:

  1. Trend Micro als „Leader“ für Cross-Layer Detection and Response
  2. Der Security-RückKlick 2020 KW 14
  3. Sicherheit von 5G-Konnektivität im Unternehmen
  4. Malware in Smart Factories: Die wichtigsten Bedrohungen für Produktionsumgebungen
  5. Verbindungen zwischen Einzelangriffen erkennen — und darauf reagieren