Überwachung der Cloud-Sicherheit

Der Transfer von Daten und Anwendungen in die Cloud stellt eine neue Herausforderung für Unternehmens-SOCs dar, die nicht immer auf die Überwachung fremder Infrastrukturen vorbereitet sind. Laut Netoskope nutzen durchschnittliche Unternehmen (offenbar vor allem in den USA) 1246 verschiedene Cloud-Dienste, was einem Anstieg von 22 % im Vergleich zum Vorjahr entspricht. 1246 Cloud-Dienste!!! 175 davon betreffen HR-Dienste, 170 sind im Marketing angesiedelt, 110 im Bereich Kommunikation und 76 in Finanzen und CRM. Bei Cisco werden 'nur' 700 externe Cloud-Dienste verwendet. Daher wundern mich diese Zahlen etwas. Unabhängig davon liegt das Problem jedoch nicht darin, sondern darin, dass immer mehr Unternehmen aktiv damit beginnen, Cloud-Lösungen zu nutzen, die dieselben Überwachungsmöglichkeiten für die Cloud-Infrastruktur bieten möchten wie in ihrem eigenen Netzwerk. Dieser Trend nimmt zu — gemäß Angaben des US-amerikanischen Rechnungshofs Bis 2023 soll es in den USA zu einem Abschluss von 1200 Rechenzentren kommen (6250 sind bereits geschlossen). Doch der Umstieg auf die Cloud ist nicht einfach "lassen Sie uns unsere Server zu einem externen Anbieter verlagern". Eine neue IT-Architektur, neue Software, neue Prozesse, neue Beschränkungen… All dies bringt erhebliche Veränderungen sowohl in der IT als auch in der Informationssicherheit mit sich. Während die Anbieter gelernt haben, die Sicherheit der Cloud selbst in den Griff zu bekommen (zum Glück gibt es zahlreiche Empfehlungen dazu), bestehen erhebliche Herausforderungen im Bereich der Cloud-Sicherheitsüberwachung, besonders auf SaaS-Plattformen, über die wir sprechen werden.

Angenommen, Ihr Unternehmen hat Teile seiner Infrastruktur in die Cloud verlagert... Halt. So nicht. Wenn die Infrastruktur bereits verlagert wurde und Sie erst jetzt darüber nachdenken, wie Sie diese überwachen werden, haben Sie bereits verloren. Wenn es sich nicht um Amazon, Google oder Microsoft handelt (und selbst das mit Vorbehalten), werden Sie wahrscheinlich nicht viele Möglichkeiten zur Überwachung Ihrer Daten und Anwendungen haben. Es ist gut, wenn Sie die Möglichkeit erhalten, mit Protokollen zu arbeiten. Manchmal sind Sicherheitsereignisdaten verfügbar, aber Sie haben keinen Zugriff darauf. Zum Beispiel bei Office 365. Wenn Sie die günstigste E1-Lizenz besitzen, haben Sie überhaupt keinen Zugriff auf Sicherheitsereignisse. Mit einer E3-Lizenz werden die Daten nur 90 Tage lang gespeichert, und nur mit einer E5-Lizenz sind die Protokolle ein ganzes Jahr lang verfügbar (obwohl auch hier einige Nuancen zu beachten sind, da es notwendig ist, eine Reihe von Funktionen zur Protokollierung separat bei Microsoft Support anzufordern). Übrigens ist die E3-Lizenz in Bezug auf Überwachungsfunktionen viel schwächer als der Unternehmens-Exchange. Um dasselbe Niveau zu erreichen, benötigen Sie eine E5-Lizenz oder eine zusätzliche Lizenz für Advanced Compliance, die möglicherweise zusätzliche Kosten verursachen, die in Ihrem finanziellen Modell für den Übergang zur Cloud-Infrastruktur nicht berücksichtigt wurden. Und das ist nur ein Beispiel für die Unterschätzung von Fragen der Cloud-Sicherheitsüberwachung. In diesem Artikel möchte ich, ohne Anspruch auf Vollständigkeit, auf einige Nuancen hinweisen, die bei der Auswahl eines Cloud-Anbieters aus sicherheitstechnischer Sicht zu berücksichtigen sind. Am Ende des Artikels finden Sie eine Checkliste, die Sie abarbeiten sollten, bevor Sie davon ausgehen, dass die Überwachung Ihrer Cloud-Sicherheitsinfrastruktur gelöst ist.

Es gibt mehrere typische Probleme, die in Cloud-Umgebungen zu Vorfällen führen, auf die die Informationssicherheitsdienste nicht rechtzeitig reagieren oder sie überhaupt nicht bemerken.

• Sicherheitsprotokolle existieren nicht. Dies ist eine recht verbreitete Situation, insbesondere bei neuen Anbietern auf dem Markt für Cloud-Lösungen. Allerdings sollte man sie auch nicht sofort abschreiben. Kleinere Anbieter, besonders lokale, sind sensibler gegenüber den Anforderungen der Kunden und können schnell gefragte Funktionen umsetzen, indem sie ihren genehmigten Fahrplan für ihre Produkte anpassen. Ja, das wird nicht den Standards von GuardDuty von Amazon oder dem Modul „Proaktive Sicherheit“ von Bitrix entsprechen, aber immerhin etwas.
• Die Informationssicherheit weiß nicht, wo die Protokolle gespeichert sind oder hat keinen Zugriff darauf. Hier ist es notwendig, mit dem Cloud-Dienstleister zu verhandeln – möglicherweise wird er solche Informationen bereitstellen, wenn er den Kunden als für sich wichtig erachtet. Insgesamt ist es jedoch nicht ideal, wenn der Zugang zu den Protokollen „auf besonderen Beschluss“ gewährt wird.
• Es kann vorkommen, dass ein Cloud-Anbieter Protokolle bereitstellt, diese jedoch nur eingeschränkte Überwachung und Ereignisprotokollierung gewährleisten, die nicht ausreichen, um alle Vorfälle zu erkennen. Zum Beispiel könnten Ihnen nur die Protokolle von Änderungen auf der Website oder von Benutzerauthentifizierungsversuchen zur Verfügung gestellt werden, während andere Ereignisse, wie z.B. der Netzwerkverkehr, nicht bereitgestellt werden. Dies würde Ihnen einen wichtigen Teil der Ereignisse vorenthalten, die die Versuche charakterisieren, Ihre Cloud-Infrastruktur anzugreifen.
• Es gibt Protokolle, aber der Zugriff darauf ist schwer zu automatisieren, was bedeutet, dass sie nicht kontinuierlich überwacht, sondern nur nach einem Zeitplan kontrolliert werden. Und wenn die Protokolle nicht automatisch exportiert werden können, kann der Export der Protokolle, z.B. im Excel-Format (wie bei einigen einheimischen Anbietern von Cloud-Lösungen), dazu führen, dass die Unternehmens-IT-Sicherheit keinen Aufwand dafür betreiben möchte.
• Es gibt keine Überwachung der Protokolle. Das ist wohl der unverständlichste Grund für das Auftreten von Sicherheitsvorfällen in Cloud-Umgebungen. Es scheint, als ob es Protokolle gibt und man den Zugriff darauf automatisieren könnte, aber niemand tut es. Warum?

Das Konzept der gemeinsamen Sicherheit in der Cloud

Der Übergang in die Cloud ist immer ein Balanceakt zwischen dem Wunsch, die Kontrolle über die Infrastruktur zu behalten, und der Übergabe dieser Verantwortung an einen professionellen Cloud-Anbieter, der auf deren Wartung spezialisiert ist. Auch im Bereich der Sicherheit von Cloud-Umgebungen ist es notwendig, diese Balance zu finden. Je nach gewähltem Cloud-Service-Modell (IaaS, PaaS, SaaS) wird diese Balance stets unterschiedlich sein. In jedem Fall sollten wir uns bewusst sein, dass alle Cloud-Anbieter heute nach dem Prinzip der geteilten Verantwortung und der geteilten Informationssicherheit arbeiten. Das Cloud-System ist für bestimmte Aspekte verantwortlich, während der Kunde, der seine Daten, Anwendungen, virtuellen Maschinen und andere Ressourcen in der Cloud platziert, für andere verantwortlich ist. Es wäre unklug zu erwarten, dass wir beim Wechsel in die Cloud die gesamte Verantwortung auf den Anbieter abwälzen. Doch es ist auch nicht ratsam, die gesamte Sicherheit selbst zu gestalten, wenn wir in die Cloud wechseln. Eine Balance ist erforderlich, die von vielen Faktoren abhängt: der Strategie des Risikomanagements, den Bedrohungsmodellen, den Sicherheitssystemen des Cloud-Anbieters, den gesetzlichen Rahmenbedingungen usw.

