Ü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 bereit sind, die Infrastruktur Dritter zu überwachen. Laut Netoskope nutzt ein durchschnittliches Unternehmen (offensichtlich doch in den USA) 1246 verschiedene Cloud-Dienste, was ein Anstieg von 22 % im Vergleich zum Vorjahr bedeutet. 1246 Cloud-Dienste!!! 175 davon betreffen HR-Services, 170 stehen im Zusammenhang mit Marketing, 110 in der Kommunikationsbranche und 76 im Finanz- und CRM-Bereich. Bei Cisco werden "nur" 700 externe Cloud-Dienste verwendet. Daher verwundern mich diese Zahlen ein wenig. Aber das Problem liegt nicht in den Zahlen, sondern darin, dass immer mehr Unternehmen die Cloud aktiv zu nutzen beginnen, die dieselben Überwachungsmöglichkeiten für die Cloud-Infrastruktur wünschen, wie sie in ihrem eigenen Netzwerk vorhanden sind. Diese Tendenz nimmt zu — laut den Daten des amerikanischen Rechnungshofes sollen bis 2023 in den USA 1200 Rechenzentren geschlossen werden (6250 wurden bereits geschlossen). Der Übergang zur Cloud ist jedoch nicht einfach "lass uns unsere Server zu einem externen Anbieter transferieren". Eine neue IT-Architektur, neue Software, neue Prozesse, neue Einschränkungen… All dies bringt erhebliche Änderungen in die Arbeitsweise nicht nur der IT, sondern auch der IT-Sicherheit. Und während die Anbieter gelernt haben, wie sie die Sicherheit der Cloud selbst gewährleisten können (zum Glück gibt es genügend Empfehlungen), gibt es beim Cloud-Monitoring der IT-Sicherheit, besonders auf SaaS-Plattformen, erhebliche Schwierigkeiten, über die wir sprechen werden.

Angenommen, Ihr Unternehmen hat einen Teil seiner Infrastruktur in die Cloud übertragen... Stopp. So nicht. Wenn die Infrastruktur bereits übertragen ist und Sie gerade darüber nachdenken, wie Sie sie überwachen werden, haben Sie bereits verloren. Wenn es sich nicht um Amazon, Google oder Microsoft handelt (und selbst dann mit Vorbehalten), werden Sie wahrscheinlich nicht viele Möglichkeiten zur Überwachung Ihrer Daten und Anwendungen haben. Es wäre gut, wenn man Ihnen die Arbeit mit Logs ermöglichen würde. Manchmal sind Sicherheitsereignisdaten verfügbar, aber Sie haben keinen Zugang dazu. Zum Beispiel bei Office 365. Wenn Sie die günstigste Lizenz E1 haben, sind Sicherheitsereignisse für Sie überhaupt nicht zugänglich. Mit der Lizenz E3 sind Ihre Daten nur 90 Tage lang gespeichert und nur mit der E5-Lizenz sind die Logdaten für ein Jahr verfügbar (obwohl es auch hier einige Nuancen gibt, die damit zusammenhängen, dass bestimmte Funktionen zur Log-Verarbeitung separat bei Microsoft angefragt werden müssen). Übrigens ist die Lizenz E3 in Bezug auf Überwachungsfunktionen viel schwächer als der Unternehmens-Exchange. Um das gleiche Niveau zu erreichen, benötigen Sie eine Lizenz E5 oder eine zusätzliche Lizenz für Advanced Compliance, die möglicherweise zusätzliche Kosten verursacht, 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 im Zusammenhang mit der Überwachung der Cloud-IT-Sicherheit. In diesem Artikel möchte ich, ohne einen Anspruch auf Vollständigkeit zu erheben, auf einige Nuancen hinweisen, die bei der Auswahl eines Cloud-Anbieters aus sicherheitstechnischer Sicht zu berücksichtigen sind. Am Ende des Artikels wird eine Checkliste präsentiert, die Sie abarbeiten sollten, bevor Sie davon ausgehen, dass die Überwachung der Cloud-IT-Sicherheit in Ihrem Fall gelöst ist.

Es gibt mehrere typische Probleme, die zu Vorfällen in Cloud-Umgebungen führen, auf die die IT-Sicherheitsdienste nicht rechtzeitig reagieren oder sie überhaupt nicht wahrnehmen:

• Sicherheitslogs existieren nicht. Das ist eine ziemlich verbreitete Situation, besonders bei neuen Akteuren auf dem Markt für Cloud-Lösungen. Aber man sollte auf sie nicht sofort verzichten. Kleine Anbieter, insbesondere einheimische, sind sensibler für die Anforderungen der Kunden und können dringend gesuchte Funktionen umsetzen, indem sie ihren genehmigten Produkt-Roadmap anpassen. Ja, es wird kein Äquivalent zu GuardDuty von Amazon oder dem Modul „Proaktive Sicherheit“ von Bitrix sein, aber es ist zumindest etwas.
• Die IT-Sicherheit weiß nicht, wo die Protokolle gespeichert sind oder hat keinen Zugriff darauf. Hier müssen Verhandlungen mit dem Cloud-Anbieter geführt werden – möglicherweise stellt er diese Informationen zur Verfügung, wenn er den Kunden als bedeutend erachtet. Insgesamt ist es jedoch nicht ideal, wenn der Zugang zu Protokollen "auf besonderen Beschluss" gewährt wird.
• Es kann auch vorkommen, dass der Cloud-Anbieter Protokolle hat, aber nur eingeschränkte Überwachung und Ereignisprotokollierung anbietet, die nicht ausreicht, um alle Vorfälle zu erkennen. Beispielsweise könnten Ihnen nur die Protokolle von Änderungen auf der Website oder von Authentifizierungsversuchen der Benutzer übergeben werden, während andere Ereignisse, wie z. B. der Netzwerkverkehr, nicht bereitgestellt werden, was eine ganze Reihe von Ereignissen, die Versuche, Ihre Cloud-Infrastruktur zu hacken, verdeckt.
• Es gibt Protokolle, aber der Zugang ist schwer zu automatisieren, was dazu führt, dass sie nicht kontinuierlich, sondern zeitplanmäßig überwacht werden. Und wenn die Protokolle auch nicht im automatisierten Modus heruntergeladen werden können, kann der Export der Protokolle, z. B. im Excel-Format (wie bei einigen inländischen Cloud-Lösungsanbietern), dazu führen, dass die Unternehmens-IT-Abteilung nicht mit ihnen arbeiten möchte.
• Es gibt keine Protokollüberwachung. Das ist wohl der unverständlichste Grund für das Auftreten von Sicherheitsvorfällen in Cloud-Umgebungen. Die Protokolle sind zwar vorhanden und der Zugang kann automatisiert werden, aber niemand tut dies. Warum?

Das Konzept der geteilten 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 an einen professionellen Cloud-Anbieter, der sich auf deren Wartung spezialisiert hat. Auch im Bereich der Sicherheit von Cloud-Umgebungen muss diese Balance gesucht werden. Zumal je nach gewähltem Modell der Bereitstellung von Cloud-Diensten (IaaS, PaaS, SaaS) diese Balance ständig variieren wird. In jedem Fall muss man sich bewusst sein, dass alle Cloud-Anbieter heute einem sogenannten Shared-Responsibility-Modell und einer geteilten Informationssicherheit folgen. Das Cloud-System ist für einige Aspekte verantwortlich, der Kunde, der seine Daten, Anwendungen, virtuellen Maschinen und anderen Ressourcen in der Cloud hostet, für andere. Es wäre übermütig zu erwarten, dass wir, wenn wir in die Cloud wechseln, die gesamte Verantwortung auf den Anbieter abwälzen können. Doch auch die gesamte Sicherheit eigenverantwortlich beim Übergang in die Cloud zu gestalten, ist unvernünftig. Eine Balance ist notwendig, die von vielen Faktoren abhängt: der Risikomanagement-Strategie, dem Bedrohungsmodell, den beim Cloud-Anbieter vorhandenen Schutzmechanismen, der Gesetzgebung und weiteren.

