Archiv der Kategorie: Cloud Security

Wie ein Bezahlsystem zur Grundlage einer Security Strategie wird

von Richard Werner, Business Consultant

Ja, der Titel ist ernst gemeint. Eigentlich schaut man sich immer zuerst nach der Ware um und kümmert sich dann um den Preis, aber gerade in der Cloud laufen die Dinge anders. Deshalb ist es an der Zeit, sich auch mit neuen Ideen zu beschäftigen. Um zu verstehen, warum Überlegungen zum Bezahlmodell in der Cloud bei der Auswahl des Security Providers viel Mühe sparen kann, ist es wichtig, zuerst die Motivationen zu verstehen, die ein Unternehmen dazu treibt, ganz oder teilweise in die Cloud zu gehen.

Flexibilität

Die Mär, die Cloud sei billiger, hält sich hartnäckig. Doch gerade in Sicherheitskreisen weiss man, dass dies so nicht stimmt. Zieht ein Unternehmen im Rahmen einer Migration System um System in die Cloud und vergleicht erst anschliessend die Kosten, so läuft die Aktion bestenfalls auf eine Nullsumme hinaus. Und genau darum geht es aber nicht, denn die Cloud soll ein Unternehmen agiler machen und Über- bzw. Unterkapazitäten ausgleichen.

Als Beispiel dafür, wie Flexibilität in der IT Security zum Erfolg führen kann, mag hier die Geschichte eines Serviceanbieters aus Texas dienen. Dieses Unternehmen offeriert seinen Kunden weltweit Dienstleistungen rund um das Thema Event-Management. Vom Ticketverkauf bis zur Event-Organisation kann alles gebucht werden. Das Unternehmen hatte 2019 mit dem „Problem“ zu kämpfen, erfolgreich zu sein. Aufgrund der schnellen Ausweitung des Angebots kam es regelmässig zu Kapazitätsengpässen. Da das Geschäft dennoch starken Schwankungen unterlag, war die Beschaffung, Verteilung und Koordinierung von Rechenkapazitäten zur grössten IT Herausforderung geworden. Der Gang in die Cloud löste das Problem. Aufgrund unbegrenzter Kapazitäten sowie der Möglichkeit je nach Bedarf automatisiert Systeme zu- oder abzuschalten, konnte die häufig saisonal bzw. regional bedingten Kapazitätsänderungen ohne logistische Herausforderung abgebildet werden.

Logistic kills Deployment

Die IT-Sicherheitsabteilung des Anbieters erstellte daraufhin zusammen mit ihrem Security Provider ein Konzept, welches es erlaubte, das Sicherheitsniveau des Rechenzentrums weitestgehend in der Cloud abzubilden. Die Sache hatte nur einen Haken: Als die IT-Security bei den Fachabteilungen anfragte, welcher Aufwand zu erwarten sei, um die benötigten Lizenzen zu erwerben bzw. abzuschätzen in welchem Masse Mehraufwand bezüglich des Managements von zwei verschiedenen Security-Lösungen auf Sicherheitsmitarbeiter zukäme, wurde ihnen mit einem Schulterzucken geantwortet.

Der Grund, in die Cloud zu gehen, war genau der, dass diese Fragen offen waren. Je nach Auftragslage wurden mitunter für einen kurzen Zeitraum grosse Kapazitäten benötigt. Parallel zeigte der wirtschaftliche Erfolg des Unternehmens (vor Corona), dass die Gesamtanforderung weiter ansteigen würde. Das Unternehmen wollte seinen Erfolg schlicht nicht von der Verfügbarkeit der Rechenleistung abhängig machen. Da sich die Security-Anforderungen des Unternehmens an Compliance Vorgaben (speziell DSGVO und PCI-DSS) ausrichteten, waren Mindestanforderungen verpflichtend einzuhalten.

Hier stellte sich der erstellte Prozess als derart unflexibel und technisch komplex heraus, dass für die Cloud-Bestandteile des Unternehmens die Einrichtung und Dokumentation der Compliance eine beträchtliche logistische Herausforderung mit sich brachte. Unter anderem führte dies dazu, dass sich Abteilungen genötigt sahen, entweder ihre Aufträge zu verzögern oder auf die rechtzeitige Bereitstellung von Security zu verzichten. Der daraus erwachsende Konflikt, entweder Geschäftsoptionen zu gefährden oder zumindest temporär die Einhaltung der Compliance zu „übersehen“, eskalierte zunehmend.