Die Verantwortung für die Klassifizierung von Daten, die in der Cloud gespeichert sind, liegt immer beim Auftraggeber. Der Cloud-Anbieter oder ein externer Dienstleister kann lediglich mit Werkzeugen unterstützen, die helfen, Daten in der Cloud zu kennzeichnen, Verstöße zu erkennen, gesetzeswidrige Daten zu löschen oder diese durch verschiedene Methoden zu maskieren. Auf der anderen Seite liegt die physische Sicherheit immer in der Verantwortung des Cloud-Anbieters, die er nicht mit seinen Kunden teilen kann. Alles, was zwischen den Daten und der physischen Infrastruktur steht, ist jedoch das Thema dieses Artikels. Die Verfügbarkeit der Cloud liegt in der Verantwortung des Anbieters, während die Konfiguration der MSCE-Regeln oder die Aktivierung von Verschlüsselung bereits die Verantwortung des Kunden sind. In diesem Artikel werden wir untersuchen, welche Sicherheitsüberwachungsmechanismen heute verschiedene beliebte Cloud-Anbieter in Deutschland bieten, welche Besonderheiten sie aufweisen und wann es sinnvoll ist, externen Lösungen wie Cisco E-mail Security in Betracht zu ziehen, die die Cybersecurity-Funktionen Ihrer Cloud erweitern. In einigen Fällen, insbesondere bei der Umsetzung einer Multi-Cloud-Strategie, bleibt Ihnen keine andere Wahl, als externe Lösungen zur Sicherheitsüberwachung in mehreren Cloud-Umgebungen zu nutzen (z.B. Cisco CloudLock oder Cisco Stealthwatch Cloud). In vielen Fällen werden Sie feststellen, dass Ihr gewählter (oder Ihnen aufgezwungener) Cloud-Anbieter überhaupt keine Möglichkeiten zur Sicherheitsüberwachung anbietet. Das ist unangenehm, aber auch wichtig, da es Ihnen ermöglicht, das Risiko, das mit der Nutzung dieser Cloud verbunden ist, angemessen zu bewerten.

Lebenszyklus der Sicherheitsüberwachung in der Cloud

Um die Sicherheit Ihrer genutzten Clouds zu überwachen, haben Sie nur drei Möglichkeiten:

• sich auf die vom Cloud-Anbieter bereitgestellten Werkzeuge zu verlassen,
• Lösungen von Drittanbietern zu nutzen, die die von Ihnen verwendeten IaaS-, PaaS- oder SaaS-Plattformen überwachen,
• oder Ihre eigene Infrastruktur zur Überwachung von Cloud-Umgebungen aufzubauen (nur für IaaS/PaaS-Plattformen).

Lassen Sie uns die Funktionen jeder dieser Optionen betrachten. Zuvor müssen wir jedoch das allgemeine Schema verstehen, das bei der Überwachung von Cloud-Plattformen verwendet wird. Ich würde 6 grundlegende Komponenten des Sicherheitsmonitoring-Prozesses in der Cloud hervorheben:

• Vorbereitung der Infrastruktur. Bestimmung der benötigten Anwendungen und Infrastruktur zur Erfassung sicherheitsrelevanter Ereignisse im Speicher.
• Erfassung. In dieser Phase werden Sicherheitsereignisse aus verschiedenen Quellen aggregiert, um sie zur Verarbeitung, Speicherung und Analyse weiterzuleiten.
• Verarbeitung. In dieser Phase werden die Daten transformiert und angereichert, um die anschließende Analyse zu erleichtern.
• Speicherung. Diese Komponente ist für die kurzfristige und langfristige Speicherung gesammelter, verarbeiteter und „roher“ Daten verantwortlich.
• Analyse. In diesem Schritt haben Sie die Möglichkeit, Vorfälle zu erkennen und darauf entweder automatisch oder manuell zu reagieren.
• Berichterstattung. Dieser Schritt hilft dabei, für alle Beteiligten (Management, Auditoren, Cloud-Anbieter, Kunden usw.) wichtige Kennzahlen zu erstellen, die uns bei der Entscheidungsfindung unterstützen, etwa bei der Wahl eines neuen Anbieters oder der Verstärkung der Informationssicherheit.

Das Verständnis dieser Komponenten ermöglicht es Ihnen, schnell zu entscheiden, was Sie von Ihrem Anbieter übernehmen können und was Sie selbst oder mit externen Beratern erledigen müssen.

Integrierte Funktionen von Cloud-Diensten

Ich habe bereits erwähnt, dass viele Cloud-Dienste heutzutage keine Möglichkeiten zur Überwachung der Informationssicherheit (IS) bieten. Tatsächlich schenken sie diesem Thema nicht viel Aufmerksamkeit. Zum Beispiel gibt es einen beliebten russischen Dienst für die Übermittlung von Berichten an staatliche Stellen über das Internet (ich werde den Namen absichtlich nicht nennen). Der gesamte Abschnitt zur Sicherheit dieses Dienstes dreht sich um die Verwendung von zertifizierten Kryptografie-Schutzmaßnahmen. Im Vergleich dazu hat ein anderer heimischer Cloud-Service für die elektronische Dokumentenverwaltung einen deutlich umfangreicheren Abschnitt zur IS. Dort wird über Zertifikate der öffentlichen Schlüssel, zertifizierte Kryptografie, die Behebung von Web-Schwachstellen, Schutz vor DDoS-Angriffen, den Einsatz von Sicherheitsmanagement-Systemen, Backups und sogar regelmäßige IS-Audits gesprochen. Aber zur Überwachung wird kein Wort verloren, ebenso wenig über die Möglichkeit, auf IS-Ereignisse zuzugreifen, die für die Kunden dieses Dienstanbieters von Interesse sein könnten.

Anhand der Art und Weise, wie ein Cloud-Anbieter sicherheitsrelevante Themen auf seiner Webseite und in der Dokumentation behandelt, lässt sich ablesen, wie ernst er dieses Thema nimmt. Wenn man beispielsweise die Anleitungen zu den Produkten von „Mein Büro“ liest, findet man dort kein Wort über Sicherheit. In der Dokumentation des speziellen Produkts „Mein Büro. KS3“, das zum Schutz vor unbefugtem Zugriff dient, sind zwar die Punkte des 17. FSTEK-Befehls aufgelistet, die „Mein Büro.KS3“ erfüllt, es wird jedoch nicht beschrieben, wie dies geschieht und, was am wichtigsten ist, wie diese Mechanismen in die Unternehmens-IT-Sicherheit integriert werden. Möglicherweise existiert eine solche Dokumentation, aber im öffentlichen Zugriff auf der Webseite von „Mein Büro“ konnte ich sie nicht finden. Oder habe ich einfach keinen Zugang zu diesen geheimen Informationen…

Bei Bitrix sieht die Situation deutlich besser aus. In der Dokumentation sind Formate für Ereignisprotokolle beschrieben, und interessanterweise auch für das Intrusion-Lock, das Ereignisse enthält, die mit potenziellen Bedrohungen für die Cloud-Plattform zusammenhängen. Dort können Sie IP-Adressen, Benutzernamen oder Gastnamen, die Quelle des Ereignisses, die Zeit, den User-Agent, den Typ des Ereignisses usw. extrahieren. Allerdings können Sie mit diesen Ereignissen entweder über das Control Panel der Cloud arbeiten oder die Daten im MS Excel-Format exportieren. Die Automatisierung der Arbeit mit den Bitrix-Logs gestaltet sich derzeit als schwierig, und Sie müssen einen Teil der Arbeit manuell erledigen (Exportieren des Berichts und Hochladen in Ihr SIEM). Wenn man jedoch bedenkt, dass noch vor relativ kurzer Zeit nicht einmal eine solche Möglichkeit existierte, ist das ein großer Fortschritt. Ich möchte bemerkten, dass auch viele internationale Cloud-Anbieter eine ähnliche Funktionalität „für Einsteiger“ anbieten – entweder die Protokolle direkt über das Control Panel ansehen oder die Daten exportieren (obwohl die meisten die Daten im .csv-Format und nicht in Excel exportieren).