Beispielsweise liegt die Klassifizierung von Daten, die in der Cloud gespeichert werden, immer in der Verantwortung des Kunden. Der Cloud-Anbieter oder ein externer Dienstleister kann ihm lediglich mit Werkzeugen zur Seite stehen, die dabei helfen, Daten in der Cloud zu kennzeichnen, Verstöße zu identifizieren, gesetzeswidrige Daten zu entfernen 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 den Kunden teilen kann. Alles, was zwischen den Daten und der physischen Infrastruktur liegt, ist Gegenstand dieser Diskussion. Beispielsweise ist die Verfügbarkeit der Cloud die Verantwortung des Anbieters, während die Konfiguration von Sicherheitsrichtlinien oder die Aktivierung von Verschlüsselung bereits in der Verantwortung des Kunden liegt. In diesem Artikel werden wir untersuchen, welche Sicherheitsüberwachungsmechanismen die verschiedenen beliebten Cloud-Anbieter in Russland heute anbieten, welche Besonderheiten ihre Anwendung hat und wann es sinnvoll ist, externe Sicherheitslösungen (wie Cisco E-mail Security) in Betracht zu ziehen, um die Möglichkeiten Ihrer Cloud im Bereich Cybersicherheit zu erweitern. In einigen Fällen, insbesondere bei der Verfolgung einer Multi-Cloud-Strategie, bleibt Ihnen keine Wahl, als externe Lösungen zur Sicherheitsüberwachung in mehreren Cloud-Umgebungen gleichzeitig zu nutzen (wie Cisco CloudLock oder Cisco Stealthwatch Cloud). In einigen Fällen werden Sie feststellen, dass der von Ihnen gewählte (oder Ihnen aufgezwungene) Cloud-Anbieter überhaupt keine Möglichkeiten zur Sicherheitsüberwachung bietet. Das ist unangenehm, aber auch wichtig, da es hilft, das Risikoniveau im Zusammenhang mit der Nutzung dieser Cloud 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 Werkzeuge zu verlassen, die Ihr Cloud-Anbieter bereitstellt,
• die Lösungen Dritter zu nutzen, die die von Ihnen genutzten IaaS-, PaaS- oder SaaS-Plattformen überwachen,
• eine eigene Infrastruktur zur Überwachung von Cloud-Umgebungen aufzubauen (nur für IaaS/PaaS-Plattformen).

Lassen Sie uns die Eigenschaften jeder dieser Optionen betrachten. Aber vorher müssen wir das allgemeine Schema verstehen, das bei der Überwachung von Cloud-Plattformen verwendet wird. Ich würde 6 grundlegende Komponenten des Überwachungsprozesses für Informationssicherheit in der Cloud hervorheben:

• Vorbereitung der Infrastruktur. Bestimmung der erforderlichen Anwendungen und Infrastruktur zur Erfassung von sicherheitsrelevanten Ereignissen, die für die Informationssicherheit wichtig sind, im Speicher.
• Sammlung. In diesem Schritt werden Sicherheitsereignisse aus verschiedenen Quellen aggregiert, um sie zur Verarbeitung, Speicherung und Analyse weiterzuleiten.
• Verarbeitung. In diesem Schritt werden die Daten transformiert und angereichert, um die anschließende Analyse zu erleichtern.
• Speicherung. Diese Komponente ist verantwortlich für die kurz- und langfristige Speicherung der gesammelten verarbeiteten und „rohen“ Daten.
• Analyse. In diesem Schritt haben Sie die Möglichkeit, Vorfälle zu erkennen und darauf sowohl automatisch als auch manuell zu reagieren.
• Berichterstattung. Diese Phase hilft, wichtige Kennzahlen für Interessengruppen (Management, Auditoren, Cloud-Anbieter, Kunden usw.) zu erstellen, die uns helfen, Entscheidungen zu treffen, z.B. Anbieterwechsel oder Stärkung der Informationssicherheit.

Ein Verständnis dieser Komponenten ermöglicht es Ihnen, schnell zu entscheiden, was Sie von Ihrem Anbieter übernehmen können und was Sie selbst oder unter Einbeziehung externer Berater erledigen müssen.

Integrierte Funktionen von Cloud-Diensten

Ich habe bereits erwähnt, dass viele Cloud-Dienste heute keine Möglichkeit zur Überwachung der Informationssicherheit (IS) bieten. Im Allgemeinen schenken sie dem Thema IS nicht viel Aufmerksamkeit. Zum Beispiel gibt es einen der beliebten russischen Dienste zur Übermittlung von Berichten an staatliche Stellen über das Internet (ich werde seinen Namen absichtlich nicht erwähnen). Der gesamte Abschnitt über die Sicherheit dieses Dienstes dreht sich um die Anwendung von zertifizierten Schutzmechanismen. Der Abschnitt zur IS eines anderen inländischen Cloud-Dienstes für die elektronische Dokumentenverarbeitung ist jedoch deutlich umfangreicher. Dort wird über Zertifikate öffentlicher Schlüssel, zertifizierte Kryptographie, Beseitigung von Web-Schwachstellen, Schutz vor DDoS-Angriffen, Einsatz von Sicherheitsrichtlinien, Backup und sogar regelmäßige IS-Audits gesprochen. Aber es wird kein Wort über die Überwachung verloren, ebenso wie über die Möglichkeit, Zugang zu IS-Ereignissen zu erhalten, die für die Kunden dieses Dienstanbieters von Interesse sein könnten.

Im Allgemeinen kann man daran, wie ein Cloud-Anbieter auf seiner Website und in der Dokumentation die Fragen der IS beschreibt, erkennen, wie ernsthaft er sich mit diesem Thema auseinandersetzt. Zum Beispiel findet man in den Handbüchern zu den Produkten "Mein Büro" kein Wort über Sicherheit, und in der Dokumentation zu dem speziellen Produkt "Mein Büro. KS3", das zum Schutz vor unbefugtem Zugriff gedacht ist, gibt es lediglich eine Aufzählung der Punkte des 17. Befehls der FSTEK, die von "Mein Büro.KS3" erfüllt werden. Es wird jedoch nicht beschrieben, wie dies umgesetzt wird und, was am wichtigsten ist, wie diese Mechanismen in die Unternehmens-IS integriert werden können. Möglicherweise gibt es solche Dokumentationen, aber ich habe sie auf der öffentlichen Website von "Mein Büro" nicht gefunden. Vielleicht habe ich einfach keinen Zugang zu diesen geheimen Informationen?

Bei dem gleichen Bitrix sieht die Situation deutlich besser aus. In der Dokumentation sind die Formate der Ereignisprotokolle beschrieben und, was interessant ist, das Protokoll von Eindringlingen, das Ereignisse enthält, die mit potenziellen Bedrohungen für die Cloud-Plattform verbunden sind. Dort können Sie die IP-Adresse, den Benutzernamen oder die Gästenamen, die Quelle des Ereignisses, die Zeit, den User-Agent, den Ereignistyp usw. abrufen. Allerdings können Sie mit diesen Ereignissen entweder über das Kontrollpanel der Cloud selbst arbeiten oder die Daten im MS Excel-Format exportieren. Es ist derzeit schwierig, die Arbeit mit den Bitrix-Protokollen zu automatisieren, sodass Sie einen Teil der Arbeit manuell erledigen müssen (Bericht exportieren und in Ihr SIEM hochladen). Aber wenn man bedenkt, dass es noch vor relativ kurzer Zeit nicht einmal diese Möglichkeit gab, ist das ein großer Fortschritt. Dabei möchte ich anmerken, dass viele ausländische Cloud-Anbieter ähnliche Funktionen "für Einsteiger" anbieten - entweder sehen Sie sich die Protokolle über das Kontrollpanel an oder exportieren die Daten zu sich (allerdings exportieren die meisten die Daten im .csv-Format und nicht in Excel).