Als sich das Unternehmen schliesslich aufgrund der Empfehlung seines Cloud Managed Service-Partners für Trend Micro entschied, war die Situation bereits derart eskaliert, dass die Lösung ohne weiteren Proof of Concept in bereits bestehende Live-Systeme integriert wurde. Bei vergleichbaren technischen Optionen war im Besonderen die komplette Integration in Cloud- und On-Premise-Operationen, so wie die flexible Möglichkeit, die Kosten anhand des Bedarfs auszurichten, entscheidend. Die Lizenzen wurden nach Bedarf sowohl in der Cloud als auch On-Premise berechnet. Das hatte während Corona übrigens auch einen ungeplanten Vorteil. Für die Eventagentur brachen in kurzer Zeit immer mehr Märkte ein, bis am Ende fast alles stand. Durch die Abrechnung nach Bedarf wurden so enorme Geldmengen eingespart, weil Systeme nicht bezahlt werden mussten, die nichts mehr zu tun hatten.

„Bring Your Own License“ versus „Pay as You Go“

Sieht man sich im Bereich Cloud-Migration um, so finden beide Bezahlmodelle ihren Platz: „Bring Your own License“ ist dabei der klassische Weg der Vorauszahlung. Der Vorteil dieser Lösung ist, dass sie die Kosten planbar macht, und sie obendrein mit dem Lieferanten verhandelt werden können. Die klassische Migration, Maschine für Maschine, kann so ohne weitere Lizenzabfrage durchgeführt werden. Der Nachteil dieser Lizenzierung ist, dass sie jegliche Flexibilität unmöglich macht. Werden mehr Lizenzen benötigt, muss das Unternehmen einen Beschaffungsprozess starten – Bedarfsabschätzung eingeschlossen. Benötigt es weniger, hat es halt „draufgezahlt“. Bei der nächsten Verhandlung geht das Spiel dann von vorn los.

„Pay as You Go“ wiederum versucht diese Nachteile auszugleichen. Hier wird nach Verbrauch abgerechnet. Moderne Verfahren ermöglichen eine Minuten genaue Taktung. Werden neue Maschinen gestartet, werden diese automatisch erfasst und mit den vorgegebenen Security-Einstellungen versorgt. Genauso werden sie wieder ausgecheckt, wenn die Systeme nicht mehr benötigt werden. Security wird damit automatisch zu einem Punkt der Betriebskosten. Die Ausgaben steigen oder fallen je nach Erfolg des Unternehmens.

Gemeinsam verwalten

Beide Bezahlmethoden haben ihre Vor- und Nachteile. Wie bereits erwähnt, entscheidet der Anwender mit der Auswahl letztlich darüber, welche Flexibilität seine Sicherheitsabteilung haben wird. Unabhängig davon, für welche Methode ein Unternehmen sich entscheidet, letztendlich geht es darum, dass Sicherheit das tut, wofür sie da ist, nämlich das Geschäft des Unternehmens zu schützen.

Entscheidend dabei ist, dass alles, was mit IT Security zu tun hat, schnell und einfach visualisiert werden kann. Wie auch immer das Datacenter aufgebaut ist, Hybrid oder Multicloud, immer werden Systeme zwischen den Formfaktoren hin und her migriert, flexibel errichtet oder auch ausgeschaltet. Um den Management-Aufwand zu minimieren und auch die Übersicht über Compliance- oder IT-Security-Aufgaben zu erhalten, sollten Organisationen vor allem nach einer Lösung Ausschau halten, die alles gemeinsam verwaltet. Sonst wird IT-Security schnell zu einem logistischen Alptraum.

Fazit

Flexibel zu sein, zahlt sich für Unternehmen aus. Den Erfolg von logistischen Bedürfnissen abzukoppeln heisst, das Business kann nach Bedarf wachsen — „The Sky is the Limit“. Aus Sicht der IT-Security kommt noch hinzu, dass aus „Bremsern“ Partner werden. Damit wird auch Security nicht mehr als Belastung empfunden, sondern als notwendige Massnahme geschätzt.