Wenn man die Möglichkeit des Fehlens von Protokollen außer Acht lässt, bieten Cloud-Anbieter in der Regel drei Optionen zur Überwachung von Sicherheitsereignissen an: Dashboards, Datenexport und API-Zugriff. Das erste löst viele Probleme scheinbar für Sie, doch das ist nicht ganz richtig – bei mehreren Protokollen müssen Sie zwischen den Bildschirmen umschalten, was die Gesamtsicht beeinträchtigt. Außerdem wird ein Cloud-Anbieter Ihnen kaum die Möglichkeit zur Korrelation von Sicherheitsereignissen und deren Analyse aus sicherheitstechnischer Sicht bieten (meistens haben Sie es mit rohen Daten zu tun, die Sie selbst interpretieren müssen). Es gibt Ausnahmen, und darüber werden wir später sprechen. Schließlich sollten Sie in Erfahrung bringen, welche Ereignisse Ihr Cloud-Anbieter protokolliert, in welchem Format und wie gut diese mit Ihrem Informationssicherheitsmonitoring-Prozess übereinstimmen. Beispielsweise die Identifizierung und Authentifizierung von Benutzern und Gästen. Derselbe Bitrix ermöglicht es Ihnen, dass Datum und Uhrzeit eines solchen Ereignisses, den Benutzernamen oder Gastnamen (bei Vorhandensein des Moduls „Web-Analyse“), das Objekt, auf das zugegriffen wurde, und andere typische Elemente einer Webseite zu protokollieren. Unternehmens-IT-Services könnten jedoch Informationen darüber benötigen, ob der Benutzer von einem vertrauenswürdigen Gerät auf die Cloud zugegriffen hat (zum Beispiel wird eine solche Aufgabe im Unternehmensnetzwerk durch Cisco ISE realisiert). Eine so einfache Aufgabe wie die Geo-IP-Funktion, die Ihnen helfen sollte festzustellen, ob das Benutzerkonto des Cloud-Dienstes gestohlen wurde? Und selbst wenn der Cloud-Anbieter Ihnen diese zur Verfügung stellt, ist das nicht genug. Dasselbe Cisco CloudLock analysiert nicht nur die Geolocation, sondern verwendet auch maschinelles Lernen und analysiert historische Daten für jeden Benutzer, um verschiedene Anomalien bei der Identifizierung und Authentifizierung zu erkennen. Ähnliche Funktionen bietet nur MS Azure (bei entsprechender Abonnementart).

Eine weitere Herausforderung besteht darin, dass viele Cloud-Anbieter das Monitoring von Informationssicherheit (IB) erst neu für sich entdecken und ständig Anpassungen an ihren Lösungen vornehmen. Heute haben sie eine API-Version, morgen eine andere und übermorgen wieder eine andere. Darauf muss man ebenfalls vorbereitet sein. Gleiches gilt für die Funktionalitäten, die sich ändern können und die in das eigene IB-Monitoringsystem integriert werden müssen. Zum Beispiel hatte Amazon zunächst separate Überwachungsservices für Ereignisse in der Cloud – AWS CloudTrail und AWS CloudWatch. Dann wurde ein eigener Service für das Monitoring von IB-Ereignissen eingeführt – AWS GuardDuty. Nach einiger Zeit launchte Amazon ein neues Management-System, Amazon Security Hub, das die Datenanalyse von GuardDuty, Amazon Inspector, Amazon Macie und weiteren Diensten umfasst. Ein weiteres Beispiel ist das Integrationswerkzeug für Azure-Logs mit SIEM – AzLog. Viele SIEM-Anbieter nutzten es aktiv, bis Microsoft 2018 die Entwicklung und Unterstützung einstellte, was viele Kunden, die dieses Tool benutzten, vor Probleme stellte (wie diese gelöst wurden, werden wir im Folgenden besprechen).

Deshalb sollten Sie alle Überwachungsfunktionen im Blick behalten, die Ihr Cloud-Anbieter Ihnen bietet. Alternativ können Sie sich auf externe Lösungspartner verlassen, die als Vermittler zwischen Ihrem SOC und der Cloud fungieren, die Sie überwachen möchten. Ja, das könnte teurer sein (wenn auch nicht immer), aber Sie übertragen damit die Verantwortung auf andere. Oder doch nicht ganz? Denken wir an das Konzept der geteilten Sicherheit und erkennen, dass wir nichts einfach abgeben können – wir müssen selbst verstehen, wie verschiedene Cloud-Anbieter die Sicherheit und Überwachung Ihrer Daten, Anwendungen, virtuellen Maschinen und anderen Ressourcen in der Cloud gewährleisten. Beginnen wir mit dem, was Amazon in diesem Bereich anbietet.

Beispiel: Überwachung der Sicherheit in IaaS auf Basis von AWS

Ja, ich verstehe, dass Amazon nicht das beste Beispiel ist, da es sich um einen amerikanischen Dienst handelt, der im Rahmen des Kampfes gegen Extremismus und die Verbreitung verbotener Informationen in Russland blockiert werden kann. In diesem Beitrag möchte ich jedoch lediglich aufzeigen, wie unterschiedlich die verschiedenen Cloud-Plattformen in Bezug auf die Möglichkeiten zur Überwachung von Informationssicherheit sind und worauf man achten sollte, wenn man seine Schlüsselprozesse in die Cloud überträgt, insbesondere im Hinblick auf die Sicherheit. Und wenn einige russische Entwickler von Cloudlösungen etwas Nützliches daraus für sich mitnehmen können, wäre das einfach großartig.

Zuerst muss gesagt werden, dass Amazon keine uneinnehmbare Festung ist. Es passieren regelmäßig verschiedene Vorfälle mit seinen Kunden. Beispielsweise wurden bei Deep Root Analytics die Namen, Adressen, Geburtsdaten und Telefonnummern von 198 Millionen Wählern gestohlen. Bei dem israelischen Unternehmen Nice Systems wurden 14 Millionen Datensätze von Verizon-Abonnenten entwendet. Dabei ermöglichen die integrierten Funktionen von AWS, eine breite Palette von Vorfällen zu erkennen. Zum Beispiel:

• Angriffe auf die Infrastruktur (DDoS)
• Kompromittierung des Knotens (Befehlsinjektion)
• Kompromittierung von Konten und unbefugtem Zugriff
• falsche Konfiguration und Sicherheitsanfälligkeiten
• unsichere Schnittstellen und APIs.

Diese Diskrepanz ergibt sich daraus, dass der Kunde selbst für die Sicherheit seiner Daten verantwortlich ist, wie wir oben festgestellt haben. Wenn er keine Schutzmaßnahmen implementiert und keine Überwachungswerkzeuge aktiviert hat, wird er von einem Vorfall nur aus den Medien oder von seinen Kunden erfahren.

Um Vorfälle zu erkennen, können eine Vielzahl von Überwachungsdiensten von Amazon eingesetzt werden (obwohl diese oft durch externe Tools wie osquery ergänzt werden). In AWS werden alle Benutzeraktivitäten verfolgt, unabhängig davon, wie sie erfolgen – über die Benutzeroberfläche, die Kommandozeile, SDKs oder andere AWS-Dienste. Alle Protokolle über Aktivitäten jeder AWS-Konto (einschließlich Benutzername, Handlung, Dienst, Aktivitätsparameter und deren Ergebnis) sowie die Nutzung von APIs sind über den AWS CloudTrail-Dienst verfügbar. Sie können diese Ereignisse (z. B. den Login in die AWS IAM-Konsole) direkt in der CloudTrail-Konsole anzeigen, sie mithilfe von Amazon Athena analysieren oder an externe Lösungen wie Splunk, AlienVault usw. „weitergeben“. Die AWS CloudTrail-Logs werden in Ihrem AWS S3-Bucket abgelegt.