Wenn man die Option des Fehlens von Logs außen vorlässt, bieten Cloud-Anbieter in der Regel drei Möglichkeiten zur Überwachung von Sicherheitsereignissen an – Dashboards, Datenexporte und den Zugang über API. Das erste scheint viele Probleme für Sie zu lösen, aber das ist nicht ganz richtig – bei mehreren Logs muss man zwischen den Bildschirmen umschalten, wodurch man die Übersicht verliert. Außerdem wird Ihnen der Cloud-Anbieter wahrscheinlich nicht die Möglichkeit bieten, Sicherheitsereignisse zu korrelieren und sie aus sicherheitstechnischer Sicht zu analysieren (normalerweise hat man es mit Rohdaten zu tun, mit denen man sich selbst auseinandersetzen muss). Es gibt Ausnahmen, und darüber werden wir später sprechen. Schließlich sollten Sie sich fragen, welche Ereignisse Ihr Cloud-Anbieter protokolliert, in welchem Format diese vorliegen und wie gut sie zu Ihrem Prozess der Informationssicherheit-Überwachung passen. Zum Beispiel die Identifikation und Authentifizierung von Benutzern und Gästen. Das gleiche Bitrix ermöglicht es Ihnen, für diese Ereignisdaten das Datum und die Uhrzeit des Ereignisses sowie den Benutzernamen oder Gästename (sofern das Modul “Web-Analyse” vorhanden ist), das Objekt, auf das zugegriffen wurde, und andere typische Elemente einer Website festzuhalten. Aber Unternehmens-IT-Schutzdienste benötigen möglicherweise Informationen darüber, von welchem vertrauenswürdigen Gerät der Benutzer in die Cloud eingeloggt ist (zum Beispiel wird diese Aufgabe innerhalb eines Unternehmensnetzwerks von Cisco ISE wahrgenommen). Und eine so einfache Aufgabe wie die Funktion Geo-IP, die hilft festzustellen, ob das Benutzerkonto eines Cloud-Dienstes gestohlen wurde? Und selbst wenn Ihnen der Cloud-Anbieter dies zur Verfügung stellt, ist das nicht genug. Cisco CloudLock analysiert nicht nur die Geolokation, sondern verwendet auch maschinelles Lernen, um historische Daten zu jedem Benutzer zu analysieren und verschiedene Anomalien bei Identifikations- und Authentifizierungsversuchen zu verfolgen. Eine ähnliche Funktionalität bietet nur MS Azure (bei entsprechender Subscription).

Es gibt eine weitere Herausforderung: Da die Sicherheitsüberwachung für viele Cloud-Anbieter ein neues Thema ist, mit dem sie gerade erst beginnen, ändert sich ständig etwas in ihren Lösungen. Heute haben sie eine Version der API, morgen eine andere, übermorgen die nächste. Auch darauf muss man vorbereitet sein. Das Gleiche gilt für die Funktionalität, die sich ändern kann und die bei der eigenen Sicherheitsüberwachungssystem berücksichtigt werden muss. Zum Beispiel hatte Amazon zunächst separate Dienste zur Überwachung von Ereignissen in der Cloud – AWS CloudTrail und AWS CloudWatch. Dann kam ein separater Dienst zur Überwachung von Sicherheitsereignissen – AWS GuardDuty. Nach einiger Zeit startete Amazon ein neues Verwaltungssystem, den Amazon Security Hub, das die Analyse von Daten umfasst, die von GuardDuty, Amazon Inspector, Amazon Macie und einer Reihe anderer Dienste stammen. Ein anderes Beispiel ist das Tool zur Integration von Logs von Azure mit SIEM – AzLog. Viele SIEM-Anbieter nutzten es aktiv, bis Microsoft 2018 die Entwicklung und Unterstützung einstellte, was viele Kunden, die dieses Tool verwendeten, vor Probleme stellte (wie diese gelöst wurden, werden wir später besprechen).

Deshalb verfolgen Sie aufmerksam alle Überwachungsfunktionen, die Ihr Cloud-Anbieter Ihnen bietet. Oder vertrauen Sie externen Anbietern von Lösungen, die als Vermittler zwischen Ihrem SOC und der Cloud fungieren, die Sie überwachen möchten. Ja, das wird teurer sein (obwohl nicht immer), aber Sie übertragen die gesamte Verantwortung auf fremde Schultern. Oder nicht ganz? Erinnern wir uns an das Konzept der geteilten Verantwortung und erkennen, dass wir nichts vollständig übertragen können – wir müssen selbst herausfinden, wie verschiedene Cloud-Anbieter die Sicherheitsüberwachung Ihrer Daten, Anwendungen, virtuellen Maschinen und anderer Ressourcen, die sich in der Cloud befinden, gewährleisten. Und wir beginnen damit, was Amazon in diesem Bereich anbietet.

Beispiel: Sicherheitsüberwachung in IaaS auf Basis von AWS

Ja, ich verstehe, dass Amazon nicht das beste Beispiel ist, da es sich um einen amerikanischen Service handelt, der im Rahmen der Bekämpfung von Extremismus und der Verbreitung verbotener Informationen in Russland blockiert werden kann. In diesem Beitrag möchte ich jedoch lediglich aufzeigen, wie unterschiedlich verschiedene Cloud-Plattformen hinsichtlich ihrer Überwachungsmöglichkeiten für die Informationssicherheit sind und worauf man bei der Übertragung seiner Kernprozesse in die Cloud aus Sicherheitssicht achten sollte. Wenn einige der russischen Anbieter von Cloud-Lösungen dabei etwas Nützliches für sich mitnehmen können, wäre das umso besser.

Zunächst ist zu sagen, dass Amazon keine uneinnehmbare Festung ist. Bei seinen Kunden gibt es regelmäßig verschiedene Vorfälle. Zum Beispiel wurden bei Deep Root Analytics die Namen, Adressen, Geburtsdaten und Telefonnummern von 198 Millionen Wählern gestohlen. Bei der israelischen Firma Nice Systems wurden 14 Millionen Datensätze von Verizon-Abonnenten gestohlen. Dennoch ermöglichen die eingebauten Funktionen von AWS, ein breites Spektrum an Vorfällen zu erkennen. Zum Beispiel:

• Einfluss auf die Infrastruktur (DDoS)
• Kompromittierung eines Knotens (Befehlsinjektion)
• Kompromittierung des Kontos und unbefugter Zugriff
• Fehlkonfigurationen und Schwachstellen
• Ungesicherte Schnittstellen und APIs.

Diese Diskrepanz ergibt sich daraus, dass, wie wir oben festgestellt haben, der Kunde selbst für die Sicherheit seiner Daten verantwortlich ist. Wenn er es versäumt hat, Sicherheitsmechanismen zu aktivieren und Überwachungstools einzuschalten, wird er von Vorfällen nur über die Medien oder von seinen Kunden erfahren.