Für weitere wertvolle Informationen zur Migration in der Cloud melden Sie sich für das Webinar an.

Der Lebenszyklus eines kompromittierten (Cloud) Servers

Originalbeitrag von Bob McArdle

Trend Micro Research hat ein breit angelegtes Forschungsprojekt zum cyberkriminellen Hosting und zur Infrastruktur im Untergrund durchgeführt. Ein erster Report dazu beschäftigte sich mit dem Angebot von Hacker-Infrastrukturen im Untergrund. In dem aktuellen zweiten Teil geht es um den Lebenszyklus von kompromittierten Servern und den verschiedenen Phasen, um daraus Gewinn zu schlagen. Es gilt dabei zu beachten, dass es für Kriminelle keine Rolle spielt, ob der Server On-Premise oder in der Cloud betrieben wird.

Cloud- versus On-Premise-Server

Cyberkriminellen ist es gleichgültig, wo sich die Server befinden. Sie können den Speicherplatz und die Rechenressourcen ausnutzen oder Daten stehlen, egal auf welche Art von Server sie zugreifen. Alles, was am meisten exponiert ist, wird höchstwahrscheinlich missbraucht.

Mit fortschreitender digitalen Transformation und zunehmendem Arbeiten von zuhause werden Cloud-Server am wahrscheinlichsten Bedrohungen ausgesetzt. Leider sind viele IT-Teams in Unternehmen nicht darauf eingerichtet, für die Cloud denselben Schutz zu bieten wie für On-Premise-Server.

Die Forscher betonen, dass dieses Szenario nur für Cloud-Instanzen gilt, die die Speicher- oder Verarbeitungsleistung eines lokalen Servers replizieren. Container oder serverlose Funktionen fallen nicht der gleichen Art von Kompromittierung zum Opfer. Wenn der Angreifer das Cloud-Konto kompromittiert – im Gegensatz zu einer einzelnen laufenden Instanz – entsteht ein völlig anderer Angriffszyklus, da die Angreifer Rechenressourcen nach Belieben in Anspruch nehmen können. Obwohl dies möglich ist, liegt der Fokus der Erforschung nicht darauf.

Alarmsignale für einen Angriff

Viele IT- und Sicherheitsteams suchen möglicherweise nicht nach früheren Stadien des Missbrauchs. Bevor Server jedoch von Ransomware betroffen sind, gibt es andere Alarmsignale, die die Teams auf die Bedrohung aufmerksam machen könnten.

Wenn ein Server kompromittiert und für Kryptowährungs-Mining (auch als Kryptomining bekannt) verwendet wird, kann dies eine der grössten Alarmsignale für das Sicherheitsteam sein. Die Entdeckung von Cryptomining Malware, die auf irgendeinem Server läuft, sollte dazu führen, dass das Unternehmen unverzüglich Massnahmen ergreift und eine Reaktion auf den Vorfall (Incident Response) einleitet, um diesen Server zu sperren.

Dieser Indicator of Compromise (IOC) ist wichtig, denn obwohl Cryptomining-Malware im Vergleich zu anderen Malware-Typen häufig als weniger schwerwiegend angesehen wird, dient sie auch als Taktik zum Geld machen. Sie kann im Hintergrund laufen, während der Serverzugriff für weitere bösartige Aktivitäten verkauft wird. Beispielsweise könnte der Zugang für die Nutzung als Server für unterirdisches Hosting verkauft werden. Gleichzeitig könnten die Daten exfiltriert und als persönlich identifizierbare Informationen (PII) oder für Industriespionage verkauft werden, auch könnten sie für einen gezielten Ransomware-Angriff verscherbelt werden. Dieses Szenario nutzen zumindest einige Access-as-a-Service (AaaS)-Kriminelle als Teil ihres Geschäftsmodells.

Lebenszyklus eines Angriffs