Zwei weitere AWS-Dienste bieten zusätzliche wichtige Funktionen zur Überwachung. Zum einen ist Amazon CloudWatch ein Überwachungsdienst für AWS-Ressourcen und -Anwendungen, der es unter anderem ermöglicht, verschiedene Anomalien in Ihrer Cloud zu entdecken. Alle integrierten AWS-Dienste wie Amazon Elastic Compute Cloud (Server), Amazon Relational Database Service (Datenbanken), Amazon Elastic MapReduce (Datenanalyse) und über 30 andere Amazon-Dienste verwenden Amazon CloudWatch zur Speicherung ihrer Protokolle. Entwickler können die offene API von Amazon CloudWatch nutzen, um die Protokollüberwachungsfunktion in benutzerdefinierte Anwendungen und Dienste hinzuzufügen, was es ermöglicht, den Umfang der analysierten Ereignisse im Kontext der Informationssicherheit zu erweitern.

Zweitens ermöglicht der VPC Flow Logs-Dienst die Analyse des Netzwerkverkehrs, der von Ihren AWS-Servern gesendet oder empfangen wird (äußere oder innere Kommunikation) sowie den Austausch zwischen Mikrodiensten. Wenn einer Ihrer AWS VPC-Ressourcen mit dem Netzwerk interagiert, protokolliert der VPC Flow Logs-Dienst Informationen über den Netzwerkverkehr, einschließlich des Quell- und Zielnetzwerkinterfaces, sowie der IP-Adressen, Ports, Protokolle, der übertragenen Bytes und der Paketanzahl. Personen, die Erfahrung mit lokaler Netzwerksicherheit haben, werden dies als Analogon zu NetFlow anerkennen NetFlow, das von Unternehmensswitches, -routern und Firewall-Systemen erstellt werden kann. Diese Protokolle sind für die Überwachung der Informationssicherheit von Bedeutung, da sie im Gegensatz zu Benutzer- und Anwendungsereignissen auch die Netzwerkinteraktionen in der virtuellen privaten Cloud-Umgebung von AWS nicht auslassen.

Diese drei AWS-Dienste – AWS CloudTrail, Amazon CloudWatch und VPC Flow Logs – bieten gemeinsam eine umfassende Übersicht über die Nutzung Ihres Kontos, das Verhalten der Benutzer, das Management der Infrastruktur, die Aktivitäten von Anwendungen und Diensten sowie die Netzwerkaktivitäten. Beispielsweise können Sie mit ihnen folgende Anomalien erkennen:

• Versuche, eine Website zu scannen, nach Backdoors zu suchen oder Schwachstellen durch „404-Fehler“-Spitzen zu identifizieren.
• Injection-Angriffe (z. B. SQL Injection) durch „500-Fehler“-Spitzen.
• Bekannte Werkzeuge für Angriffe wie sqlmap, nikto, w3af, nmap usw. durch die Analyse des User-Agent-Feldes.

Amazon Web Services hat auch weitere Dienste für Cybersecurity entwickelt, die viele weitere Aufgaben erfüllen. Zum Beispiel gibt es in AWS einen integrierten Service für die Überprüfung von Richtlinien und Konfigurationen – AWS Config. Dieser Service bietet eine kontinuierliche Überwachung Ihrer AWS-Ressourcen und deren Konfigurationen. Lassen Sie uns ein einfaches Beispiel betrachten: Angenommen, Sie möchten sicherstellen, dass Benutzerpasswörter auf allen Ihren Servern deaktiviert und der Zugang nur über Zertifikate möglich ist. AWS Config ermöglicht es Ihnen, dies mühelos für alle Ihre Server zu überprüfen. Es gibt auch andere Richtlinien, die auf Ihren Cloud-Servern angewendet werden können: „Kein Server darf Port 22 verwenden“, „Nur Administratoren dürfen die Firewall-Regeln ändern“ oder „Nur Benutzer Iwaschko darf neue Benutzerkonten erstellen, und dies darf er nur dienstags tun.“ Im Sommer 2016 wurde der AWS Config-Service erweitert, um die Automatisierung bei der Erkennung von Verstößen gegen die festgelegten Richtlinien zu ermöglichen. AWS Config Rules sind im Wesentlichen kontinuierliche Konfigurationsabfragen der von Ihnen verwendeten Amazon-Dienste, die Ereignisse erzeugen, falls die entsprechenden Richtlinien verletzt werden. Zum Beispiel, anstatt gelegentlich AWS Config-Abfragen durchzuführen, um zu überprüfen, dass alle Festplatten des virtuellen Servers verschlüsselt sind, können AWS Config Rules verwendet werden, um kontinuierlich die Festplattenservers auf die Erfüllung dieser Bedingung zu überprüfen. Und das Wichtigste in diesem Zusammenhang: Alle Verstöße erzeugen Ereignisse, die von Ihrem Informationssicherheitsdienst analysiert werden können.

AWS bietet auch seine eigenen Äquivalente zu traditionellen Unternehmenslösungen für Informationssicherheit, die Sicherheitsereignisse generieren, die Sie analysieren können und sollten:

• Intrusion Detection — AWS GuardDuty
• Datenlecks überwachen — AWS Macie
• EDR (obwohl es etwas seltsam klingt, über Endgeräte in der Cloud zu sprechen) — AWS Cloudwatch + Open-Source-Lösungen wie osquery oder GRR
• Netflow-Analyse — AWS Cloudwatch + AWS VPC Flow
• DNS-Analyse — AWS Cloudwatch + AWS Route53
• AD — AWS Directory Service
• Kontoverwaltung — AWS IAM
• SSO — AWS SSO
• Sicherheitsanalyse — AWS Inspector
• Konfigurationsmanagement — AWS Config
• WAF — AWS WAF.

Ich werde nicht alle Amazon-Dienste im Detail beschreiben, die im Bereich Informationssicherheit nützlich sein können. Das Wichtigste, was zu verstehen ist, ist, dass alle diese Dienste Ereignisse generieren können, die wir analysieren sollten, indem wir sowohl die eingebauten Funktionen von Amazon als auch externe Lösungen wie SIEM nutzen, die Sicherheitsereignisse in Ihr Monitoring-Center übernehmen und zusammen mit Ereignissen anderer Cloud-Dienste oder aus interner Infrastruktur, dem Perimeter oder mobilen Geräten analysieren.

In jedem Fall beginnt alles mit den Datenquellen, die Ihnen Sicherheitsereignisse bereitstellen. Zu diesen Quellen gehören unter anderem:

• CloudTrail – Nutzung von APIs und Benutzeraktionen
• Trusted Advisor – Sicherheitsüberprüfung anhand bewährter Praktiken
• Config – Inventarisierung und Konfiguration von Konten und Diensteinstellungen
• VPC Flow Logs – Verbindungen zu virtuellen Schnittstellen
• IAM – Identifizierungs- und Authentifizierungsdienst
• ELB Access Logs – Lastenausgleichsprotokolle
• Inspector – Schwachstellen in Anwendungen
• S3 – Dateispeicher
• CloudWatch – Anwendungsaktivität
• SNS – Benachrichtigungsdienst.

Amazon, mit einem breiten Spektrum an Ereignisquellen und Werkzeugen zur deren Generierung, hat jedoch erhebliche Einschränkungen in der Analyse der gesammelten Daten im Kontext der Informationssicherheit. Sie müssen die vorhandenen Protokolle selbst durchsehen und nach relevanten Indikatoren für Kompromittierungen suchen. Der AWS Security Hub, den Amazon kürzlich eingeführt hat, soll dieses Problem lösen, indem er als eine Art Cloud-SIEM für AWS fungiert. Er steht jedoch noch am Anfang seiner Entwicklung und ist sowohl in der Anzahl der unterstützten Quellen als auch durch andere, von der Architektur und den Abonnements von Amazon auferlegte, Einschränkungen limitiert.

Beispiel: Informationssicherheitsüberwachung in IaaS auf Basis von Azure

Ich möchte nicht in eine lange Debatte eintreten, welcher der drei Cloud-Anbieter (Amazon, Microsoft oder Google) der beste ist (insbesondere da jeder von ihnen seine eigenen spezifischen Merkmale hat und für verschiedene Aufgaben geeignet ist); lassen Sie uns auf die Möglichkeiten zur Überwachung der Informationssicherheit konzentrieren, die diese Anbieter bieten. Es ist anzuerkennen, dass Amazon AWS einer der ersten in diesem Segment war und daher in Bezug auf seine Sicherheitsfunktionen weiter fortgeschritten ist (obwohl viele anerkennen, dass die Nutzung dieser Funktionen kompliziert sein kann). Aber das bedeutet nicht, dass wir die Möglichkeiten, die Microsoft und Google uns bieten, ignorieren sollten.