Um Vorfälle zu erkennen, kann ein breites Spektrum verschiedener Überwachungsdienste genutzt werden, die von Amazon entwickelt wurden (obwohl sie oft durch externe Tools wie osquery ergänzt werden). In AWS werden alle Aktionen der Benutzer verfolgt, unabhängig davon, wie sie durchgeführt werden – über die Management-Konsole, die Befehlszeile, SDK oder andere AWS-Dienste. Alle Protokolle über die Aktionen jedes AWS-Kontos (einschließlich Benutzername, Aktion, Dienst, Aktivitätsparameter und Ergebnis) sowie die Nutzung der API sind über den AWS CloudTrail-Dienst zugänglich. Sie können diese Ereignisse (zum Beispiel den Login in die AWS IAM-Konsole) über die CloudTrail-Konsole einsehen, mithilfe von Amazon Athena analysieren oder an externe Lösungen wie Splunk, AlienVault usw. weitergeben. Die AWS CloudTrail-Protokolle werden in Ihrem AWS S3-Bucket gespeichert.

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

Zweitens ermöglicht der VPC Flow Logs-Dienst die Analyse des Netzwerkverkehrs, der von oder zu Ihren AWS-Servern gesendet oder empfangen wird (von außen oder von innen) sowie zwischen Mikrodiensten. Wenn einer Ihrer AWS VPC-Ressourcen mit dem Netzwerk interagiert, protokolliert der VPC Flow Logs-Dienst Informationen über den Netzwerkverkehr, einschließlich der Quell- und Zielnetzwerkschnittstelle sowie IP-Adressen, Ports, Protokolle, die Anzahl der Bytes und die Anzahl der Pakete, die sie gesehen haben. Experten für lokale Netzwerksicherheit erkennen dies als das Äquivalent von Flüssen. NetFlow, die von Unternehmens-Level-Switches, Routern und Firewalls erstellt werden können. Diese Protokolle sind wichtig für die Überwachung der Informationssicherheit, da sie im Gegensatz zu Ereignissen über Benutzer- und Anwendungsaktionen auch den Netzwerkverkehr in einer virtuellen privaten Cloud-Umgebung von AWS nicht auslassen.

Somit bieten diese drei AWS-Dienste – AWS CloudTrail, Amazon CloudWatch und VPC Flow Logs – zusammen eine recht effiziente Sicht auf die Nutzung Ihres Kontos, das Verhalten der Benutzer, das Management der Infrastruktur, die Aktivität von Anwendungen und Diensten sowie den Netzwerkverkehr. Beispielsweise können Sie mit ihnen folgende Anomalien erkennen:

• Versuche, eine Website zu scannen, nach Backdoors zu suchen, sowie die Suche nach Schwachstellen durch die Häufung von "404-Fehlern".
• Injection-Angriffe (zum Beispiel SQL-Injection) durch die Häufung von "500-Fehlern".
• Bekannte Werkzeuge für Angriffe wie sqlmap, nikto, w3af, nmap usw. durch die Analyse des User-Agent-Feldes.

Amazon Web Services hat auch andere Dienste für die Cybersicherheit entwickelt, die viele weitere Aufgaben lösen. Zum Beispiel bietet AWS einen integrierten Dienst für die Audits von Richtlinien und Konfigurationen – AWS Config. Dieser Service gewährleistet eine kontinuierliche Überwachung Ihrer AWS-Ressourcen und deren Konfigurationen. Nehmen wir ein einfaches Beispiel: Angenommen, Sie möchten sicherstellen, dass die Benutzerpasswörter auf allen Ihren Servern deaktiviert sind und der Zugriff nur basierend auf Zertifikaten möglich ist. AWS Config ermöglicht es Ihnen, dies ganz einfach 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 können Firewall-Regeln ändern“ oder „Nur der Nutzer Iwaschko kann neue Benutzerkonten erstellen, und das darf er nur dienstags“. Im Sommer 2016 wurde der Dienst AWS Config erweitert, um die Automatisierung der Erkennung von Verstößen gegen die festgelegten Richtlinien zu ermöglichen. AWS Config Rules sind im Wesentlichen kontinuierliche Konfigurationsabfragen für die von Ihnen genutzten Amazon-Dienste, die Ereignisse generieren, wenn gegen die entsprechenden Richtlinien verstoßen wird. Anstatt regelmäßig AWS Config-Abfragen durchzuführen, um sicherzustellen, dass alle Festplatten des Virtual Servers verschlüsselt sind, können Sie AWS Config Rules verwenden, um die Serverfestplatten kontinuierlich auf die Erfüllung dieser Bedingung zu überprüfen. Und das Wichtigste in diesem Kontext: Jegliche Verstöße erzeugen Ereignisse, die von Ihrem IKT-Dienst analysiert werden können.

AWS bietet auch Äquivalente zu traditionellen Unternehmenslösungen für Informationssicherheit, die ebenfalls Sicherheitsereignisse generieren, die Sie analysieren sollten:

• Intrusion Detection – AWS GuardDuty
• Information Leakage Detection – AWS Macie
• EDR (obwohl es etwas seltsam klingt, über Endgeräte in der Cloud zu sprechen) – AWS Cloudwatch + Open-Source-Lösungen osquery oder GRR
• Netflow-Analyse – AWS Cloudwatch + AWS VPC Flow
• DNS-Analyse – AWS Cloudwatch + AWS Route53
• AD – AWS Directory Service
• Account Management – AWS IAM
• SSO – AWS SSO
• Security Analysis – AWS Inspector
• Configuration Management – AWS Config
• WAF – AWS WAF.

Ich werde nicht detailliert auf alle Amazon-Dienste eingehen, die im Kontext der Informationssicherheit nützlich sein können. Das Wichtigste ist zu verstehen, dass sie alle Ereignisse generieren können, die wir im Rahmen der Informationssicherheit analysieren können und sollten, indem wir sowohl die integrierten Möglichkeiten von Amazon selbst als auch externe Lösungen, wie SIEM, nutzen, die Sicherheitsereignisse in Ihr Monitoring-Center ziehen und dort neben Ereignissen anderer Cloud-Dienste oder interner Infrastruktur, Perimeter oder mobiler Geräte analysieren.

Auf jeden 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 gemäß bewährten Praktiken
• Config – Inventarisierung und Konfiguration von Konten und Diensteinstellungen
• VPC Flow Logs – Verbindungen zu virtuellen Schnittstellen
• IAM – Identifikations- und Authentifizierungsdienst
• ELB Access Logs – Lastenausgleichsprotokolle
• Inspector – Schwachstellen in Anwendungen
• S3 – Dateispeicher
• CloudWatch – Anwendungsaktivität
• SNS – Benachrichtungsdienst.

Amazon, das ein solches Spektrum an Ereignisquellen und Werkzeugen zu deren Generierung anbietet, ist bei der Analyse der gesammelten Daten im Kontext der Informationssicherheit stark eingeschränkt. Sie müssen die vorhandenen Protokolle selbst durchsehen und entsprechende Indikatoren für Kompromittierungen finden. AWS Security Hub, das Amazon kürzlich gestartet hat, soll dieses Problem lösen und fungiert als eine Art Cloud-SIEM für AWS. Doch befindet es sich noch am Anfang seiner Reise und ist sowohl in der Anzahl der Quellen, mit denen es arbeitet, als auch durch andere Einschränkungen, die durch die Architektur und Abonnements von Amazon selbst festgelegt sind, begrenzt.

Beispiel: Informationssicherheitsmonitoring in IaaS auf Basis von Azure

Ich möchte keine lange Diskussion darüber führen, welcher der drei Cloud-Anbieter (Amazon, Microsoft oder Google) der beste ist (zumal jeder von ihnen eine bestimmte Spezifik hat und für seine eigenen Aufgaben geeignet ist); konzentrieren wir uns auf die Möglichkeiten zur Überwachung von IT-Sicherheit, die diese Anbieter bieten. Man muss zugeben, dass Amazon AWS einer der ersten in diesem Segment war und daher in Bezug auf seine Funktionen zur IT-Sicherheit am weitesten fortgeschritten ist (obwohl viele anerkennen, dass die Nutzung etwas kompliziert ist). Aber das bedeutet nicht, dass wir die Möglichkeiten ignorieren, die uns Microsoft und Google bieten.