Attacken auf kompromittierte Server folgen einem allgemeinen Muster:

  • Ursprüngliche Kompromittierung: In dieser Phase ist es klar, dass ein Krimineller den Server übernommen hat.
  • Asset-Kategorisierung: Dies ist die Phase der Bestandsaufnahme. Der Kriminelle nimmt seine Einschätzung anhand von Fragen vor, wie etwa: Welche Daten befinden sich auf diesem Server? Besteht die Möglichkeit einer lateralen Bewegung zu etwas Lukrativerem? Wer ist das Opfer?
  • Exfiltrierung sensibler Daten: Der Kriminelle stiehlt unter anderem Unternehmens-E-Mails, Client-Datenbanken und vertrauliche Dokumente. Dies kann jederzeit nach der Kategorisierungsphase passieren, wenn der Angreifer etwas Wertvolles entdeckt hat.
  • Kryptowährungs-Mining: Während der Angreifer einen Kunden für den Serverraum, einen Zielangriff oder andere Mittel zur Geldgewinnung sucht, wird Cryptomining eingesetzt, um im Verborgenen Geld zu verdienen.
  • Wiederverkauf oder Nutzung für gezielte Angriffe mit dem Ziel, mehr Geld zu verdienen: Abhängig davon, was der Kriminelle bei der Kategorisierung der Assets findet, könnte er seinen eigenen gezielten Ransomware-Angriff planen, den Serverzugang für Wirtschaftsspionage oder für weitere Zwecke verkaufen.

Der Lebenszyklus eines kompromittierten Servers bezüglich der Möglichkeiten Gewinn daraus zu ziehen

Häufig ist der Einsatz gezielter Ransomware die letzte Phase. In den meisten Fällen zeigt die Kategorisierung der Assets Daten auf, die zwar für das Unternehmen wertvoll sind, die sich jedoch nicht unbedingt für Spionage eignen.

Ein tiefgreifendes Verständnis der Server und des Netzwerks ermöglicht es Kriminellen hinter einem gezielten Ransomware-Angriff, das Unternehmen dort zu treffen, wo es am meisten schmerzt. Diese Kriminellen kennen den Datenbestand, wissen, wo sie sich befinden, ob es Backups der Daten gibt und vieles mehr. Mit einer so detaillierten Blaupause der Organisation können sie kritische Systeme abriegeln und ein höheres Lösegeld fordern. Das zeigt auch der Halbjahresbericht 2020 von Trend Micro.

Darüber hinaus hat zwar ein Ransomware-Angriff die sichtbare Dringlichkeit für die Abwehr, aber derselbe Angriff könnte auch darauf hinweisen, dass etwas weitaus Schwerwiegenderes wahrscheinlich bereits stattgefunden hat: der Diebstahl von Unternehmensdaten, und dies ist bei der Reaktionsplanung des Unternehmens zu berücksichtigen. Noch wichtiger ist, dass sobald ein IOC für Krypto-Währung gefunden wurde, das Unternehmen in der Lage ist, den Angreifer sofort zu stoppen, um später erhebliche Zeit und Kosten zu sparen.

Letztendlich ist die Sicherheit der Hybrid-Cloud von entscheidender Bedeutung, um diesen Lebenszyklus zu verhindern, unabhängig davon, wo die Daten eines Unternehmens gespeichert sind.

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:

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.

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

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.

Sicherheitstraining auf Mitarbeiterpersönlichkeiten abstimmen

Originalartikel von Bharat Mistry

Nachdem in den letzten Monaten der Lockdown wegen der Corona-Pandemie Unternehmen gezwungen hatte, ihre Mitarbeiter ins Home Office zu schicken, könnte für viele diese Regelung permanent gelten und das verteilte Arbeiten zur Norm werden. Angestellte werden oft als schwächstes Glied in der Sicherheitskette eines Unternehmens bezeichnet, sie könnten also zu einer noch grösseren Belastung werden, wenn sie von zu Hause aus arbeiten. Eine neue Studie von Trend Micro stellt bedauerlicherweise fest, dass viele Mitarbeiter, obwohl während des Lockdowns sicherheitsbewusster geworden, schlechte Gewohnheiten beibehalten haben. CISOs, die die Schulung des Benutzerbewusstseins intensivieren wollen, können bessere Ergebnisse erzielen, wenn sie versuchen, ihre Strategien auf die jeweiligen Benutzer-Persönlichkeiten abzustimmen.

Ergebnisse der Studie