Die Microsoft-Produkte sind für ihre "Offenheit" bekannt, und Azure bildet da keine Ausnahme. Während AWS und GCP stets das Prinzip "alles, was nicht erlaubt ist, ist verboten" verfolgen, ist der Ansatz bei Azure genau umgekehrt. Zum Beispiel sind bei der Erstellung eines virtuellen Netzwerks in der Cloud und einer virtuellen Maschine darin standardmäßig alle Ports und Protokolle offen und erlaubt. Daher müssen Sie etwas mehr Aufwand in die ursprüngliche Konfiguration des Zugriffsmanagements in der Microsoft-Cloud investieren. Dies führt zudem zu strengeren Anforderungen an das Monitoring der Aktivitäten in Azure.

AWS hat eine Besonderheit: Wenn Sie Ihre virtuellen Ressourcen überwachen und diese sich in verschiedenen Regionen befinden, kann es schwierig werden, alle Ereignisse zu konsolidieren und einheitlich zu analysieren. Dies erfordert oft komplizierte Lösungen, wie z.B. das Erstellen eigener AWS Lambda-Codes, um Ereignisse zwischen den Regionen zu übertragen. In Azure gibt es dieses Problem nicht – das Activity Log verfolgt sämtliche Aktivitäten innerhalb der gesamten Organisation ohne Einschränkungen. Dasselbe gilt für den AWS Security Hub, der kürzlich von Amazon entwickelt wurde, um viele Sicherheitsfunktionen innerhalb eines zentralen Sicherheitszentrums zu konsolidieren, aber nur im Rahmen seiner Region, was für Russland nicht relevant ist. Azure bietet ein eigenes Security Center, das keinen regionalen Einschränkungen unterliegt und Zugang zu allen Sicherheitsfunktionen der Cloud-Plattform bietet. Darüber hinaus kann es für verschiedene lokale Teams eine eigene Reihe von Sicherheitsfunktionen bereitstellen, einschließlich verwalteter Sicherheitsereignisse. Der AWS Security Hub strebt erst noch danach, dem Azure Security Center ähnlich zu werden. Allerdings gibt es einen Wermutstropfen: Man kann aus Azure viel herausholen, was zuvor bei AWS beschrieben wurde, aber dies lässt sich am bequemsten nur für Azure AD, Azure Monitor und Azure Security Center umsetzen. Alle anderen Sicherheitsmechanismen von Azure, einschließlich der Analyse von Sicherheitsereignissen, werden derzeit noch nicht optimal verwaltet. Teilweise löst das API-Management, das alle Microsoft Azure-Dienste durchdringt, dieses Problem, aber das erfordert zusätzlichen Aufwand, um Ihre Cloud mit Ihrem SOC zu integrieren und qualifiziertes Personal zu haben (wie bei jeder anderen SIEM, die mit Cloud-APIs arbeitet). Einige SIEM, auf die später eingegangen wird, unterstützen bereits Azure und können die Überwachungsaufgabe automatisieren, aber auch dies hat seine Tücken – nicht alle können sämtliche Protokolle abrufen, die Azure zur Verfügung stellt.

Die Ereignissammlung und -überwachung in Azure erfolgt über den Dienst Azure Monitor. Dies ist das zentrale Werkzeug zur Sammlung, Speicherung und Analyse von Daten in der Microsoft-Cloud und deren Ressourcen — wie Git-Repositorys, Containern, virtuellen Maschinen, Anwendungen usw. Alle von Azure Monitor gesammelten Daten werden in zwei Kategorien unterteilt: Echtzeitmetriken, die die wichtigsten Leistungsindikatoren von Azure Cloud beschreiben, und Protokollnachrichten, die Daten in strukturierten Einträgen enthalten, die bestimmte Aspekte der Aktivitäten von Azure-Ressourcen und -diensten charakterisieren. Darüber hinaus kann der Azure Monitor über die Data Collector API Daten von jeder REST-Quelle erfassen, um eigene Überwachungsszenarien zu erstellen.

Hier sind einige Sicherheitsereignisquellen, die Azure Ihnen bietet und auf die Sie über das Azure Portal, CLI, PowerShell oder REST API zugreifen können (einige nur über Azure Monitor / Insight API):

• Aktivitätsprotokolle — dieses Protokoll beantwortet grundlegende Fragen wie „wer“, „was“ und „wann“ in Bezug auf jede Aufzeichnungsoperation (PUT, POST, DELETE) an Cloud-Ressourcen. Ereignisse, die mit Lesezugriff (GET) auf dieses Protokoll verbunden sind, werden nicht erfasst, ebenso wie eine Reihe anderer.
• Diagnoseprotokolle — enthält Daten zu Operationen mit einem bestimmten Ressourcenteil Ihrer Abonnements.
• Azure AD-Bereichte — zeigt sowohl Benutzeraktivität als auch systembezogene Aktivitäten, die mit der Verwaltung von Gruppen und Benutzern verbunden sind.
• Windows-Ereignisprotokoll und Linux-Syslog — enthält Ereignisse von den virtuellen Maschinen, die in der Cloud gehostet werden.
• Metriken — enthält Telemetrie über die Leistungsfähigkeit und den "Zustand" Ihrer Cloud-Services und Ressourcen. Diese werden minütlich gemessen und 30 Tage lang gespeichert.
• Flow-Protokolle der Netzwerksicherheitsgruppe — enthält Sicherheitsereignisdaten, die durch den Network Watcher und das Monitoring von Ressourcen auf Netzwerkebene gesammelt werden.
• Speicherprotokolle — enthält Ereignisse, die mit dem Zugriff auf Speicher verbunden sind.

Für das Monitoring können Sie externe SIEM-Systeme oder den integrierten Azure Monitor sowie dessen Erweiterungen nutzen. Über die Systeme zur Verwaltung von Sicherheitsereignissen werden wir später sprechen; zunächst schauen wir uns an, was Azure selbst für die Datenanalyse im Sicherheitskontext bietet. Der Hauptbildschirm für alles, was mit Sicherheit im Azure Monitor zu tun hat, ist das Log Analytics Sicherheits- und Auditch Dashboard (die kostenlose Version unterstützt die Speicherung einer begrenzten Anzahl von Ereignissen nur eine Woche lang). Dieses Dashboard ist in 5 Hauptbereiche unterteilt, die zusammenfassende Statistiken darüber visualisieren, was in Ihrer genutzten Cloud-Umgebung passiert:

• Security Domains – wichtige Kennzahlen im Zusammenhang mit der Informationssicherheit, wie die Anzahl der Vorfälle, die Anzahl der kompromittierten Knoten, der nicht gepatchten Knoten, Sicherheitsereignisse im Netzwerk usw.
• Notable Issues – zeigt die Anzahl und die Dringlichkeit aktiver Informationssicherheitsprobleme an
• Detections – zeigt Muster von Angriffen, die gegen Sie verwendet wurden
• Threat Intelligence – zeigt geografische Informationen über externe Knoten an, die Sie angreifen
• Common security queries – typische Anfragen, die Ihnen helfen, Ihre Informationssicherheit besser zu überwachen.

Zu den Erweiterungen von Azure Monitor gehören Azure Key Vault (Schutz kryptographischer Schlüssel in der Cloud), Malware Assessment (Analyse des Schutzes vor Schadsoftware auf virtuellen Maschinen), Azure Application Gateway Analytics (Analyse unter anderem der Protokolle der Cloud-Firewall) usw. Diese Werkzeuge, ergänzt durch bestimmte Regeln zur Ereignisverarbeitung, ermöglichen es, verschiedene Aspekte der Cloud-Dienste, einschließlich der Sicherheit, zu visualisieren und Abweichungen im Betrieb zu identifizieren. Wie so oft erfordert jedoch jede zusätzliche Funktionalität ein entsprechendes kostenpflichtiges Abonnement, was von Ihnen eine finanzielle Planung im Voraus verlangt.