Die Produkte von Microsoft zeichnen sich immer durch ihre „Offenheit“ aus, und in Azure ist die Situation ähnlich. Während AWS und GCP immer von dem Konzept ausgehen, dass „alles, was nicht erlaubt ist, verboten ist“, verfolgt Azure einen völlig gegensätzlichen Ansatz. Beispielsweise sind beim Erstellen eines virtuellen Netzwerks in der Cloud und einer virtuellen Maschine darin standardmäßig alle Ports und Protokolle geöffnet und erlaubt. Daher müssen Sie etwas mehr Aufwand für die anfängliche Einrichtung der Zugriffskontrolle in der Microsoft-Cloud investieren. Dies stellt auch strengere Anforderungen an die Überwachung der Aktivitäten in der Azure-Cloud.

AWS bietet eine Besonderheit, die besagt, dass die Überwachung Ihrer virtuellen Ressourcen in verschiedenen Regionen Schwierigkeiten bei der Konsolidierung aller Ereignisse und deren einheitlicher Analyse mit sich bringt. Um diesen Herausforderungen zu begegnen, müssen Sie auf verschiedene Tricks zurückgreifen, wie etwa das Erstellen eigener Codes für AWS Lambda, um Ereignisse zwischen Regionen zu übertragen. In Azure gibt es dieses Problem nicht — sein Activity Log-Mechanismus verfolgt alle Aktivitäten innerhalb der gesamten Organisation ohne Einschränkungen. Gleiches gilt für den AWS Security Hub, der kürzlich von Amazon entwickelt wurde, um viele Sicherheitsfunktionen in einem einzigen Sicherheitszentrum zu konsolidieren, jedoch nur innerhalb seiner eigenen Region, was für Russland nicht relevant ist. Azure verfügt über ein eigenes Security Center, das keine regionalen Einschränkungen hat und Zugang zu allen Sicherheitsfunktionen der Cloud-Plattform bietet. Darüber hinaus kann es für verschiedene lokale Teams einen eigenen Satz von Sicherheitsfunktionen bereitstellen, einschließlich verwalteter Sicherheitsereignisse. Der AWS Security Hub strebt noch danach, dem Azure Security Center ähnlich zu werden. Allerdings gibt es einen Wermutstropfen — Sie können aus Azure viel mehr herausholen, als zuvor bei AWS beschrieben, aber dies funktioniert am besten für Azure AD, Azure Monitor und Azure Security Center. Alle anderen Sicherheitsmechanismen von Azure, einschließlich der Analyse von Sicherheitsereignissen, werden derzeit nicht auf die benutzerfreundlichste Weise verwaltet. Ein Teil des Problems wird durch die API gelöst, die alle Dienste von Microsoft Azure durchdringt, jedoch erfordert dies zusätzlichen Aufwand für die Integration Ihrer Cloud mit Ihrem SOC und qualifizierte Fachkräfte (genauso wie bei jedem anderen SIEM, das mit Cloud-APIs arbeitet). Einige SIEM, auf die wir später zu sprechen kommen, unterstützen bereits Azure und können die Aufgabe seiner Überwachung automatisieren, doch auch hier gibt es Herausforderungen — nicht alle können alle Protokolle abrufen, die Azure zur Verfügung stellt.

Die Ereignissammlung und -überwachung in Azure erfolgt über den Azure Monitor-Dienst, der das Hauptwerkzeug zum Sammeln, Speichern und Analysieren von Daten in der Microsoft-Cloud und ihren Ressourcen ist – darunter Git-Repositories, Container, virtuelle Maschinen, Anwendungen usw. Alle Daten, die vom Azure Monitor gesammelt werden, lassen sich in zwei Kategorien unterteilen: Metriken, die in Echtzeit erfasst werden und die wichtigsten Leistungskennzahlen der Azure-Cloud beschreiben, sowie Protokolle, die Daten enthalten, die in Datensätzen organisiert sind und verschiedene Aspekte der Aktivitäten von Azure-Ressourcen und -Diensten kennzeichnen. Darüber hinaus kann der Azure Monitor über die Data Collector API Daten von jeder REST-Quelle sammeln, 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):

• Activity Logs – dieses Protokoll beantwortet die klassischen Fragen „wer“, „was“ und „wann“ bezüglich jeder Operation (PUT, POST, DELETE) an Cloud-Ressourcen. Ereignisse, die mit Lesezugriffen (GET) verbunden sind, werden in dieses Protokoll nicht aufgenommen, ebenso wie eine Reihe anderer.
• Diagnostic Logs – enthält Daten zu Operationen mit bestimmten Ressourcen, die zu Ihrem Abonnement gehören.
• Azure AD-Berichterstattung – enthält sowohl Benutzeraktivitäten als auch systembezogene Aktivitäten im Zusammenhang mit der Verwaltung von Gruppen und Benutzern.
• Windows Event Log und Linux Syslog – enthält Ereignisse von den im Cloud gehosteten virtuellen Maschinen.
• Metrics – enthält Telemetriedaten zum Zustand der Leistungsfähigkeit und „Gesundheit“ Ihrer Cloud-Dienste und -Ressourcen. Diese werden alle ein bis zwei Minuten gemessen und 30 Tage lang gespeichert.
• Network Security Group Flow Logs – enthält Daten zu sicherheitsrelevanten Netzereignissen, die mit dem Network Watcher-Dienst und der Netzwerk-Ressourcenüberwachung gesammelt werden.
• Storage Logs – enthält Ereignisse, die mit dem Zugriff auf Speicherressourcen verbunden sind.

Für die Überwachung können Sie externe SIEM-Systeme oder den integrierten Azure Monitor mit seinen Erweiterungen verwenden. Über die Systeme zur Verwaltung von Sicherheitsereignissen werden wir später sprechen, aber zunächst werfen wir einen Blick darauf, was Azure selbst zur Datenanalyse im Sicherheitskontext bietet. Der Hauptbildschirm für alles, was mit Sicherheit im Azure Monitor zu tun hat, ist das Log Analytics Security and Audit Dashboard (die kostenlose Version unterstützt die Speicherung einer begrenzten Anzahl von Ereignissen für nur eine Woche). Dieses Dashboard ist in fünf Hauptbereiche unterteilt, die eine zusammenfassende Statistik über das Geschehen in Ihrer genutzten Cloud-Umgebung visualisieren:

• Security Domains – Schlüsselkennzahlen im Zusammenhang mit der Informationssicherheit – Anzahl der Vorfälle, Anzahl der kompromittierten Knoten, nicht gepatchte Knoten, Ereignisse der Netzwerksicherheit usw.
• Notable Issues – zeigt die Anzahl und Wichtigkeit aktiver Sicherheitsprobleme an.
• Detections – zeigt die Muster der gegen Sie verwendeten Angriffe an.
• Threat Intelligence – zeigt geografische Informationen über externe Knoten an, die Sie angreifen.
• Common security queries – typische Abfragen, die Ihnen helfen, Ihre Informationssicherheit besser zu überwachen.

Zu den Erweiterungen des Azure Monitors gehören Azure Key Vault (Schutz kryptografischer Schlüssel in der Cloud), Malware Assessment (Analyse des Schutzes vor Schadsoftware auf virtuellen Maschinen), Azure Application Gateway Analytics (Analyse unter anderem von Protokollen der Cloud-Firewall) usw. Diese Tools, die mit bestimmten Regeln zur Ereignisverarbeitung angereichert sind, ermöglichen die Visualisierung verschiedener Aspekte der Cloud-Dienste, einschließlich der Sicherheit, sowie die Identifizierung von Abweichungen im Betrieb. Aber wie so oft erfordert jede zusätzliche Funktionalität ein entsprechendes kostenpflichtiges Abonnement, das von Ihnen entsprechende finanzielle Investitionen erfordert, die Sie im Voraus planen müssen.

