Erfahren Sie mehr über die Bedeutung einer starken AWS-Cloud-Sicherheit.
AWS RisikoanalyseAWS Cloud Security ist das Paket aus Protokollen und Prüfungen, die standardmäßig erstellt wurden, sodass die Infrastruktur der Cloud, in der Sie arbeiten, so sicher wie möglich ist. Für die Cloud-Sicherheit bei AWS sind AWS und der Kunde gemeinsam verantwortlich. AWS sichert die Cloud selbst und der Kunde sichert seinen Betrieb innerhalb der Cloud.
Die AWS Cloud Security schützt die Infrastruktur, die Services in der AWS Cloud ausführt. Sie besteht aus Hardware, Software, Netzwerk und Einrichtungen, die AWS Cloud-Services ausführen. AWS ist verantwortlich für Security-Prozesse wie Patch-Management und Konfigurationsmanagement, die Behebung von Schwachstellen in der Infrastruktur der Cloud sowie die Aufrechterhaltung der Konfiguration seiner Infrastrukturgeräte.
Auf oberster Ebene sind die Grundlagen der Sicherung der Cloud-Infrastruktur den Grundlagen der Sicherung eines lokalen Netzwerks ähnlich. So gilt beispielsweise das NIST Cybersecurity Framework nach wie vor: Sie versuchen zu ermitteln, was Sie sichern müssen, diese Assets zu schützen, böswillige Aktivitäten zu erkennen, auf Sicherheitsereignisse zu reagieren und den Normalzustand danach wiederherzustellen. Allerdings ist die Art und Weise, wie Sie unter den einzigartigen Aspekten einer Cloud-Umgebung diese Funktionen durchführen, mitunter ganz anders.
In einer Cloud-Umgebung liegt der offensichtlichste, aber häufig nicht verstandene Unterschied darin, dass der Cloud-Anbieter (CSP) für die Sicherheit einiger Elemente dieser Umgebung verantwortlich ist. Die Missverständnisse treten genau im Zuständigkeitsbereich des CSP auf. CSPs wie AWS haben ein gemeinsames Verantwortungsmodell entwickelt, um das Ganze zu klären.
Dieses Modell der geteilten Verantwortung besagt, dass AWS für die Sicherung der seiner Cloud zugrundeliegenden Infrastruktur verantwortlich ist. Das bedeutet, dass AWS für Dinge wie die Wartung und Aktualisierung der Hardware verantwortlich ist. Der Kunde, der die AWS-Infrastruktur nutzt, ist für die Sicherung aller Dinge, die er in AWS speichert, zuständig. Das bedeutet, dass er für die Aktualisierung und das Patching von Betriebssystemen verantwortlich ist genau wie für die ordnungsgemäße Konfiguration der von ihm genutzten AWS-Dienste, und die Zugriffsberechtigung aller Personen kontrolliert, die auf diese Dienste zugreifen.
Sollte jemand in Ihrem Unternehmen fälschlicherweise annehmen, dass Ihr Cloud-Anbieter sich um einen Sicherheitsaspekt kümmert, könnte dies zu unsachgemäß gesicherten Cloud-Assets führen. Daher ist es sehr wichtig, dass alle Personen, die eine Cloud-Umgebung modifizieren können, zunächst über die Bedeutung des gemeinsamen Verantworungsmodells unterrichtet werden und wissen, für welche Teile der Sicherheit Ihres Unternehmens sie zuständig sind.
Ein weiterer einzigartiger Aspekt einer Cloud-Umgebung ist die Leichtigkeit, mit der neue Assets erstellt und bereitgestellt werden können. In einem lokalen Netzwerk haben die IT- und Sicherheits-Teams den Überblick über neue Infrastruktur. In einem Cloud-Netzwerk kann neue Infrastruktur von jeder beliebigen Person oder jedem System mit den passenden Zugriffsberechtigungen sofort hinzugefügt werden. Das macht den Netzwerkausbau sehr viel einfacher, vergrößert jedoch ohne entsprechende Richtlinien und aktives Monitoring auch das Risiko, dass neue Infrastruktur nicht auf Sicherheit konfiguriert wurde und daher Schwachstellen aufweist.
Gleichzeitig verändern sich Cloud-Umgebungen sehr schnell. Beim Einsatz von Technologien wie Autoscaling und serverlosem Computing tauchen Assets in einem Cloud-Netzwerk ständig neu auf und verschwinden dann wieder. Herkömmliche Sicherheitsmaßnahmen wie Vulnerability Scans sind nicht mehr ausreichend, da anfällige Assets möglicherweise nur für wenige Minuten oder Stunden bestehen, d.h. es wird von dem wöchentlichen oder sogar dem täglichen Scan nicht erkannt.
Man könnte meinen, dass das auch bedeutet, dass das Asset nicht lange genug existiert, um ein Risiko darzustellen, aber Daten aus unserem globalen Honeypot-Netzwerk Project Lorelei zeigen, dass neue Assets innerhalb weniger Stunden nach ihrer Erstellung von bösartigen Quellen gescannt werden.
Durch die einfache Bereitstellung und hohe Veränderungsrate wird es für Sicherheits-Teams sehr viel schwieriger, einen vollständigen Überblick über die Cloud-Umgebung aufrechtzuerhalten. Erschwert wird dies in Hybrid-Umgebungen (IT-Umgebungen, in denen sowohl lokale als auch Cloud-Netzwerke vorhanden sind) und Multi-Cloud-Umgebungen (IT-Umgebungen mit Cloud-Netzwerken von mehreren Cloud-Anbietern), in denen verschiedene Informationen in unterschiedlichen Systemen gespeichert werden, die häufig mit verschiedenen Sicherheitstools geschützt werden.
In diesen Umgebungen muss das Sicherheitsteam zwischen verschiedenen Systemen hin und her springen, um seine Sicherheitsmaßnahmen umzusetzen. Der Mangel an vereinheitlichten Daten erschwert oder verhindert es sogar, sich einen genauen Überblick über die gesamte Sicherheitslage des Unternehmens zu verschaffen oder einen böswilligen Akteur zu verfolgen, der zwischen der Cloud und den lokalen Netzwerken hin und her wechselt.
Die Sicherheit auf AWS ist so stark, wie Sie sie machen. Oben haben wir das Modell der gemeinsamen Verantwortung besprochen und dass AWS für die Sicherheit der zugrunde liegenden Infrastruktur verantwortlich ist. Tatsächlich investiert AWS mehr Ressourcen in seinen Anteil des gemeinsamen Verantwortungsmodells als die Mehrzahl der Organisationen mit lokalen Netzwerken. Ein Wechsel zu AWS kann bei diesen Organisationen Aspekte ihrer Sicherheitslage verbessern.
Allerdings bringt der Wechsel zu AWS oder einem anderen öffentlichen Cloud-Anbieter auch neue Risiken mit sich. Wie oben erwähnt, haben Cloud-Umgebungen individuelle Herausforderungen. Es ist nicht möglich, die vorhandenen Sicherheitstaktiken einfach auf die Cloud zu übertragen. Trotz alledem kann AWS genauso sicher sein wie ein lokales Netzwerk (oder sogar noch sicherer), vorausgesetzt, Sie machen sich mit den einzigartigen Aspekten der Cloud-Sicherheit vertraut und wenden Best Practices an.
Starke AWS-Sicherheit ist aus denselben Gründen wichtig, die auch Cybersicherheit im Allgemeinen betreffen. Sie müssen Ihre Organisation und Ihre Kunden vor böswilligen Akteuren schützen. In vielen Unternehmen steigt die Wertschätzung einer starken AWS-Sicherheit, je mehr wertvolle Workloads und vertrauliche Daten in die Cloud verlagert werden.
Ein weiterer Grund, warum eine starke AWS-Sicherheit wichtig ist, ist der Reputationsschaden, der durch einen vermeidbaren Vorfall entstehen kann. Gartner prognostiziert, dass bis Ende 2020 95 % der Cloud-Sicherheitsausfälle auf Fehler des Kunden zurückzuführen sein werden. Sollten Kunden erfahren, dass ein Unternehmen aufgrund eines leicht vermeidbaren Fehlers kompromittiert wurde, könnte dies ihr Vertrauen soweit erschüttern, dass sie ihr Unternehmen an einen anderen Anbieter verlagern.
Eine kurze Anmerkung vor dem Einstieg: Wie Sie aus dem Firmennamen ablesen können, nutzt AWS sehr gerne Abkürzungen. Das kann verwirrend sein, wenn wir versuchen, die Funktionen der verschiedenen AWS-Dienste zu erkennen, darum hier eine kurze Erläuterung:
Weiter unten gehen wir noch näher auf zusätzliche AWS-Dienste ein, aber wir wollten Sie zunächst mit diesen Grundlagen vertraut machen. Nun aber zu den Best Practices:
1. Vorausplanen
Idealerweise sollten Sie bereits vor der Einführung darüber nachdenken, wie Sie Ihre AWS-Umgebung sichern. Wenn das Kind bereits in den Brunnen gefallen ist, ist das kein Grund zur Sorge – die Implementierung einiger Best Practices erfordert möglicherweise nur etwas mehr Aufwand.
2. In die Cloud einsteigen
Wenn ein Unternehmen zum ersten Mal in die Cloud-Umgebung einsteigt, versuchen einige Sicherheitsteams, die von ihnen betreute lokale Umgebung so gut wie möglich in der Cloud widerzuspiegeln, indem sie beispielsweise Entwickler daran hindern, Infrastrukturänderungen umzusetzen. In fast allen Fällen kommt es dann dazu, dass das Team seiner Aufgaben für die Cloud-Sicherheit entbunden wird, oder die Engineers Wege finden, die Einschränkungen zu umgehen (siehe Best Practices Nr. 9, weshalb das keine geeignete Vorgehensweise ist).
Sicherheitsteams müssen erkennen, dass potenziell riskante Aspekte der Cloud, wie z.B. die rasanten Veränderungen und die einfache Bereitstellung zugleich die größten Vorteile für die Nutzung der Cloud-Infrastruktur darstellen. Für ihren Erfolg müssen Sicherheitsteams versuchen, zu Wegbereitern der Cloud zu werden. Sie müssen Wege finden, um die Cloud-Infrastruktur zu sichern, ohne die Aspekte übermäßig zu unterdrücken, die den Nutzen der Cloud für das Unternehmen ausmachen. Das beginnt mit Offenheit und mit der Erkenntnis, dass ein erfolgreiches Risikomanagement einer Cloud-Umgebung neue Taktiken und Prozesse erfordert.
3. Definition einer Sicherheitsgrundlage für Ihre AWS-Umgebung
IhreSicherheits- und DevOps-Teams sollten zusammenarbeiten, um zu definieren, wie Ihre AWS-Umgebung aus Sicherheitssicht aussehen soll. Die Baseline sollte alles klar beschreiben, von der Konfiguration von Assets bis hin zu einem Incident-Response-Plan. Die Teams sollten die Verwendung von Ressourcen wie dem AWS Well-Architected Framework und den CIS-Benchmarks für die Sicherheit auf AWSals Ausgangspunkt in Betracht ziehen . Möglicherweise möchten sie auch einen AWS-Lösungsarchitekten um Unterstützung bitten, bei dem es sich um einen technischen Experten handelt, der in der Lage ist, Kunden beim Aufbau ihrer AWS-Umgebung zu unterstützen.
Stellen Sie sicher, dass Ihre Baseline sowohl auf Ihre Produktionsumgebung als auch auf alle Test- und Vorproduktionsumgebungen angewendet wird. Bewerten Sie Ihre Baseline mindestens alle sechs Monate neu, um Dinge wie neue Bedrohungen und Änderungen in Ihrer Umgebung zu berücksichtigen.
4. Durchsetzung Ihrer Baseline
Sobald Ihre Sicherheits- und DevOps-Teams definiert haben, wie Ihre AWS-Sicherheitsstandard aussieht, müssen Sie sie durchsetzen. Erleichtern Sie Entwicklern die Einhaltung Ihrer Sicherheitsstandards, indem Sie ihnen bereits ordnungsgemäß konfigurierte Infrastrukturvorlagen zur Verfügung stellen. Sie können dies mit AWS CloudFormation oder einem Infrastructure-as-Code-Anbieter wie Terraformtun.
Sie benötigen außerdem eine Überwachungslösung, um zu erkennen, wenn etwas nicht mit der Baseline-Standard übereinstimmt (entweder weil es mit einer Fehlkonfiguration bereitgestellt wurde oder weil nach der Bereitstellung eine Änderung vorgenommen wurde).Hierfür bietet sich beispielsweise die Nutzung von AWS Security Huban . Es gibt jedoch auch mehrere Drittanbieter-Vulnerability-Management-Lösungen, die eine integrierte Überwachung für Cloud-Fehlkonfigurationen bieten..
Die Verwendung einer VM-Lösung mit integrierter Fehlkonfigurationserkennung bietet zwei Vorteile. Erstens werden zwei Arten der Risikoüberwachung (Asset-Schwachstellen und Fehlkonfigurationen der Cloud-Infrastruktur) in einem Tool zusammengefasst. Zweitens werden bei den meisten Schwachstellenmanagementlösungen alle Fehlkonfigurationsregeln und -erkennungen vom Anbieter für Sie verwaltet, während Sie bei AWS Security Hub die Regeln selbst einrichten und verwalten müssen. Erfahren Sie mehr über InsightVM zur Schwachstellenbewertung und Cloud-Konfiguration.
Eine weitere Option zur Durchsetzung Ihrer Sicherheitsgrundlinie ist eine Cloud Security Posture Management (CSPM)-Lösung. Ein hochwertiges CSPM wird in der Lage sein,Konten von mehreren Cloud-Anbietern auf Fehlkonfigurationen zu überwachen. Dies ist besonders wichtig, da es Ihrer Organisation ermöglicht, einen Sicherheitsstandard für alle Ihre Cloud-Anbieter festzulegen und diese dann mit einem einzigen Tool durchsetzen kann. Neben der Möglichkeit,Cloud-Konten auf Fehlkonfigurationen zu überwachen, sollten Sie nach einem CSPM suchen, das in der Lage ist,Fehlkonfigurationen automatisch zu beheben, sobald sie erkannt werden. Dadurch wird die Belastung Ihres Sicherheitsteams erheblich reduziert und sichergestellt, dass nichts durchs Raster fällt.
Zu den weiteren Funktionen, nach denen Sie in einem CSPM suchen sollten, gehören die Möglichkeit,Probleme in der Infrastruktur als Code zu kennzeichnen, bevor etwas bereitgestellt wird, IAM-Governance (weitere Informationen zu IAM finden Sie im nächsten Abschnitt) und Compliance-Auditing. CSPMs sind in der Regel etwas teuer, aber für Unternehmen, die mehrere Cloud-Anbieter nutzen oder eine große Anzahl von Konten bei einem einzigen Anbieter haben, ist ein CSPM die Möglichkeit, das Chaos bei der Verwaltung all dieser Konten in Ordnung zu bringen.
5. Zugriffsrechte beschränken
Für die Schaffung einer sicheren AWS-Umgebung gibt es kaum etwas Wichtigeres, als den Zugriff auf die Benutzer und Systeme zu beschränken, die ihn wirklich benötigen. Dies wird mithilfe von AWS Identity Access Management (IAM)erreicht. IAM besteht aus folgenden Komponenten:
Da Sie jetzt einen Überblick über die Komponenten haben, aus denen sich ein IAM zusammensetzt, wollen wir uns die Best Practices ansehen. AWS verfügt über eine Liste der IAM Best Practices, die Sie sich durchlesen sollten. Ähnliche Praktiken sind in den CIS Benchmarks für AWS erwähnt. Obwohl alle Best Practices durchaus von Bedeutung sind, wollen wir an dieser Stelle nur die entscheidendsten Richtlinien (die am häufigsten missachtet werden) erwähnen:
6. Auf Schwachstellen achten
Vielen Menschen ist nicht bewusst, dass ungepatchte Schwachstellen auch in der Cloud immer noch eine Bedrohung darstellen. Um Schwachstellen in EC2-Instanzen zu erkennen, können Sie AWS Inspector oder eine Schwachstellenmanagementlösung eines Drittanbieters verwenden. Durch den Einsatz einer Schwachstellenmanagementlösung können Sie Ihre Arbeit besser priorisieren, Ihre Berichtsfunktionen verbessern, die Kommunikation mit Infrastruktureigentümern erleichtern und allen dabei helfen, den Fortschritt bei der Risikoreduzierung zu überwachen. Darüber hinaus bevorzugen Sicherheitsteams, die mit einer Hybrid- oder Multi-Cloud-Umgebung zu tun haben, häufig die Verwendung einer Lösung eines Drittanbieters, da sie damit das Schwachstellen- und Risikomanagement für alle ihre Umgebungen an einem Ort überwachen können (mehr dazu im Artikel „Best Practice“) Nr. 9).
Obwohl das Vulnerability Management den meisten Cybersicherheitsexperten vertraut sein sollte, gibt es einige einzigartige Aspekte von VMs in einer Cloud-Umgebung wie AWS, die Sie kennen sollten. Wie bereits erwähnt, kann sich eine Cloud-Umgebung schnell ändern. Assets erscheinen und verschwinden minütlich. In einer so dynamischen Welt reichen wöchentliche oder sogar tägliche Scans nicht aus, um ein genaues Verständnis von Schwachstellen und Ihrer Risikoexposition zu erhalten. Es ist wichtig, sicherzustellen, dass Sie ein vollständiges Bild davon haben, welche EC2-Instances vorhanden sind, sowie eine Möglichkeit, die Instances während ihrer gesamten Lebensdauer kontinuierlich zu überwachen. Um sicherzustellen, dass Sie ein vollständiges Bild Ihrer EC2-Instances haben, investieren Sie in eine Schwachstellen-Management-Lösung mit dynamischer Asset-Erkennung, die neue Instanzen automatisch erkennt, sobald sie bereitgestellt werden. Eine ähnliche Funktion kann mit AWS Inspector durch die Verwendung von CloudWatch Eventserreicht werden, obwohl die Einrichtung etwas manueller ist.
Wenn Sicherheitslücken in einer EC2-Instance entdeckt werden, können sie auf verschiedene Arten behoben werden. Eine Option ist die Verwendung des Patch Managers in AWS Systems Manager. Dieser Ansatz ist der herkömmlichen Verwaltung von Sicherheitslücken in einem lokalen Netzwerk am ähnlichsten. Viele Cloud-Umgebungen sind jedoch so konzipiert, dass sie unveränderlich sind. Mit anderen Worten, Ressourcen wie EC2-Instances sollten nicht geändert werden, sobald sie bereitgestellt wurden. Stattdessen wird, wenn eine Änderung vorgenommen werden muss, die bestehende Anlage gekündigt und durch eine neue ersetzt, die die Änderung beinhaltet.
In unveränderlichen Umgebungen setzen Sie also keine Patches ein, sondern setzen neue Instanzen mit diesen Patches ein. Dies lässt sich erreichen, indem Sie ein Basis-AMI erstellen und pflegen, das regelmäßig aktualisiert wird und die neueste Version des von Ihnen verwendeten Betriebssystems ausführt. Wenn unter diesem Ansatz eine Sicherheitslücke erkannt wird, können Sie eine neue Baseline-AMI aufbauen, die die Patches für die Sicherheitslücke enthält. So beseitigen Sie die Sicherheitslücke aus zukünftigen EC2-Instanzen, die Sie bereitstellen, müssen aber darauf achten, dass Sie auch alle derzeit laufenden EC2-Instanzen erneut bereitstellen.
Eine weitere Möglichkeit ist die Verwendung eines Infrastruktur-Automatisierungstools wie Chef oder Puppet, um AMIs zu aktualisieren und neu zu implementieren. Dieser Ansatz ist sinnvoll, wenn Sie bereits eines dieser Tools zur Wartung Ihrer EC2-Instanzen verwenden.
7. Logs erfassen und schützen
Wie bei jedem anderen System sollten Sie alle Aktivitäten, die in Ihrer AWS-Umgebung stattgefunden haben, protokollieren. Logs sind nicht nur für die Überwachung und Einhaltung von Vorschriften wichtig, sondern sie sind, wenn man an das NIST Cybersecurity Frameworkzurückdenkt, ein entscheidender Bestandteil bei der Erkennung bösartiger Aktivitäten (insbesondere, wenn sie in ein SIEMeingespeist werden), bei der Reaktion auf ein Sicherheitsereignis und bei der anschließenden Wiederherstellung.
In AWS werden die meisten Logs mit CloudTrailerfasst. Dieser Service erfasst und speichert automatisch AWS-API-Aktivitäten als so genannte Management-Ereignisse in Ihrem AWS-Konto, und zwar kostenlos (allerdings müssen Sie die Kosten für die Speicherung tragen). CloudTrail erfasst Zehntausende von Ereignissen, darunter wichtige Sicherheitsinformationen wie Anmeldungen und Konfigurationsänderungen an AWS-Services. Gegen eine Gebühr können Sie in CloudTrail auch Trails ("Pfade") erstellen, mit denen Sie z.B. zusätzliche Aktivitäten erfassen und Ihre Logs zur langfristigen Speicherung und/oder zum Export an S3 senden können. Hier finden Sie einige bewährte Verfahren für die Einrichtung von CloudTrail in Ihrem AWS-Konto:
Obwohl die meisten Protokolle in CloudTrail erfasst werden, gibt es noch einige andere Protokolle, die Sie unbedingt erfassen sollten. VPC Flow Logs zeigen Daten zum IP-Verkehr zu und von den Netzwerkschnittstellen in Ihrer Virtual Private Cloud (VPC). Sie können Ihnen dabei helfen, Intra-VPC-Port-Scans, Anomalien im Netzwerkverkehr und bekannte bösartige IP-Adressen zu identifizieren. Wenn Sie AWS Route 53 als DNS verwenden, sollten Sie auch DNS-Anfragen protokollieren. Mithilfe dieser Protokolle können Sie Bedrohungsinformationen abgleichen und bekanntermaßen schädliche oder sich schnell ausbreitende Bedrohungen identifizieren. Beachten Sie, dass Sie AWS CloudWatch verwenden müssen, um Ihre DNS-Protokolle anzuzeigen.
8. Überwachen, erkennen und reagieren
Da Sie nun wissen, wie Sie Logs verwenden können, um Einblicke in die Aktivitäten in Ihrer AWS-Umgebung zu erhalten, besteht die nächste Frage darin, wie Sie diese Transparenz nutzen können. Eine (sehr manuelle) Option ist die Verwendung von AWS CloudWatch-Alarmen. Mit diesem Ansatz erstellen Sie Alarme für verschiedene verdächtige Aktionen wie unautorisierte API-Aufrufe, VPC-Änderungen usw. Eine Liste der empfohlenen Alarme ist in den CIS-Benchmarks für AWS enthalten. Die Herausforderung bei diesem Ansatz besteht darin, dass jeder Alarm manuell erstellt und gewartet werden muss.
Eine weitere Option ist die Verwendung von AWS GuardDuty. GuardDuty verwendet CloudTrail, VPC-Flow Logs und DNS-Protokolle, um verdächtiges Verhalten zu erkennen und darauf hinzuweisen. Das Schöne an GuardDuty ist, dass es auf einer von AWS verwalteten Liste von Ergebnissen (auch potenziellen Sicherheitsproblemen genannt) sowie maschinellem Lernen basiert. Das bedeutet, dass keine manuelle Einrichtung oder Wartung erforderlich ist, um Benachrichtigungen über verdächtige Aktivitäten zu erhalten. Das Erkennen verdächtiger Aktivitäten ist jedoch nur der erste Schritt bei der Reaktion auf einen Vorfall.
Ihr Sicherheitsteam muss die relevanten Log-Dateien und andere Daten aufrufen, um zu überprüfen, ob ein Vorfall aufgetreten ist, und dann die beste Reaktion und Wiederherstellung bestimmen. Wenn das Team mehrere verschiedene Datenquellen durchsuchen muss, um diese Informationen zu finden, kann dies einen beträchtlichen Zeitaufwand für die Untersuchung bedeuten. In Hybrid- oder Multi-Cloud-Umgebungen ist diese Herausforderung sogar noch größer.
Die automatische Zentralisierung aller relevanten Daten während einer Untersuchung ist nur einer der Gründe, warum sich viele Sicherheitsteams für ein modernes SIEM- und Incident Detection-Toolentscheiden. Eine gute SIEM-Lösung verfügt über eine CloudTrail-Integration und ermöglicht es Ihnen, alle Protokolle von AWS neben den Protokollen von On-Prem-Netzwerken und anderen Cloud-Anbietern wie Azure und Google Cloud Platform (GCP) zu speichern. Diese Möglichkeit, alle Daten zu zentralisieren, kann die Ermittlungen enorm beschleunigen, insbesondere wenn Sie einen böswilligen Akteur verfolgen müssen, der sich in Ihren Umgebungen bewegt hat.
Ein gutes SIEM bietet auch eine Vielzahl anderer Funktionen, um die Fähigkeit Ihres Sicherheitsteams zu verbessern, einen Angriff zu erkennen, zu bestätigen und darauf zu reagieren. Beispielsweise verwenden die fortschrittlichsten SIEMs mehrere Techniken, um verdächtiges Verhalten zu erkennen. Andere Funktionen, auf die Sie achten sollten, sind die Möglichkeit, benutzerdefinierte Warnungen zu erstellen, Täuschungstechnologie (Dinge wie vorgefertigte Honeypots und Honey-Benutzer, die Warnungen auslösen, wenn darauf zugegriffen wird) und File Integrity Monitoring (FIM).
Alle diese Funktionen bieten zusätzliche Erkennungsebenen. Sie sollten auch nach einem SIEM suchen, das Visualisierungsfunktionen wie anpassbare Dashboards und Untersuchungszeitplänebietet, die Ihre zentralisierten Daten besser nutzbar machen. Stellen Sie außerdem sicher, dass jedes SIEM, das Sie in Betracht ziehen, über eine integrierte Automatisierungverfügt, da dies die Reaktionszeiten bei einem Vorfall erheblich verkürzen kann. Schließlich nutzen viele Teams gerne sowohl AWS als auch Tools von Drittanbietern, um ihre AWS-Umgebung zu sichern. In diesem Fall ist es wichtig, ein SIEM zu finden, das eine GuardDuty-Integration beinhaltet.
9. Vereinheitlichung von AWS mit lokaler und anderer Cloud-Sicherheit
Ein häufig auftretender Fehler ist der Ansatz, die AWS-Sicherheit eigenständig und getrennt von allen anderen Maßnahmen zum Schutz der vorhandenen IT-Infrastruktur zu sichern. Dadurch entsteht eine Lücke, die böswillige Akteure ausnutzen können. So haben wir beispielsweise Situationen gesehen, in denen die lokale und die AWS-Sicherheit eines Unternehmens so gestaltet wurden, dass sie unterschiedliche potenzielle Bedrohungen angehen. Die daraus resultierenden Lücken machten beide Netzwerke anfällig.
Ein einzelnes Team mit Zuständigkeit für die Sicherung der gesamten IT-Infrastruktur sorgt dafür, dass keine Vermutungen aufgestellt werden, was das „andere“ Sicherheitsteam tut oder unterlässt. Stattdessen gibt es ein Team, das sich seiner Zuständigkeit für alle Aspekte der Cybersicherheit Ihres Unternehmens bewusst ist. Die Verknüpfung Ihrer Sicherheitsmaßnahmen unter Aufsicht eines Teams kann auch während eines Vorfalls äußerst wichtig sein. Das Team hat unmittelbaren Zugriff auf weit mehr Daten. Zudem ist es sehr viel einfacher, Klarheit über die Zuständigkeiten der einzelnen Teammitglieder zu schaffen.
Die Vereinheitlichung zählt nicht nur, weil ein Team die Verantwortung übernimmt, sondern sie bringt auch alle Sicherheitsdaten in einem Tool-Satz zusammen. Die überragende Mehrheit der Unternehmen beschränkt ihren Einsatz von AWS nicht auf die einfache Nutzung. Sie verfügen in den allermeisten Fällen über lokale Netzwerke und Endgeräte der Mitarbeiter, die gesichert werden sollen. In vielen Fällen nutzen Unternehmen auch mehrere Cloud-Anbieter.
Wenn Sie verschiedene Sicherheitslösungen für die einzelnen Umgebungen verwenden, erhöht sich die Wahrscheinlichkeit der toten Winkel. Zudem gilt, je mehr Tools Ihr Sicherheitsteam einsetzt, desto höher ist deren Arbeitsbelastung, da sie ständig die Tools wechseln müssen, um sich manuell ein vollständiges Bild von der aktuellen Cybersicherheitslage des Unternehmens machen zu können.
10. Automatisieren
Angesichts so vieler Best Practices zur Sicherung des AWS ist es illusorisch, dass die Benutzer jederzeit alle beachten. Selbst wenn das möglich wäre, würden Fehler auftreten. Damit in Ihrer AWS-Umgebung die Sicherheitsgrundlagen kontinuierlich beachtet werden, sollten Sie auf Automatisierung setzen.
So können Sie beispielsweise eine Kombination von CloudFormation und Lambda oder einem Tool wie Terraform oder eine der fortschrittlicheren CSPMs verwenden, um die Bereitstellung neuer AWS-Infrastruktur zu automatisieren, und sichergehen, dass alles mit der von Ihnen etablierten Baseline konform ist. Sie können diese Tools auch automatisch markieren oder kündigen, wenn die Infrastruktur nicht konform ist.
Ein weiterer Vorteil der Automatisierung steckt in der Kapazität, die dadurch für Ihr Sicherheitsteam frei wird. Der kontinuierliche Mangel an Sicherheitsfachkräften bedeutet, dass Teams überfordert sind. Diese Lage wird nur noch schlimmer, wenn ein Unternehmen in die Cloud wechselt, was den Fußabdruck der vom Team zu sichernden Infrastruktur enorm ausdehnt.
Um Ihrem Team einen Vorteil gegenüber den Angreifern zu verschaffen, sollten Sie auch SOARin Betracht ziehen. Mit SOAR können Sie Daten problemlos zwischen lokalen und Cloud-Diensten austauschen und so eine einheitliche Sicht auf die gesamte IT-Infrastruktur des Unternehmens erhalten. Ein SOAR kann auch arbeitsintensive Aufgaben wie Onboarding und Offboarding sowie die Zusammenführung von Daten in der Anfangsphase einer Untersuchung erleichtern.
Die Verwendung eines SOAR-Tools reduziert die Arbeitslast des Sicherheitsteams und hilft ihm, effizienter zu arbeiten. Mit einem SOAR hat Ihr Sicherheitsteam mehr Zeit, sich auf hochwertige Aufgaben zu konzentrieren, und verkürzt den Zeitaufwand für die Untersuchung von Vorfällen.
Fordern Sie eine AWS-Risikoanalyse an
2022 Cloud Misconfigurations Report: Neueste Cloud Security-Verstöße und Angriffstrends
Erfahren Sie mehr über die Cloud Security Lösung von Rapid7: InsightCloudSec