Azure bietet eine Vielzahl integrierter Bedrohungsüberwachungsfunktionen, die in Azure AD, Azure Monitor und Azure Security Center integriert sind. Dazu gehören unter anderem die Erkennung von Verbindungen virtueller Maschinen mit bekannten schädlichen IPs (durch die Integration mit Microsofts Threat Intelligence-Diensten), die Erkennung von Malware in der Cloud-Infrastruktur dank Alarmmeldungen von virtuellen Maschinen, die in der Cloud gehostet werden, Brute-Force-Angriffe auf virtuelle Maschinen, Schwachstellen in der Konfiguration von Identitätssystemen, Anmeldungen über Anonymisierungsdienste oder kompromittierte Knoten, das Leakin von Konten, Anmeldungen von ungewöhnlichen Standorten usw. Azure ist heute einer der wenigen Cloud-Anbieter, der Ihnen integrierte Threat Intelligence-Funktionen zur Verfügung stellt, um die gesammelten Sicherheitsereignisse zu bereichern.

Wie bereits erwähnt, steht die Sicherheitsfunktionalität und die dadurch generierten Sicherheitsereignisse nicht allen Benutzern gleich zur Verfügung. Es wird ein spezifisches Abonnement benötigt, das die gewünschten Funktionen beinhaltet und die entsprechenden Ereignisse zur Überwachung der Informationssicherheit generiert. Beispielsweise sind einige der im vorherigen Absatz beschriebenen Funktionen zur Überwachung von Anomalien in Benutzerkonten nur mit der Premium-Lizenz P2 für den Azure AD-Dienst verfügbar. Ohne diese müssen Sie, ähnlich wie bei AWS, die gesammelten Sicherheitsereignisse "manuell" analysieren. Je nach Art der Lizenz für Azure AD sind Ihnen außerdem nicht alle Ereignisse zur Analyse zugänglich.

Im Azure-Portal können Sie sowohl Suchanfragen zu den für Sie interessanten Protokollen verwalten als auch Dashboards zur Visualisierung der wichtigsten Informationssicherheitskennzahlen einrichten. Darüber hinaus können Sie dort Azure Monitor-Erweiterungen auswählen, die Ihnen helfen, die Funktionalität der Azure Monitor-Logs zu erweitern und eine tiefere Analyse von Ereignissen aus sicherheitstechnischer Sicht zu erhalten.

Wenn Sie nicht nur die Möglichkeit benötigen, mit Logs zu arbeiten, sondern auch ein umfassendes Sicherheitszentrum für Ihre Azure-Cloud-Plattform, einschließlich des Managements von Sicherheitsrichtlinien, sollten Sie das Azure Security Center in Betracht ziehen. Viele nützliche Funktionen sind kostenpflichtig, wie z. B. Bedrohungserkennung, Überwachung außerhalb von Azure und Compliance-Evaluierung. (In der kostenlosen Version erhalten Sie nur Sicherheitsbewertungen und Empfehlungen zur Behebung festgestellter Probleme.) Es konsolidiert alle Sicherheitsfragen an einem Ort. Im Grunde können wir von einem höheren Sicherheitsniveau sprechen, als es der Azure Monitor bietet, da in diesem Fall die gesammelten Daten aus Ihrem gesamten Cloud-Setup mit Informationen aus verschiedenen Quellen angereichert werden, wie Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, der Microsoft Digital Crimes Unit (DCU) und dem Microsoft Security Response Center (MSRC). Diese Informationen werden durch komplexe Algorithmen für maschinelles Lernen und Verhaltensanalysen verbessert, was letztendlich die Effizienz der Bedrohungserkennung und -reaktion erhöhen sollte.

Azure verfügt ebenfalls über ein eigenes SIEM, das Anfang 2019 eingeführt wurde: Azure Sentinel. Dieses nutzt Daten von Azure Monitor und kann zusätzlich mit externen Sicherheitslösungen (wie NGFW oder WAF) integriert werden, deren Liste stetig erweitert wird. Darüber hinaus ermöglicht die Integration der Microsoft Graph Security API, eigene Threat Intelligence-Feeds mit Sentinel zu verbinden, was die Analyse von Vorfällen in Ihrer Azure-Cloud verbessert. Es lässt sich sagen, dass Azure Sentinel das erste "native" SIEM ist, das bei Cloud-Anbietern eingeführt wurde (im Gegensatz zu Splunk oder ELK, die zwar in der Cloud gehostet werden können, jedoch nicht von Anbietern traditioneller Cloud-Dienste stammen). Azure Sentinel und das Security Center könnten als SOC für die Azure-Cloud betrachtet werden und man könnte sich damit zufrieden geben (mit gewissen Einschränkungen), wenn Sie keinerlei weitere Infrastruktur hätten und alle Ihre Rechenressourcen in die Cloud verlagert hätten, die in diesem Fall Microsoft Azure wäre.

Da die integrierten Funktionen von Azure (selbst mit einem Sentinel-Abonnement) häufig nicht ausreichen, um die Überwachung der Informationssicherheit zu gewährleisten und diesen Prozess mit anderen Sicherheitsereignisquellen (sowohl Cloud- als auch interne Quellen) zu integrieren, besteht die Notwendigkeit, die gesammelten Daten in externe Systeme zu exportieren, zu denen auch SIEM gehören kann. Dies erfolgt sowohl über APIs als auch über spezielle Erweiterungen, die derzeit offiziell nur bei den folgenden SIEM verfügbar sind: Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight und ELK. Bis vor kurzem gab es mehr solcher SIEM, doch seit dem 1. Juni 2019 hat Microsoft die Unterstützung für das Azure Log Integration Tool (AzLog) eingestellt, das in den Anfangstagen von Azure und in der Abwesenheit einer ordentlichen Standardisierung für die Log-Verarbeitung (Azure Monitor war damals noch nicht vorhanden) die einfache Integration externer SIEM mit der Microsoft-Cloud ermöglichte. Die Situation hat sich jetzt geändert, und Microsoft empfiehlt die Plattform Azure Event Hub als primäres Integrationswerkzeug für andere SIEM. Viele haben bereits eine solche Integration realisiert, aber seien Sie vorsichtig: Sie erfassen möglicherweise nicht alle Azure-Logs, sondern nur einige (siehe die Dokumentation für Ihr SIEM).

Abschließend möchte ich einen kurzen Überblick über Azure geben und eine allgemeine Empfehlung für diesen Cloud-Service aussprechen. Bevor Sie etwas zu den Überwachungsfunktionen von Azure sagen, sollten Sie diese sehr sorgfältig einrichten und testen, ob sie so funktionieren, wie es in der Dokumentation beschrieben wird, und wie es Ihnen von Microsoft-Beratern mitgeteilt wurde (die möglicherweise unterschiedliche Ansichten zur Funktionsweise der Azure-Funktionen haben). Wenn die finanziellen Mittel zur Verfügung stehen, können Sie aus Azure im Bereich der Sicherheitsüberwachung sehr viel Nützliches herausholen. Wenn Ihre Ressourcen jedoch begrenzt sind, müssen Sie, ähnlich wie bei AWS, nur auf Ihre eigenen Fähigkeiten und die Rohdaten zurückgreifen, die Ihnen Azure Monitor bietet. Denken Sie daran, dass viele Überwachungsfunktionen kostenpflichtig sind, und es ist ratsam, sich im Voraus mit der Preisgestaltung vertraut zu machen. Beispielsweise können Sie Daten bis zu 31 Tagen kostenlos speichern, jedoch nicht mehr als 5 GB pro Kunde. Eine Überschreitung dieser Werte wird zusätzliche Kosten verursachen (ungefähr 2+ Dollar für die Speicherung jedes zusätzlichen GB ab dem Kunden und 0,1 Dollar für die Speicherung von 1 GB pro zusätzlichem Monat). Der Umgang mit Anwendungs-Telemetrie und Metriken kann ebenfalls zusätzliche finanzielle Mittel erfordern, ebenso wie die Verwaltung von Alarmen und Benachrichtigungen (ein gewisses Limit steht kostenlos zur Verfügung, das möglicherweise nicht ausreicht, um Ihre Bedürfnisse zu decken).

Beispiel: Sicherheitsüberwachung in IaaS basierend auf Google Cloud Platform

Die Google Cloud Platform erscheint im Vergleich zu AWS und Azure noch relativ neu, was jedoch auch positiv ist. Anders als AWS, das seine Funktionen, einschließlich der Sicherheitsfeatures, schrittweise und oft mit Problemen bei der Zentralisierung erweitert hat, wird GCP, ähnlich wie Azure, zentraler verwaltet, was die Fehlerquote reduziert und die Implementierungszeiten im Unternehmen verkürzt. In Bezug auf die Sicherheit liegt GCP erstaunlicherweise zwischen AWS und Azure. Es verfügt ebenfalls über eine organisationsweite Ereignisregistrierung, die jedoch nicht vollständig ist. Einige Funktionen sind noch im Beta-Status, aber allmählich wird dieser Nachteil behoben werden, sodass GCP eine reifere Plattform für die Sicherheitsüberwachung wird.