Azure bietet eine Reihe integrierter Bedrohungsüberwachungsfunktionen, die in Azure AD, Azure Monitor und Azure Security Center integriert sind. Dazu gehört beispielsweise die Erkennung der Interaktion virtueller Maschinen mit bekannten bösartigen IP-Adressen (durch die Integration mit Microsofts Threat Intelligence-Diensten), die Erkennung von Malware in der Cloud-Infrastruktur durch Alarmsignale von in der Cloud gehosteten virtuellen Maschinen, Brute-Force-Angriffe auf virtuelle Maschinen, Schwachstellen in der Konfiguration des Benutzeridentifikationssystems, der Zugriff von Anonymisierern oder infizierten Knoten, Datenleckagen von Benutzerkonten, Anmeldungen von ungewöhnlichen Standorten usw. Azure ist heute einer der wenigen Cloud-Anbieter, die Ihnen integrierte Threat Intelligence-Funktionen anbieten, um die gesammelten Sicherheitsereignisse anzureichern.

Wie bereits erwähnt, ist die Schutzfunktionalität und die somit generierten Sicherheitsereignisse nicht für alle Benutzer gleich zugänglich, sondern erfordert ein bestimmtes Abonnement, das die erforderliche Funktionalität umfasst, die 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, wie im Fall von AWS, die gesammelten Sicherheitsereignisse "manuell" analysieren. Zudem sind je nach Art der Lizenz für Azure AD nicht alle Ereignisse für die Analyse verfügbar.

Im Azure-Portal können Sie sowohl die Suchanfragen zu den gewünschten Protokollen verwalten als auch Dashboards zur Visualisierung von Schlüsselindikatoren der Informationssicherheit einrichten. Darüber hinaus können Sie dort Azure Monitor-Erweiterungen auswählen, die es Ihnen ermöglichen, die Funktionalität der Azure Monitor-Protokolle zu erweitern und eine tiefere Analyse von Ereignissen aus Sicherheitsansicht zu erhalten.

Wenn Sie nicht nur die Möglichkeit benötigen, mit Protokollen zu arbeiten, sondern auch ein umfassendes Sicherheitszentrum für Ihre Cloud-Plattform Azure, einschließlich der Verwaltung von Sicherheitsrichtlinien, dann ist es notwendig, mit dem Azure Security Center zu arbeiten, dessen nützlichste Funktionen gegen eine zusätzliche Gebühr verfügbar sind, wie z.B. Bedrohungserkennung, Überwachung außerhalb von Azure, Compliance-Bewertung usw. (in der kostenlosen Version haben Sie nur Zugang zur Sicherheitsbewertung und Empfehlungen zur Behebung identifizierter Probleme). Es konsolidiert alle Sicherheitsaspekte an einem Ort. Faktisch kann man von einem höheren Sicherheitsniveau sprechen, als es Azure Monitor bietet, da die gesammelten Daten über Ihre gesamte Cloud-Infrastruktur mit einer Vielzahl von Quellen angereichert werden, wie z.B. 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), die mit verschiedenen fortschrittlichen Algorithmen für maschinelles Lernen und Verhaltensanalysen kombiniert werden, was letztendlich die Effektivität bei der Bedrohungserkennung und -reaktion erhöhen sollte.

Azure verfügt ebenfalls über ein eigenes SIEM, das Anfang 2019 eingeführt wurde. Dies ist Azure Sentinel, das auf Daten von Azure Monitor basiert und sich auch mit externen Sicherheitslösungen (z.B. NGFW oder WAF) integrieren kann, deren Liste ständig erweitert wird. Darüber hinaus erhalten Sie durch die Integration der Microsoft Graph Security API die Möglichkeit, Ihre eigenen Threat Intelligence Feeds an Sentinel anzuschließen, was die Analysefunktionen von Vorfällen in Ihrer Azure-Umgebung bereichert. Man kann sagen, dass Azure Sentinel das erste „native“ SIEM ist, das von Cloud-Anbietern bereitgestellt wird (andere wie Splunk oder ELK, die in der Cloud gehostet werden können, wie z.B. AWS, sind schließlich nicht von traditionellen Cloud-Dienstleistern entwickelt worden). Azure Sentinel und das Security Center könnten als das SOC für die Azure-Cloud bezeichnet werden, und man könnte sich damit begnügen (mit gewissen Vorbehalten), wenn Sie keine andere Infrastruktur mehr hätten und alle Ihre Rechenressourcen in die Cloud verlagert hätten und es sich um Microsoft Azure handeln würde.

