Die AWS-Bedrohungserkennung bezieht sich auf die Identifizierung und Priorisierung bösartiger oder verdächtiger Aktivitäten in AWS durch die Analyse cloud auf Anzeichen für Angreiferverhalten.
Anstatt einzelne Ereignisse isoliert zu bewerten, untersucht dieser Ansatz, was ein Akteur über Identitäten, Rollen und Dienste hinweg tut. AWS-Umgebungen generieren große Mengen an Protokollen und Metadaten, die unabhängig voneinander schwer zu interpretieren sind. Die Verknüpfung dieser Telemetriedaten mit Verhaltenssignalen hilft dabei, die Bewegungen von Angreifern während eines cloud aufzudecken. Dies ist wichtig, da unkorrelierte Aktivitäten die Untersuchung und Reaktion verzögern können.
In der Praxis verknüpft die AWS-Bedrohungserkennung verwandte Aktionen zu Verhaltensmustern, die untersucht und priorisiert werden können. Anstatt cloud als eine Sammlung unabhängiger Warnmeldungen zu behandeln, interpretiert sie Aktivitäten als Hinweise auf eine mögliche Angriffssequenz. Diese Unterscheidung ist wichtig, da viele AWS-Aktionen technisch legitim sind, aber dennoch einen Missbrauch von Zugriffsrechten, Rollen oder Diensten darstellen.
Um Unsicherheiten während der Untersuchungen zu reduzieren, konzentriert sich die Bedrohungserkennung von AWS auf Verhaltensweisen, die auf das Vorgehen von Angreifern hinweisen, darunter die folgenden Aktivitätstypen, die Absichten über einen bestimmten Zeitraum und über verschiedene Dienste hinweg offenbaren:
Sehen Sie sich das Verhalten von AWS-Angreifern in Aktion an – mit einer geführten Angriffstour →
Die logzentrierte Überwachung in AWS versagt häufig dabei, das Verhalten von Angreifern aufzudecken, da Ereignisse als eigenständige Datensätze analysiert werden. Die Zuordnung endet häufig bei der letzten Rolle oder den letzten temporären Anmeldedaten, wodurch sich die Untersuchungen auf die falsche Abstraktion konzentrieren. Infolgedessen können Verteidiger den ursprünglichen Akteur möglicherweise nicht rechtzeitig identifizieren, um die Aktivitäten vor dem Auftreten von Auswirkungen einzudämmen.
Um eine falsche Priorisierung der Arbeit zu vermeiden, müssen Teams die spezifischen Fehlermodi erkennen, die auftreten können, wenn AWS-Aktivitäten als isolierte Ereignisse bewertet werden:
Um zu verstehen, wie sich Angreifer durch AWS bewegen, muss man über einzelne Serviceaktionen hinausblicken. Die verhaltensorientierte Erkennung hebt Progressionsmuster hervor, wie z. B. Rollenkettung, Protokollvermeidung und lateraler Servicezugriff, die isoliert betrachtet legitim erscheinen können.
Um die Untersuchungen auf reale Risiken zu konzentrieren, hebt die AWS-Bedrohungserkennung Angreiferverhalten hervor, das aufgrund seiner Sequenz, Absicht und operativen Auswirkungen von Bedeutung ist:
Verfolgen Sie, wie Angreifer Rollen und Identitäten in AWS missbrauchen →
Nicht alle Signale in AWS haben denselben Ermittlungswert. Bei der Erkennung werden Indikatoren priorisiert, die ungewöhnliches oder mehrstufiges Verhalten im Zusammenhang mit einem bestimmten Akteur widerspiegeln. Frühe Indikatoren können subtil und verteilt sein, während Signale im Spätstadium oft erst dann auftreten, wenn bereits erheblicher Schaden entstanden ist.
Um eine schnellere Triage zu ermöglichen, ohne die Absicht eines einzelnen Ereignisses zu erraten, stützt sich die AWS-Bedrohungserkennung auf Signale, die wichtig sind, weil sie dabei helfen, Aktivitäten zuzuordnen und deren Verlauf zu identifizieren:
Die Erkennung von Bedrohungen in AWS hat nach wie vor ihre Grenzen. Zwar kann verdächtiges Verhalten identifiziert werden, doch die Erkennung von Bedrohungen verhindert oder behebt cloud nicht automatisch. Das bedeutet, dass Teams weiterhin auf Reaktionsabläufe und das Urteilsvermögen von Analysten angewiesen sind. Die Verwechslung von Erkennung und Prävention kann zu blinden Flecken führen, die die Eindämmung verzögern.
Hier sind einige häufige Missverständnisse zum Thema Erkennung von Bedrohungen:
Um die Erkennung von Bedrohungen in AWS zu unterstützen, muss das Verhalten von Angreifern über Identitäten, Netzwerke und cloud hinweg als ein einziges Kontinuum verstanden werden. Die Vectra AI geht dieses Problem an, indem sie Aktionen miteinander in Beziehung setzt, anstatt AWS-Ereignisse als isolierte Warnmeldungen zu behandeln. Dadurch wird die Unsicherheit verringert, wenn Rollen, temporäre Anmeldedaten und Aktivitäten über mehrere Dienste hinweg die Zuordnung erschweren.
Zur Verbesserung der Übersichtlichkeit bietet die Vectra AI folgende Vorteile:
Folgen Sie dieser geführten AWS-Angriffstour, um zu sehen, wie kompromittierte Identitäten, Rollenkettung, laterale Bewegungen und Exfiltrationsaktivitäten zu einem einzigen Angriffsverlauf zusammenhängen und wie Teams dies klar untersuchen und darauf reagieren können.
CloudTrail-Überwachung zeichnet einzelne Ereignisse auf, während die AWS-Bedrohungserkennung darauf abzielt, Ereignisse über Identitäten, Rollen, Dienste und Zeiträume hinweg miteinander zu verknüpfen, um das Verhalten von Angreifern aufzudecken. Isolierte Protokollereignisse können zwar zeigen, was passiert ist, aber sie zeigen oft nicht die Absicht oder den Verlauf, insbesondere wenn Angreifer temporäre Anmeldedaten und übernommene Rollen verwenden. Der praktische Unterschied liegt in der Untersuchung: Die Bedrohungserkennung priorisiert mehrstufige Verhaltensmuster, die zugeordnet und bearbeitet werden können, anstatt es den Analysten zu überlassen, die Zusammenhänge aus den Rohprotokollen manuell zusammenzusetzen.
Nein. Die AWS-Bedrohungserkennung verhindert oder behebt architektonische oder konfigurationsbezogene Probleme nicht von selbst. Das Fehlkonfigurationsmanagement konzentriert sich auf die Identifizierung unsicherer Einstellungen und Gefährdungsbedingungen, während die Bedrohungserkennung sich auf die Identifizierung bösartiger oder verdächtiger Aktivitäten innerhalb einer AWS-Umgebung konzentriert. Diese Funktionen zu verwechseln ist problematisch, da Teams möglicherweise davon ausgehen, dass die Erkennung die Konfigurationssicherheit ersetzt, wodurch primäre Einstiegspunkte unberücksichtigt bleiben, während sie erwarten, dass die Bedrohungserkennung dies kompensiert.
Identität und Rollen sind von zentraler Bedeutung, da Angreifer nach der ersten Kompromittierung häufig legitime Zugriffsmechanismen nutzen, darunter auch angenommene Rollen und temporäre Anmeldedaten. Aktionen können auf API-Ebene gültig erscheinen, auch wenn sie einen Missbrauch darstellen. Daher ist die Zuordnung unerlässlich, um zu verstehen, wer eine Sequenz initiiert hat und ob diese Sequenz mit dem erwarteten Verhalten übereinstimmt. Dies ist wichtig, da die Rollenkette den ursprünglichen Akteur verschleiern kann und Untersuchungen fehlschlagen können, wenn sie bei der zuletzt verwendeten temporären Rolle enden.
Mehrstufiges Verhalten, das legitime AWS-Mechanismen nutzt, ist am schwierigsten zu erkennen, wenn es Ereignis für Ereignis bewertet wird. Rollenkettungen, temporäre Anmeldedatensequenzen und Aktionen, die isoliert betrachtet normal erscheinen, erfordern oft eine Korrelation zwischen Diensten und Identitäten, um aussagekräftig zu sein. Diese Muster sind schwierig, da sie über mehrere AWS-Dienste und Zeitfenster verteilt sein können und da die zuletzt verwendeten Anmeldedaten möglicherweise nicht den ursprünglichen Akteur widerspiegeln. Dies ist von Bedeutung, da subtiles Verhalten in der Frühphase übersehen werden kann, bis Indikatoren in der Spätphase auftreten.
Ja, aber nur, wenn der Ansatz Aktivitäten über verschiedene Umgebungen hinweg miteinander verbindet, anstatt AWS als isolierte Domäne zu behandeln. Hybride Angriffe können über kompromittierte Laptops oder Identitätsanbieter erfolgen und später mithilfe vertrauenswürdiger Identitätsbeziehungen und übernommener Rollen auf AWS übergreifen. Ohne Korrelation zwischen Identität und zugehöriger Telemetrie können AWS-Aktivitäten vom ursprünglichen Kompromittierungspfad losgelöst erscheinen. Dies ist wichtig, da Verteidiger verstehen müssen, wie cloud mit früheren Zugriffen zusammenhängen, um den Umfang der Reaktion und die Zuordnung korrekt einschätzen zu können.