Für die Studie „Head in the Clouds“ wurden 13.200 Remote Worker in 27 Ländern befragt. Es zeigt sich, dass 72% die Cybersicherheits-Richtlinien ihrer Organisation seit dem Lockdown bewusster wahrnehmen. 85% geben an, die IT-Anweisungen ernst zu nehmen, und 81% sind der Ansicht, dass Cybersicherheit teilweise in ihrer Verantwortung liegt. Fast zwei Drittel (64%) geben sogar zu, dass die Verwendung von Anwendungen, die nicht für den Arbeitsplatz bestimmt sind, auf einem Firmengerät ein Risiko darstellt.

Doch trotz dieser Erfahrungen aufgrund des Lockdowns befassen sich viele Mitarbeiter mehr mit der Produktivität. Mehr als die Hälfte der Befragten (56%) gibt zu, eine arbeitsfremde App auf einem Firmengerät zu verwenden, und 66% haben Firmendaten auf dieses Gerät hochgeladen. 39% der Umfrageteilnehmer greifen „oft“ oder „immer“ von einem persönlichen Gerät auf Firmendaten zu, und 29% sind der Meinung, dass sie problemlos eine firmenfremde App nutzen können, da IT-gestützte Lösungen „Nonsens“ sind.

Vier Sicherheitspersönlichkeiten

In einem zweiten Teil der Untersuchung werden die vier verschiedenen Mitarbeiterpersönlichkeiten bezüglich deren Sicherheitsverhalten dargestellt. Mit diesem Teil hatte Trend Micro Dr Linda Kaye, Cyberpsychology Academic an der Edge Hill University beauftragt. Sie unterteilt die Persönlichkeiten in vier Kategorien: ängstlich, gewissenhaft, ignorant und tollkühn.

Ängstliche Mitarbeiter können von Schulungs- und Simulationswerkzeugen profitieren sowie von Echtzeit-Feedback über Sicherheitskontrollen und Mentoring.

Gewissenhafte Mitarbeiter brauchen nur sehr wenig Schulung, können aber als Vorbild für gutes Verhalten dienen und zur Zusammenarbeit mit „Kumpels“ aus den anderen Gruppen gut eingesetzt werden.

Ignorante Nutzer benötigen Spieltechniken und Simulationsübungen, um sie in der Ausbildung zu halten, und können auch zusätzliches Eingreifen erfordern, damit sie die Folgen riskanten Verhaltens wirklich verstehen.

Tollkühne Mitarbeiter stellen vielleicht die grösste Herausforderung dar, denn ihr Fehlverhalten ist nicht das Ergebnis von Unwissenheit, sondern einer wahrgenommenen Überlegenheit gegenüber anderen. Möglicherweise müssen Organisationen Prämienregelungen einsetzen, um die Einhaltung der Vorschriften zu fördern, und unter extremen Umständen DLP- und Sicherheitskontrollen verstärken, um ihr risikoreiches Verhalten zu entschärfen.

Wenn Sicherheitsmanager verstehen, dass kein Mitarbeiter dem anderen gleicht, können sie ihren Ansatz nuancierter gestalten. Die Aufteilung des Mitarbeiterstabs in vier Lager sollte eine persönlichere Herangehensweise gewährleisten als die Einheitsschulungen, die die meisten Organisationen heute durchführen. Die Mitarbeiter können die Vorteile von Schulungs- und Simulationsplattformen geniessen, wie Phish Insight von Trend Micro mit seiner vielfältigen Bibliothek von Schulungsinhalten, die auf die unterschiedlichen Unternehmenskulturen, Qualifikationsniveaus und Rollen der Mitarbeiter zugeschnitten sind.

Ähnliche Artikel:

  1. IoT-Sicherheit eine riskante „Nebensache“
  2. Top 12 der Bedrohungen im nächsten Jahr
  3. Trend Micro-Studie: Es fehlt noch an Bewusstsein für IoT-Sicherheit
  4. Sicherheit für die 4 Cs von Cloud-nativen Systemen: Cloud, Cluster, Container und Code, Teil 1
  5. Sicherheit für die 4 Cs von Cloud-nativen Systemen: Cloud, Cluster, Container und Code, Teil 2

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

Originalartikel von William Malik, CISA VP Infrastructure Strategies

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

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

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

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

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

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

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

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

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

Ähnliche Artikel:

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

Botnet Malware-Varianten zielen auf exponierte Docker Server

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

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

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

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

Analyse der beiden Varianten

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

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

Schutz für Docker-Server

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

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

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

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