Da die integrierten Funktionen von Azure (selbst bei einer Sentinel-Subscription) oft nicht ausreichen, um die Anforderungen an das Sicherheitsmonitoring zu erfüllen 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 nur für die folgenden SIEM offiziell verfügbar sind – Splunk (Azure Monitor Add-On für Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight und ELK. Noch vor kurzem gab es mehr solche SIEM, aber seit dem 1. Juni 2019 hat Microsoft die Unterstützung des Azure Log Integration Tools (AzLog) eingestellt, welches zu Beginn von Azure und in der Zeit, als es noch keine ordentliche Standardisierung zur Arbeit mit Logs gab (Azure Monitor existierte noch nicht), eine einfache Integration externer SIEM mit der Microsoft-Cloud ermöglichte. Die Situation hat sich geändert und Microsoft empfiehlt jetzt die Plattform Azure Event Hub als primäres Integrationswerkzeug für andere SIEM. Viele haben bereits eine solche Integration durchgeführt, aber seien Sie vorsichtig – sie können möglicherweise nicht alle Logs von Azure erfassen, sondern nur einige (siehe die Dokumentation zu Ihrem SIEM).

Abschließend möchte ich eine allgemeine Empfehlung zu Azure geben: Bevor Sie irgendwelche Aussagen zu den Funktionen der Sicherheitsüberwachung in Azure treffen, sollten Sie diese sehr sorgfältig konfigurieren und testen, ob sie so funktionieren, wie in der Dokumentation angegeben und wie Ihnen die Microsoft-Berater erzählt haben (die möglicherweise unterschiedliche Ansichten über die Funktionsfähigkeit der Azure-Funktionen haben). Wenn Sie über finanzielle Mittel verfügen, können Sie in Azure sehr viel Nützliches im Bereich der Sicherheitsüberwachung herausholen. Wenn Ihre Ressourcen jedoch begrenzt sind, müssen Sie, wie im Fall von AWS, nur auf Ihre eigenen Kräfte und die Rohdaten zurückgreifen, die Ihnen Azure Monitor zur Verfügung stellt. Denken Sie daran, dass viele Überwachungsfunktionen kostenpflichtig sind und es ratsam ist, sich im Voraus mit der Preisgestaltung vertraut zu machen. Beispielsweise können Sie Daten für 31 Tage kostenlos speichern, wobei das Volumen 5 GB pro Auftraggeber nicht überschreiten darf – eine Überschreitung dieser Werte erfordert zusätzliche Ausgaben (etwa 2+ Dollar für die Speicherung jedes zusätzlichen GB pro Auftraggeber und 0,1 Dollar für die Speicherung von 1 GB jeden zusätzlichen Monat). Die Arbeit mit Anwendungstelemmetrien und Metriken kann ebenfalls zusätzliche finanzielle Mittel erfordern, ebenso wie die Arbeit mit Alarmen und Benachrichtigungen (ein gewisses kostenloses Kontingent steht zur Verfügung, das möglicherweise nicht für Ihre Bedürfnisse ausreicht).

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

Die Google Cloud Platform erscheint im Vergleich zu AWS und Azure ziemlich neu, aber das ist teilweise positiv. Im Gegensatz zu AWS, das seine Möglichkeiten, einschließlich der Sicherheitsfunktionen, schrittweise ausgebaut hat und dabei Probleme mit der Zentralisierung hatte, wird GCP, ähnlich wie Azure, viel besser zentral verwaltet, was die Fehlerquote und die Implementierungszeit im Unternehmen verringert. In Bezug auf die Sicherheit befindet sich GCP, erstaunlicherweise, zwischen AWS und Azure. Es verfügt ebenfalls über ein zentrales Logging für die gesamte Organisation, aber dieses ist unvollständig. Einige Funktionen befinden sich noch im Beta-Modus, aber allmählich sollte dieser Mangel behoben werden und GCP wird zu einer reiferen Plattform in Bezug auf die Sicherheitsüberwachung.

Das Hauptinstrument zur Ereignisregistrierung in GCP ist Stackdriver Logging (entspricht Azure Monitor), das es Ihnen ermöglicht, Ereignisse in Ihrer gesamten Cloud-Infrastruktur zu sammeln (einschließlich AWS). Aus Sicht der Sicherheit hat jede Organisation, jedes Projekt oder jeder Ordner in GCP vier Protokolle:

• Admin Activity – enthält alle Ereignisse, die mit administrativem Zugang zusammenhängen, wie z. B. das Erstellen einer virtuellen Maschine, das Ändern von Zugriffsrechten usw. Dieses Protokoll wird immer aufgezeichnet, unabhängig von Ihrem Wunsch, und speichert seine Daten für 400 Tage.
• Data Access – enthält alle Ereignisse, die mit der Arbeit von cloudbasierten Nutzern an Daten verbunden sind (Erstellung, Änderung, Lesung usw.). Standardmäßig wird dieses Protokoll nicht geschrieben, da sein Volumen sehr schnell anwächst. Aus diesem Grund beträgt seine Aufbewahrungszeit nur 30 Tage. Außerdem werden nicht alle Ereignisse in dieses Protokoll geschrieben. Zum Beispiel werden Ereignisse, die mit öffentlich zugänglichen Ressourcen für alle Nutzer verbunden sind oder die ohne Anmeldung in GCP zugänglich sind, nicht aufgezeichnet.
• System Event – enthält Systemereignisse, die nicht mit Nutzern verbunden sind, oder Aktionen eines Administrators, der die Konfiguration der Cloud-Ressourcen ändert. Dieses Protokoll wird immer geschrieben und für 400 Tage aufbewahrt.
• Access Transparency – ist ein einzigartiges Beispiel für ein Protokoll, das alle Aktionen von Google-Mitarbeitern (aber bisher nicht für alle GCP-Dienste) aufzeichnet, die im Rahmen ihrer dienstlichen Aufgaben auf Ihre Infrastruktur zugreifen. Dieses Protokoll wird 400 Tage lang aufbewahrt 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 Rollen eines bestimmten Typs im Rahmen des Unternehmenskontos). 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: "KUNDENINITIIERTER_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 kann auf verschiedene Weise erfolgen (ähnlich wie bei den zuvor erörterten Azure und AWS) - über die Benutzeroberfläche Log Viewer, über die API, über das Google Cloud SDK oder über die Seite Activity Ihres Projektes, für das Sie an den Ereignissen interessiert sind. Ebenso können sie in externe Lösungen für eine zusätzliche Analyse exportiert werden. Letzteres geschieht durch den Export von Protokollen in den BigQuery-Speicher oder Cloud Pub/Sub.

Neben Stackdriver Logging bietet die GCP-Plattform auch die Funktionalität von Stackdriver Monitoring, die es ermöglicht, Schlüsselmetriken (Leistung, Fehlerrate, allgemeiner Zustand usw.) von Cloud-Diensten und Anwendungen zu überwachen. Die speziell verarbeiteten und visualisierten Daten können die Fehlersuche in Ihrer Cloud-Infrastruktur erleichtern, auch im Hinblick auf die Sicherheit. Es ist jedoch zu beachten, dass diese Funktionalität im Hinblick auf die Informationssicherheit nicht sehr umfangreich sein wird, da die GCP derzeit kein Pendant zu AWS GuardDuty hat und unter allen registrierten Ereignissen keine fehlerhaften herausfiltern kann (Google hat Event Threat Detection entwickelt, aber es befindet sich momentan in der Beta-Phase, und es ist früh, um über seine Nützlichkeit zu sprechen). Stackdriver Monitoring könnte als Anomalieerkennungssystem eingesetzt werden, dessen Ursachen dann untersucht werden. Angesichts des Mangels an qualifiziertem Personal im Bereich Informationssicherheit in der GCP erscheint diese Aufgabe derzeit jedoch als herausfordernd.

Es lohnt sich auch, eine Liste einiger Sicherheitsmodule anzuführen, die im Rahmen Ihrer GCP-Cloud angewendet werden können und die mit denen übereinstimmen, die AWS anbietet:

