Archiv der Kategorie: Cloud Computing

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.

Hacker-Infrastrukturen als Hosting-Angebot im Untergrund

Originalartikel von Vladimir Kropotov, Robert McArdle, and Fyodor Yarochkin, Trend Micro Research

Im cyberkriminellen Untergrund stellt die Hosting-Infrastruktur eines Kriminellen die Grundlage für sein gesamtes Geschäftsmodell dar. Sie beinhaltet Anonymisierungsdienste, um die Aktivitäten vertraulich zu halten, Command-and-Control (C&C)-Server für den Missbrauch der Rechner der Opfer und Diskussionsforen für die Kommunikation mit anderen Kriminellen. Kriminelle Anbieter liefern Dienste und Infrastrukturen, die andere Kriminelle für die Ausführung ihrer Angriffe benötigen. Ein solcher Hosting-Service kann die Bereitstellung von Hosting-Infrastrukturen, von Domain-Namen, Fast-Flux-Infrastrukturen, Traffic-Beschleunigern, virtuellen und dedizierten Servern und virtuellen privaten Netzwerken (VPNs) umfassen. Gehostete Infrastrukturen werden auch für das Versenden von Phishing-Emails, den Handel mit illegalen Waren in Online-Shops und das Hosten von Virtual Private Systems (VPS), von denen aus Angriffe gestartet werden können, eingesetzt.

Hosting Services im Untergrund

Plattformen im kriminellen Untergrund bieten eine breite Palette von Diensten für kriminelle Hacker. Dazu gehören Bulletproof Hosting und Proxies bis hin zu VPS und VPNs. Interessanterweise finden sich solche Dienste auch in Foren, die mit Online-Wetten, Online-Marketing und Suchmaschinenoptimierung (SEO) zu tun haben.

Es gibt darüber hinaus auch Chat-Gruppen auf Online-Messenger-Plattformen wie VK, Telegram und WhatsApp, die zur Werbung für die oben genannten Dienste genutzt werden. Die Anzeigen in Untergrundforen und sozialen Netzwerken hatten dieselben Kontaktinformationen wie die Verkäufer, stellten die Forscher fest. Dies widerlegt die bestehende Vorstellung, dass Kriminelle nur im Untergrund illegale Waren verkaufen. Sie bieten ihre Marktplätze auch im legalen Netz an.

Dies ist der aktuelle Status des Untergrundmarkts – gut etabliert mit Foren voller Angebote und Communities von Akteuren unterschiedlicher Reife. Die Untergrundmarktplätze haben sich weiterentwickelt und besitzen Strukturen, die die legitimer Geschäfte widerspiegeln. Die Anbieter haben detaillierte Geschäftsmodelle und Systeme entwickelt, die gängige Zahlungsmittel wie PayPal, Mastercard, Visa und Kryptowährungen akzeptieren.

Die Produktpalette im Untergrund ist vielfältig. Abgesehen von den diversen Angeboten von Kreditkarten-Dumps und Skimmern, gibt es Hacking-Dienste in dedizierten Shops, die dedizierte Server, SOCKS-Proxies, VPNs und Distributed Denial-of-Service (DDoS)-Schutz anbieten.

Bild 1. Online-Shop, der dedizierte Hosting-Server anbietet

Die Sicherheitsforscher fanden offizielle Wiederverkäufer von öffentlichen Hosting-Diensten, die in Untergrundforen werben. Diese Provider haben eine legitime Kundschaft und werben im Internet. Mehrere Reseller kümmern sich jedoch auch um Kriminelle im Untergrund, entweder mit oder ohne Wissen des Unternehmens.

Es gibt auch Akteure im Untergrund, die Referenzlinks von Hosting-Providern sharen und sogar Empfehlungsprämien von der Community kassierten. Hosts werden häufig von kriminellen Akteuren wegen ihrer Anonymität und ihrer Möglichkeiten des Missbrauchs diskutiert und beworben.

Bild 2. Werbung für kompromittierte Hosts in einem Untergrundforum

Social Media-Plattformen, die kriminelle Anbieter und Käufer ausnutzen