Das Hauptwerkzeug zur Ereignisregistrierung in GCP ist Stackdriver Logging (ähnlich wie Azure Monitor), das es Ihnen ermöglicht, Ereignisse in Ihrer gesamten Cloud-Infrastruktur (einschließlich AWS) zu sammeln. In Bezug auf die Sicherheit verfügt in GCP jede Organisation, jedes Projekt oder jeder Ordner über vier Protokolle zur Ereignisregistrierung:

• Admin-Aktivität — enthält alle Ereignisse, die mit administrativem Zugriff verbunden sind, wie das Erstellen von virtuellen Maschinen, das Ändern von Zugriffsrechten usw. Dieses Protokoll wird immer aufgezeichnet, unabhängig von Ihrem Wunsch, und speichert seine Daten für 400 Tage.
• Datenzugriff — enthält alle Ereignisse, die mit der Arbeit von cloudbasierten Benutzern zu tun haben (Erstellung, Änderung, Lesen usw.). Standardmäßig wird dieses Protokoll nicht aufgezeichnet, da sein Volumen sehr schnell anwächst. Aus diesem Grund beträgt die Aufbewahrungsfrist nur 30 Tage. Darüber hinaus werden in dieses Protokoll nicht alle Ereignisse geschrieben. Zum Beispiel werden Ereignisse, die mit öffentlich zugänglichen Ressourcen für alle Benutzer verbunden sind oder die ohne Anmeldung in GCP zugänglich sind, nicht erfasst.
• Systemereignis — enthält systemische Ereignisse, die nicht mit Benutzern verbunden sind, oder Aktionen des Administrators, der die Konfiguration der Cloud-Ressourcen ändert. Es wird immer aufgezeichnet und für 400 Tage gespeichert.
• Access Transparency ist ein einzigartiges Beispiel für ein Protokoll, das alle Aktivitäten von Google-Mitarbeitern (bisher nicht für alle GCP-Dienste) dokumentiert, die im Rahmen ihrer beruflichen Pflichten auf Ihre Infrastruktur zugreifen. Dieses Protokoll wird 400 Tage lang gespeichert und ist nicht für jeden GCP-Kunden zugänglich, sondern nur unter bestimmten Bedingungen (entweder Gold- oder Platin-Support oder das Vorhandensein von vier bestimmten Rollen im Rahmen des Unternehmenssupports). Eine ähnliche Funktion gibt es auch in Office 365 – Lockbox.

Beispielprotokoll: Access Transparency