• Cloud Security Command Center ist 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, gemäß mehr als 90 vordefinierten Klassifizierungspolicen.
• Cloud Scanner — Scanner für bekannte Schwachstellen (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 einheitliches Dashboard.
• Cloud HSM — Schutz von kryptographischen Schlüsseln.
• Cloud Key Management Service — Verwaltung kryptographischer Schlüssel in GCP.
• VPC Service Control — Erstellung eines sicheren Umfangs um Ihre GCP-Ressourcen, um sie vor Lecks zu schützen.
• Titan Security Key — Schutz vor Phishing.

Viele dieser Module generieren Sicherheitsereignisse, die in BigQuery zur Analyse oder zum Export in andere Systeme, einschließlich SIEM, gesendet werden können. Wie bereits erwähnt, ist GCP eine aktiv entwickelte Plattform, und Google arbeitet derzeit an einer Reihe neuer Sicherheitsmodule für seine Plattform. Dazu gehört Event Threat Detection (aktuell im Beta-Stadium), das die Stackdriver-Protokolle auf Spuren unbefugter Aktivitäten scannt (vergleichbar mit GuardDuty in AWS), sowie Policy Intelligence (verfügbar in Alpha), das die Entwicklung intelligenter Zugriffsrichtlinien für GCP-Ressourcen ermöglichen wird.

Ich habe einen kleinen Überblick über die integrierten Überwachungsmöglichkeiten in beliebten Cloud-Plattformen gemacht. Aber haben Sie Fachkräfte, die mit "rohen" Protokollen des IaaS-Anbieters umgehen können (nicht alle sind bereit, erweiterte Funktionen von AWS, Azure oder Google zu kaufen)? Zudem ist vielen das Sprichwort "Vertrauen ist gut, Kontrolle ist besser" bekannt, das im Bereich Sicherheit mehr denn je gilt. Wie sehr vertrauen Sie den integrierten Funktionen des Cloud-Anbieters, die Ihnen Sicherheitsereignisse zur Verfügung stellen? Wie sehr konzentrieren sie sich überhaupt auf Sicherheitsaspekte?

Manchmal lohnt es sich, nach integrierten Lösungen zur Überwachung von Cloud-Infrastrukturen Ausschau zu halten, die die eingebaute Sicherheit der Cloud ergänzen können. In einigen Fällen sind solche Lösungen die einzige Möglichkeit, um Daten zur Sicherheit Ihrer Daten und Anwendungen in der Cloud zu erhalten. Zudem sind sie einfach praktischer, da sie alle Aufgaben zur Analyse der erforderlichen Protokolle übernehmen, die von verschiedenen Cloud-Diensten unterschiedlicher Cloud-Anbieter generiert werden. Ein Beispiel für eine solche integrierte Lösung ist Cisco Stealthwatch Cloud, das sich auf eine einzige Aufgabe konzentriert: die Überwachung von Anomalien in der Informationssicherheit (IS) in Cloud-Umgebungen, einschließlich Amazon AWS, Microsoft Azure und Google Cloud Platform sowie privaten Clouds.

Beispiel: IS-Überwachung mit Stealthwatch Cloud

AWS bietet eine flexible Plattform für das Rechnen, doch diese Flexibilität führt dazu, dass Unternehmen leichter Fehler machen, die zu Sicherheitsproblemen führen. Und das geteilte IS-Modell fördert dies nur. Wenn Software mit unbekannten Sicherheitsanfälligkeiten in der Cloud ausgeführt wird (mit bekannten kann beispielsweise AWS Inspector oder GCP Cloud Scanner kämpfen), schwache Passwörter, falsche Konfigurationen, Insider und so weiter. All dies beeinflusst das Verhalten der Cloud-Ressourcen, die von Cisco Stealthwatch Cloud überwacht werden können, einer Überwachungs- und Angriffserkennungslösung für IS in öffentlichen und privaten Clouds.

Eine der Hauptmerkmale von Cisco Stealthwatch Cloud ist die Möglichkeit, Entitäten zu modellieren. Damit können Sie ein Softwaremodell (d. h. eine nahezu Echtzeitsimulation) jedes Ihrer Cloud-Ressourcen erstellen (unabhängig davon, ob es sich um AWS, Azure, GCP oder etwas anderes handelt). Dazu gehören Server und Benutzer sowie ressourcenspezifische Typen, die für Ihre Cloud-Umgebung relevant sind, wie Sicherheitsgruppen und Autoscaling-Gruppen. Diese Modelle verwenden strukturierte Datenströme, die von Cloud-Diensten bereitgestellt werden, als Eingang. Für AWS sind dies beispielsweise 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 aller Ihrer Ressourcen (man kann von der Profilerstellung aller Cloud-Aktivitäten sprechen). Zu diesen Rollen gehören Android- oder Apple-Geräte, Citrix PVS-Server, RDP-Server, Mailgateways, VoIP-Clients, Terminalserver, Domänencontroller usw. Anschließend überwacht es kontinuierlich ihr Verhalten, um festzustellen, wann riskantes oder sicherheitsbedrohliches Verhalten auftritt. Sie können Passwort-Cracking, DDoS-Angriffe, Datenlecks, unbefugten Remote-Zugriff, bösartige Aktivitäten, Sicherheitsüberprüfungen von Schwachstellen und andere Bedrohungen identifizieren. Hier ist ein Beispiel, wie ein Versuch, aus einem für Ihre Organisation untypischen Land (Südkorea) per SSH auf einen Kubernetes-Cluster zuzugreifen, erkannt wird:

So sieht ein vermuteter Datenleck aus einer Postgress-Datenbank in ein Land aus, mit dem zuvor keine Interaktion stattgefunden hat:

So sieht schließlich eine zu große Anzahl fehlgeschlagener SSH-Zugriffsversuche aus China und Indonesien von einem externen Remote-Gerät aus:

Oder nehmen wir an, dass eine Serverinstanz in der VPC gemäß der Richtlinie niemals als Ziel für den Remote-Login dienen sollte. Angenommen, auf diesem Computer gab es einen Remote-Login aufgrund einer fehlerhaften Änderung der Firewall-Regel. Die Funktion zur Modellierung von Entitäten wird diese Aktivität ("Ungewöhnlicher Remote-Zugriff") fast in Echtzeit erkennen und melden und auf den spezifischen Aufruf der API AWS CloudTrail, Azure Monitor oder GCP Stackdriver Logging (einschließlich Benutzername, Datum und Uhrzeit sowie weiteren Details) hinweisen, der die Änderung der Firewall-Regel ausgelöst hat. Diese Informationen können dann zur Analyse an das SIEM übergeben werden.

Ähnliche Möglichkeiten werden für jede von Cisco Stealthwatch Cloud unterstützte Cloud-Umgebung bereitgestellt:

Die Modellierung von Entitäten ist eine einzigartige Form der Sicherheitsautomatisierung, die zuvor unbekannte Probleme bei Ihren Personen, Prozessen oder Technologien erkennen kann. Zum Beispiel ermöglicht es, unter anderem folgende Sicherheitsprobleme zu erkennen:

• Hat jemand einen Backdoor in der Software entdeckt, die wir verwenden?
• Gibt es eine fremde Software oder ein Gerät in unserer Cloud?
• Missbraucht ein autorisierter Benutzer seine Privilegien?
• Wurde ein Konfigurationsfehler gemacht, der den Remote-Zugriff oder eine andere unbeabsichtigte Nutzung von Ressourcen ermöglicht?
• Gibt es keine Datenleckagen von unseren Servern?
• Hat jemand versucht, sich von einem ungewöhnlichen geografischen Standort aus mit uns zu verbinden?
• Ist unsere Cloud mit bösartiger Software infiziert?

Ein entdecktes Sicherheitsereignis kann als entsprechendes Ticket in Slack, Cisco Spark, das Incident-Management-System PagerDuty übergeben und an verschiedene SIEMs wie Splunk oder ELK weitergeleitet werden. Zusammenfassend lässt sich sagen, dass, wenn Ihr Unternehmen eine Multi-Cloud-Strategie nutzt und sich nicht auf einen einzigen Cloud-Anbieter beschränkt, die oben beschriebenen Möglichkeiten zur Sicherheitsüberwachung zeigen, dass der Einsatz von Cisco Stealthwatch Cloud eine gute Option ist, um einen einheitlichen Satz von Überwachungsmöglichkeiten für die führenden Cloud-Anbieter – Amazon, Microsoft und Google – zu erhalten. Am interessantesten ist, dass beim Vergleich der Preise für Stealthwatch Cloud mit erweiterten Lizenzen zur Sicherheitsüberwachung in AWS, Azure oder GCP herauskommen kann, dass die Cisco-Lösung sogar günstiger ist als die integrierten Möglichkeiten der Lösungen von Amazon, Microsoft und Google. Paradoxerweise ist das so. Und je mehr Clouds und deren Möglichkeiten Sie nutzen, desto offensichtlicher wird der Vorteil einer konsolidierten Lösung.

Darüber hinaus kann Stealthwatch Cloud auch private Clouds überwachen, die in Ihrer Organisation bereitgestellt werden, zum Beispiel auf Basis von Kubernetes-Containern oder durch Überwachung von Netflow-Strömen oder Netzwerkverkehr, der über das Mirroring von Netzwerkausrüstungen (auch von inländischer Produktion) erhalten wird, AD-Daten oder DNS-Servern usw. Alle diese Daten werden mit Informationen aus der Threat Intelligence angereichert, die von der Cisco Talos-Abteilung gesammelt wird, die größte private Gruppe von Bedrohungsforschern weltweit.

Das ermöglicht es Ihnen, ein einheitliches Überwachungssystem für sowohl öffentliche als auch hybride Clouds zu implementieren, die Ihr Unternehmen nutzen kann. Die gesammelten Informationen können dann 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 von Informationssicherheit in IaaS/PaaS-Plattformen behandelt habe, die 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 fortsetzen und die Überwachungsmöglichkeiten von SaaS-Plattformen am Beispiel von Salesforce und Dropbox untersuchen, sowie versuchen, alles zusammenzufassen und ein einheitliches Überwachungssystem für die Informationssicherheit verschiedener Cloud-Anbieter zu schaffen.

Quelle: habr.com