Wie jedes Unternehmen, das Waren und Dienstleistungen an potenzielle Abnehmer verkauft, werben auch kriminelle Händler. Verkäufer nutzen verschiedene Plattformen, um für ihre Produkte und Dienstleistungen zu werben: Chat-Kanäle, Hacking-Foren und Social Media-Posts.

So gab es beispielsweise einen Hosting-Service, der im sozialen Netzwerk VK als geeignet beworben wurde, um Brute-Force-Angriffe und Massen-Internet-Scans über Masscan, Nmap und ZMap durchzuführen.

Fazit

Ein gutes Wissen, den kriminellen Untergrund betreffend, ist von entscheidender Bedeutung, um Organisationen, der InfoSec-Community und den Strafverfolgungsbehörden dabei zu helfen, mit der Cyberkriminalität umzugehen und sie einzudämmen. Ein zweiter Teil zu der Forschung von Trend Micro stellt dar, wie Cyberkriminelle Infrastrukturkomponenten erwerben und einsetzen, so etwa kompromittierte Assets und dedizierte Hosting-Server.

Details zu der aktuellen Forschung umfasst das Whitepaper „The Hacker Infrastructure and Underground Hosting: An Overview of the Cybercriminal Market“. Es gibt Einblicke in die Funktionsweise einer Untergrundwirtschaft und die Grundlagen von krimineller Online-Infrastruktur.

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.

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

Originalbeitrag von Magno Logan, Threat Researcher

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

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

Bild 1. Die 4 Cs der Cloud-nativen Sicherheit

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

Container-Sicherheit

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

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

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

Code-Sicherheit

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

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

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

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

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

Fazit

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

Cloud-Sicherheitslösungen von Trend Micro

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

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

Originalbeitrag von Magno Logan, Threat Researcher

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

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

Bild 1. Die 4 Cs der Cloud-nativen Sicherheit

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

Cloud-Sicherheit

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

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

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

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

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

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

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

Cluster-Sicherheit

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

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

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

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

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

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

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

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

Geteilte Verantwortlichkeiten

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

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

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

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

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

Die wichtigsten Herausforderungen für die Sicherheit

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

Verwalten der Komplexität

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

Übersicht erhalten

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

Sicherheitsrisiken und Bedrohungen in der Cloud

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

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

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

Die zu sichernden Bereiche in der Cloud

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

Netzwerk (Traffic Inspection, Virtual Patching)

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

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

Cloud-Instanz (Workload-Sicherheit zur Laufzeit)

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

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

DevOps (Container-Sicherheit)

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

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

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

Applikationen (Serverlos, APIs, Web Apps)

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

Dateispeicher

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

Compliance und Governance

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

Cloud-Sicherheitstechnologien

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

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

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

Cloud One Webinare von Trend Micro

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

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

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

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

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

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

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

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

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

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

Originalbeitrag von Jason Dablow

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

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

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

Das Sicherheits-Framework umfasst sieben Prinzipien:

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

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

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

Live Webinare von Trend Micro

Treffen Sie im Mai unsere Experten zu verschiedenen Themen in unseren für Sie aufbereiteten Webinaren.
Melden Sie sich noch heute an.

Schutz vor Schwachstellen mit virtuellem Patching – Trend Micro Deep Security
Datum: 11. Mai, Zeit: 11:00 – 11:30 Uhr –> Anmelden
Referent: Elias Kickinger, Sales Engineer
oder alternativ
Datum: 25. Mai, Zeit: 14:00 – 14:30 Uhr –> Anmelden
Referent: Elias Kickinger, Sales Engineer

Sicherheitslücken und wie sie geschlossen werden können – das ist in der IT-Welt kein neues Thema. Umso mehr überrascht es, dass das Problem auch heute nicht gelöst ist und periodisch an die Oberfläche schwappt, immer dann, wenn eine alte Betriebssystemvariante, wie z.B. Windows Server 2008, abgekündigt wird. Dabei gibt es Methoden, die damit verbundenen Risiken zu beseitigen oder zumindest einzudämmen. Die erfolgreichste in diesem Zusammenhang – „virtuelles Patchen“.