{
 insertId: "abcdefg12345"
 jsonPayload: {
 @type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
 principalOfficeCountry: "US"
 principalEmployingEntity: "Google LLC"
 principalPhysicalLocationCountry: "CA"
 }
 product: [
 0: "Cloud Storage"
 ]
 reason: [
 detail: "Fallnummer: bar123"
 type: "KUNDEN_INITIERTER_SUPPORT"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "HINWEIS"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

Der Zugriff auf die angegebenen Protokolle ist auf mehreren Wegen möglich (ähnlich wie bei den zuvor besprochenen Azure und AWS) – über die Benutzeroberfläche des Log Viewers, über die API, über das Google Cloud SDK oder über die Aktivitätsseite Ihres Projekts, für das Sie sich für Ereignisse interessieren. Ebenso können diese Protokolle exportiert werden, um sie in externe Lösungen für eine zusätzliche Analyse zu nutzen. Dies geschieht durch den Export der Protokolle in den BigQuery-Speicher oder Cloud Pub/Sub.

Neben Stackdriver Logging bietet die GCP-Plattform auch die Funktionalität von Stackdriver Monitoring, mit der Sie wichtige Kennzahlen (Leistung, Ausfallzeiten, allgemeiner Zustand usw.) von Cloud-Diensten und Anwendungen überwachen können. Die speziell aufbereiteten und visualisierten Daten können helfen, Probleme in Ihrer Cloud-Infrastruktur zu identifizieren, auch im Hinblick auf Sicherheitsaspekte. Es ist jedoch zu beachten, dass die Funktionen in Bezug auf Informationssicherheit aktuell eher begrenzt sind, da GCP derzeit kein Pendant zu AWS GuardDuty bietet und nicht in der Lage ist, schädliche Aktivitäten unter den erfassten Ereignissen zu kennzeichnen (Google hat Event Threat Detection entwickelt, aber es befindet sich noch in der Beta-Phase, sodass es früh ist, über seine Nützlichkeit zu sprechen). Stackdriver Monitoring könnte als System zur Erkennung von Anomalien verwendet werden, die dann näher untersucht werden, um die Ursachen zu ermitteln. Angesichts des aktuellen Mangels an qualifiziertem Personal im Bereich Informationssicherheit auf dem Markt erscheint diese Aufgabe derzeit als recht herausfordernd.

Es lohnt sich, eine Liste einiger Sicherheitsmodule zusammenzustellen, die in Ihrem GCP-Cloud-Umfeld verwendet werden können und die mit dem Angebot von AWS vergleichbar sind:

• Cloud Security Command Center – das Pendant zu AWS Security Hub und Azure Security Center.
• Cloud DLP – automatisches Erkennen und Bearbeiten (z. B. Maskierung) von Daten, die in der Cloud gespeichert sind, basierend auf mehr als 90 vordefinierten Klassifikationsrichtlinien.
• Cloud Scanner – Scanner für bekannte Sicherheitsanfälligkeiten (XSS, Flash Injection, nicht gepatchte Bibliotheken usw.) in App Engine, Compute Engine und Google Kubernetes.
• Cloud IAM – Zugriffskontrolle für alle GCP-Ressourcen.
• Cloud Identity – Verwaltung von Benutzerkonten, Geräten und Anwendungen in GCP über ein zentrales Dashboard.
• Cloud HSM – Schutz kryptografischer Schlüssel.
• Cloud Key Management Service – Verwaltung von kryptografischen Schlüsseln in GCP.
• VPC Service Control – Schaffung eines sicheren Perimeters um Ihre GCP-Ressourcen, um sie vor Datenlecks zu schützen.
• Titan Security Key – Schutz vor Phishing.

Viele dieser Module erzeugen Sicherheitsereignisse, die in den BigQuery-Speicher zur Analyse oder zum Export in andere Systeme, einschließlich SIEM, gesendet werden können. Wie bereits erwähnt, handelt es sich bei GCP um eine aktiv weiterentwickelte Plattform, und Google entwickelt derzeit eine Reihe neuer Module zur Informationssicherheit für seine Plattform. Dazu gehört unter anderem die Event Threat Detection (derzeit in der Beta-Phase), die Stackdriver-Logs auf Anzeichen unbefugter Aktivitäten scannt (vergleichbar mit GuardDuty in AWS), sowie das Policy Intelligence (verfügbar in der Alpha-Phase), das die Entwicklung intelligenter Zugriffspolitiken für GCP-Ressourcen ermöglichen wird.

Ich habe einen kleinen Überblick über die integrierten Überwachungsmöglichkeiten in beliebten Cloud-Plattformen erstellt. Haben Sie jedoch Experten, die mit „rohen“ IaaS-Logs des Anbieters umgehen können (nicht alle sind bereit, erweiterte Funktionen von AWS, Azure oder Google zu erwerben)? Darüber hinaus ist vielen die Redewendung „Vertraue, aber prüfe“ bekannt, die im Bereich Sicherheit so relevant ist wie nie. Wie sehr vertrauen Sie den integrierten Möglichkeiten des Cloud-Anbieters, der Ihnen Sicherheitsereignisse bereitstellt? Inwieweit fokussieren sie sich tatsächlich auf Informationssicherheit?

Manchmal lohnt es sich, Lösungen für das Monitoring von Cloud-Infrastrukturen in Betracht zu ziehen, die die integrierte Sicherheit der Cloud ergänzen können. In einigen Fällen sind solche Lösungen die einzige Möglichkeit, um Sicherheitsdaten zu Ihren in der Cloud gehosteten Daten und Anwendungen zu erhalten. Zudem sind sie äußerst praktisch, da sie alle Aufgaben zur Analyse der benötigten Protokolle, die von verschiedenen Cloud-Diensten unterschiedlicher Anbieter generiert werden, übernehmen. Ein Beispiel für eine solche Lösung ist Cisco Stealthwatch Cloud, die sich auf die Überwachung von Sicherheitsanomalien in Cloud-Umgebungen konzentriert. Dazu gehören nicht nur Amazon AWS, Microsoft Azure und Google Cloud Platform, sondern auch private Clouds.

Beispiel: Sicherheitsüberwachung mit Stealthwatch Cloud

AWS bietet eine flexible Plattform für Berechnungen, doch diese Flexibilität kann dazu führen, dass Unternehmen leichter Fehler machen, die Sicherheitsprobleme verursachen. Das geteilte Sicherheitsmodell trägt nur zur Verwirrung bei. Der Einsatz von Software in der Cloud mit unbekannten Schwachstellen (bekannte Schwachstellen können zum Beispiel von AWS Inspector oder GCP Cloud Scanner bekämpft werden), schwache Passwörter, falsche Konfigurationen, Insider und Ähnliches sind häufige Herausforderungen. All dies beeinflusst das Verhalten der Cloud-Ressourcen, die von Cisco Stealthwatch Cloud überwacht werden, einem System zur Sicherheitsüberwachung und Angriffserkennung in öffentlichen und privaten Clouds.

Eine der zentralen Funktionen von Cisco Stealthwatch Cloud ist die Möglichkeit zur Modellierung von Entitäten. Damit können Sie ein Softwaremodell (also eine nahezu Echtzeit-Simulation) Ihrer Cloud-Ressourcen erstellen, unabhängig davon, ob es sich um AWS, Azure, GCP oder etwas anderes handelt. Dazu gehören Server und Nutzer sowie ressourcenspezifische Typen in Ihrer Cloud-Umgebung, wie Sicherheitsgruppen und Auto-Scaling-Gruppen für Dienste. Diese Modelle verwenden strukturierte Datenströme, die von den Cloud-Diensten bereitgestellt werden, als Eingabewerte. Beispielsweise umfassen die Daten für AWS VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda und AWS IAM. Die Entitätsmodellierung erkennt automatisch die Rolle und das Verhalten Ihrer Ressourcen (man kann von einer Profilierung aller Cloud-Aktivitäten sprechen). Zu diesen Rollen gehören mobile Geräte (Android oder Apple), Citrix PVS-Server, RDP-Server, Mailgateways, VoIP-Clients, Terminalserver, Domänencontroller usw. Anschließend verfolgt es kontinuierlich deren Verhalten, um festzustellen, wann riskantes oder bedrohliches Verhalten auftritt. Sie können Brute-Force-Angriffe, DDoS-Attacken, Datenlecks, unerlaubten Remote-Zugriff, schadhafter Code, Schwachstellenscans und andere Bedrohungen identifizieren. Zum Beispiel so sieht die Erkennung eines Versuchs des Remote-Zugriffs aus einem für Ihre Organisation untypischen Land (Südkorea) auf ein Kubernetes-Cluster über SSH aus:

So sieht die vermutete Datenleckage aus einer Postgres-Datenbank in ein bisher unbekanntes Land aus:

Hier sind die übermäßig vielen fehlgeschlagenen SSH-Zugriffsversuche aus China und Indonesien von einem externen Remote-Gerät:

Angenommen, ein Serverexemplar in einer VPC sollte gemäß den Richtlinien niemals als Ziel für den Remote-Zugriff dienen. Nehmen wir weiterhin an, dass auf diesem Computer ein Remote-Zugriff aufgrund einer fehlerhaften Regeländerung in der Firewall-Policy erfolgt ist. Die Entity-Modellierungsfunktion wird diese Aktivität („Ungewöhnlicher Remote-Zugriff“) nahezu in Echtzeit erkennen und melden und auf den spezifischen AWS CloudTrail API-Aufruf, Azure Monitor oder GCP Stackdriver Logging hinweisen (einschließlich Benutzername, Datum und Uhrzeit sowie weiteren Details), der die Regeländerung in der Firewall-Policy verursacht hat. Diese Informationen können dann an ein SIEM zur Analyse übergeben werden.

Ähnliche Möglichkeiten werden für jede Cloud-Umgebung umgesetzt, die von Cisco Stealthwatch Cloud unterstützt wird:

Entity Modeling ist eine einzigartige Form der Sicherheitsautomatisierung, die in der Lage ist, zuvor unbekannte Probleme mit Ihren Personen, Prozessen oder Technologien zu erkennen. Beispielsweise ermöglicht sie die Identifizierung von Sicherheitsproblemen wie:

• Hat jemand eine Hintertür in der Software entdeckt, die wir verwenden?
• Gibt es irgendwelche Drittanbieter-Software oder -Geräte in unserem Cloud-Umfeld?
• Missbraucht ein autorisierter Benutzer seine Berechtigungen?
• Gab es einen Konfigurationsfehler, der Remote-Zugriff oder eine andere unbeabsichtigte Nutzung von Ressourcen ermöglicht?
• Gibt es Datenlecks von unseren Servern?
• Hat jemand versucht, sich von einem ungewöhnlichen geografischen Standort aus mit uns zu verbinden?
• Ist unsere Cloud mit Malware infiziert?

Das entdeckte Sicherheitsereignis kann als entsprechendes Ticket in Slack, Cisco Spark, dem Incident-Management-System PagerDuty übermittelt und an verschiedene SIEMs wie Splunk oder ELK weitergeleitet werden. Zusammenfassend lässt sich sagen, dass, wenn Ihr Unternehmen eine Multi-Cloud-Strategie verfolgt und sich nicht auf einen bestimmten Cloud-Anbieter beschränkt, die oben beschriebenen Möglichkeiten zur Überwachung von Sicherheitsereignissen eine Verwendung von Cisco Stealthwatch Cloud in Betracht gezogen werden sollte. Dieses Tool bietet eine einheitliche Lösung zur Überwachung führender Cloud-Anbieter – Amazon, Microsoft und Google. Interessanterweise kann es sein, dass die Preise für Stealthwatch Cloud im Vergleich zu den fortgeschrittenen Überwachungs-Lizenzen in AWS, Azure oder GCP sogar günstiger sind als die integrierten Funktionen der Lösungen von Amazon, Microsoft und Google. Paradoxerweise ist das so. Je mehr Clouds und deren Funktionen Sie nutzen, desto offensichtlicher wird der Vorteil einer konsolidierten Lösung.

Darüber hinaus kann Stealthwatch Cloud private Clouds überwachen, die in Ihrer Organisation bereitgestellt werden, beispielsweise auf Basis von Kubernetes-Containern oder durch die Überwachung von Netflow-Datenströmen oder Netzwerktraffic, der über die Spiegelung in Netzwerkhardware (auch von inländischer Produktion) erfasst wird, sowie von AD- oder DNS-Serverdaten usw. Alle diese Informationen werden mit Bedrohungsintelligenz angereichert, die von Cisco Talos, der weltweit größten unabhängigen Gruppe von Cybersicherheitsforschern, gesammelt wird.

Dies ermöglicht es Ihnen, ein einheitliches Überwachungssystem sowohl für öffentliche als auch für hybride Clouds zu implementieren, die Ihr Unternehmen nutzen kann. Die gesammelten Informationen können dann entweder mit den integrierten Funktionen von Stealthwatch Cloud analysiert oder an Ihr SIEM gesendet werden (standardmäßig werden Splunk, ELK, SumoLogic und mehrere andere unterstützt).

Damit beenden wir den ersten Teil des Artikels, in dem ich die integrierten und externen Tools zur Überwachung der IT-Sicherheit von IaaS/PaaS-Plattformen betrachtet habe, die es uns ermöglichen, Vorfälle in den Cloud-Umgebungen, die unser Unternehmen gewählt hat, schnell zu erkennen und darauf zu reagieren. Im zweiten Teil werden wir das Thema weiterführen und die Überwachungsmöglichkeiten von SaaS-Plattformen am Beispiel von Salesforce und Dropbox untersuchen und versuchen, alles zusammenzufassen, um ein einheitliches Überwachungssystem für die IT-Sicherheit verschiedener Cloud-Anbieter zu schaffen.

Quelle: habr.com