Erweiterte Bedrohungsabwehr und Datensicherheit für Office 365, Gmail und Cloud-Filesharing Dienste – Trend Micro Cloud App Security
Datum: 20. Mai, Zeit: 14:00 – 14:30 Uhr –> Anmelden
Referent: Daniel Bühler, Technical Consultant
oder alternativ
Datum: 29. Mai, Zeit: 11:00 – 11:30 Uhr –> Anmelden
Referent: Daniel Bühler, Technical Consultant

Beim Einsatz von cloudbasierten Unternehmensanwendungen wie Microsoft® Office 365, Box, Dropbox und Google Drive müssen Unternehmen in puncto Sicherheit noch wachsamer sein als je zuvor. Diese Anwendungen werden zwar in einer sicheren Umgebung bereitgestellt, aber Unternehmen tragen gemeinsam die Verantwortung für den Schutz der Inhalte der Anwendungen.

Endpunktsicherheit neu definiert – Apex One, automatische und intelligente Komplettlösung von Trend Micro (onPremise oder SaaS)
Datum: 19. Mai, Zeit: 10:00 – 10:30 Uhr –> Anmelden
Referent: Daniel Bühler, Technical Consultant
oder alternativ
Datum: 27. Mai, Zeit: 14:00 – 14:30 Uhr –> Anmelden
Referent: Daniel Bühler, Technical Consultant

Trend Micro™ Apex One™ bietet fortschrittliche, automatisierte Erkennung und Abwehr der ständig wachsenden Vielzahl von Bedrohungen, einschließlich dateiloser Angriffe und Ransomware. Das fortschrittliche EDR-Toolset, starke SIEM-Integration und offene APIs bieten Ihnen sofort verwertbare Erkenntnisse, erweiterte Untersuchungsmöglichkeiten und zentrale Transparenz. Apex One stellt Erkennung, Abwehr und Untersuchung von Bedrohungen in einem einzigen Agenten bereit. Sie sind nicht länger auf mehrere Anbieter und Konsolen angewiesen und können die Flexibilität von SaaS- und On-Premises-Optionen nutzen.

Prinzipien für die Cloud Migration – Zuständigkeiten in der Sicherheit

Originalartikel von Jason Dablow und Mark Nunnikhoven, Vice President, Cloud Research

Analysten gehen davon aus, dass mehr als 75 Prozent der mittleren und großen Unternehmen bis 2021 eine Workload in die Cloud auslagern werden. Der Erfolg einer solchen Migration hängt von vielen Faktoren ab — nicht nur IT-Teams, Betrieb und Sicherheit sind involviert sondern auch Fach-, Finanz- und andere Abteilungen der Unternehmens. Best Practices, Fallbeispiele und Überlegungen rund um eine erfolgreiche Cloud-Migration sollen Unternehmen bei einem Cloud-Projekt helfen. Dazu gehören selbstverständlich auch die Sicherheitskonzepte für diese „neue“ Welt und damit auch die Zuteilung von Verantwortlichkeiten für Security.

Im Rahmen der Untersuchung „Untangling the Web of Cloud Security Threats“ bestätigt Trend Micro erneut, dass Fehlkonfigurationen die Hauptursache für Sicherheitsrisiken in der Cloud sind. Trotz des klaren Betriebsmodells der Cloud machen die Teams weiterhin einfache Fehler oder übersehen, die von ihnen genutzten Dienste in der Cloud richtig zu konfigurieren.

Eine der Ursachen für Fehlkonfigurationen liegt im Missverständnis darüber, wer (Provider oder Unternehmen) wofür zuständig ist. In einem solchen Szenario erwarten Sicherheitsteams, zuständig für die Cloud im Unternehmen, von ihrem Provider, dass er Kontrollmechanismen zur Verfügung stellt und Monitoring für bestimmte Aspekte durchführt, obwohl diese Bereiche eigentlich in die Verantwortung des Teams fallen.

Ein leider häufig anzutreffendes Beispiel hierfür ist, wenn Teams virtuelle Maschinen oder Instanzen in der Cloud mit einem vorkonfigurierten Bereitstellungsdienst verwenden. In diesen Fällen hat der Cloud-Anbieter die Schritte vereinfacht, die erforderlich sind, um gängige Konfigurationen in der Cloud zum Laufen zu bringen. Doch sobald die Konfiguration läuft, liegt es in der Verantwortung des Teams im Unternehmen, die Lösung zu patchen, zu härten und zu warten.

Sicherheit in der Cloud funktioniert gemäß dem Shared Responsibility Model, das festlegt, wer für eine jede operative Aufgabe in der Cloud verantwortlich ist. Dabei ist Sicherheit nur eine Teilmenge dieser Aufgaben.

Das Modell an sich ist recht einfach:

Es gibt sechs Bereiche, in denen eine tagtägliche Arbeit erforderlich ist — angefangen von der physischen Sicherheit (Gebäude, in dem die Systeme sicher untergebracht sind, bezahlt werden usw.) bis hin zur Infrastruktur, Virtualisierung, Betriebssystemen, Anwendungen und Daten.

In einer traditionellen On-Premise-Umgebung ist das Unternehmen für alle sechs Bereiche verantwortlich. Diese Arbeit wird normalerweise auf mehrere Teams aufgeteilt, aber letztendlich unterstehen sie alle einer Person innerhalb der Organisation, in der Regel dem CIO. Bei einer Migration in die Cloud, wird mindestens die Hälfte der Verantwortlichkeiten an den Cloud-Provider übergeben.

Bei Services auf Infrastrukturebene (IaaS), wie etwa die Instanzen oder virtuellen Maschinen, übernehmen Unternehmen die Verantwortung auf der Ebene des Betriebssystems. Die Konfiguration und Wartung des Betriebssystems liegt vollständig bei dem Team des Unternehmens.

Je mehr es um abstraktere oder SaaS-artige Dienste geht, desto weniger Verantwortlichkeiten tragen die Firmen selbst.  Das bedeutet, dass sie sich auf weniger Bereiche konzentrieren können, um die Sicherheit zu gewährleisten.

Vertrauen und Prüfen

Natürlich sollte sich kein Sicherheitsprofi lediglich auf die Zusage des Cloud-Service Providers verlassen, ohne zu verifizieren, ob er die Verantwortung gemäß des Modells wahrnimmt. Dafür gibt es Compliance-Attestierungen, etwa PCI-DSSSOC1 oder ISO 27001. Auch kann ein Unternehmen jederzeit eine Kopie der Audit-Ergebnisse für ein bestimmtes Compliance-Framework von seinem Provider anfordern.

Eine weitere Ursache für Fehlkonfigurationen liegt in einfachen Fehlern. Die Cloud ist ein Verstärker, denn mit einem einzigen API-Call lässt sich das Äquivalent eines ganzen Rechenzentrums starten. Die Kehrseite der Medaille ist, dass kleinere Teams für eine größere Vielfalt an technischen Stacks und Diensten verantwortlich sind. Einfache Fehler, die zu unnötigen Risiken führen, sind da unvermeidlich. Hier gilt es, soweit wie möglich zu automatisieren. Dadurch werden Fehler insgesamt reduziert, und die Fehler, die dennoch vorkommen, sind konsistent und leichter zu beheben.

Cloud-Sicherheitsverantwortliche im Unternehmen

  • InfoSec – Die Abteilung muss wohl an erster Stelle genannt werden, ist sie doch für die gesamte Informationssicherheit innerhalb einer Organisation zuständig. Und da es auch im Rahmen der Cloud-Migration um den Umgang mit „Informationen“ geht, muss InfoSec involviert sein, wenn es um den Zugang zum Monitoring der mit einer Organisation verbundenen Sicherheit und Risiken geht.
  • Cloud Architekt – Diese Position ist wichtig, um nicht den Fehler zu begehen, einfach die alten Prinzipien des On-Premise-Betriebs in die Cloud zu übertragen. Eine agile Plattform, die für die Automatisierung jedes Vorgangs, einschließlich der Sicherheit, gebaut wurde, sollte im Mittelpunkt stehen.
  • IT / Cloud Ops – Dabei kann es sich um dieselben oder verschiedene Teams handeln. Wenn mehr und mehr Ressourcen in die Cloud verlagert werden, wird ein IT-Team weniger Verantwortung für die physische Infrastruktur haben, da diese nun ein Cloud-Anbieter betreibt. Sie werden selbst eine „Migration“ durchlaufen müssen, um neue Fähigkeiten für den Betrieb und die Sicherung einer hybriden Umgebung zu erlernen.