Jede Organisation mit sensiblen Daten kann das Ziel eines Cyberangriffs sein, unabhängig von ihrer Größe oder Branche. Da immer mehr Unternehmen auf die Website cloud umsteigen, entwickelt sich die Bedrohungslandschaft immer schneller, und die Angreifer setzen fortschrittliche Taktiken ein, um ihr Ziel zu erreichen. Die Reaktion auf Vorfälle spielt eine entscheidende Rolle, wenn es darum geht, Ihre Daten zu schützen und zu verhindern, dass ein Angriff Ihr Unternehmen in Mitleidenschaft zieht.
Die Grundlage eines erfolgreichen cloud Incident-Response-Programms konzentriert sich auf die Vorbereitung, den Betrieb und die Aktivitäten nach einem Vorfall. NIST und SANS - beides vertrauenswürdige Organisationen - haben IR-Frameworks mit Incident-Response-Schritten entwickelt, die eng mit diesen Phasen übereinstimmen. Vectra AI CDR für AWS Incident Response wurde auf der Grundlage dieser Phasen entwickelt, aus der Notwendigkeit heraus, mit dem NIST Incident Response-Lebenszyklus übereinzustimmen, gekoppelt mit Operationen, die KI-gesteuerte Erkennung, Analyse mit Eindämmung, Ausmerzung und Wiederherstellung umfassen. Der AWS Security Incident Response-Leitfaden beschreibt viele Methoden zur Automatisierung von Incident Response-Techniken.
Im Leitfaden zur Reaktion auf AWS-Sicherheitsvorfälle wird erläutert, dass die Vorbereitung auf einen Vorfall entscheidend ist. Nach der Erkennung eines Ereignisses in der Erkennungsphase einer Vorfallsreaktion und der Analyse in der Analysephase können Sie die automatisierte Lösung zur Eindämmung der vier unterstützten AWS-Services verwenden. Die Eindämmung des Vorfalls ist entscheidend, um Bedrohungen in Echtzeit zu bekämpfen. Wie sieht eine automatisierte Eindämmungsinstanz aus?
Warum Vectra's AWS Entity Lockdown
Sicherheit hat bei Vectra höchste Priorität. AWS hat ein Modell der geteilten Verantwortung: AWS verwaltet die Sicherheit von cloud, und die Kunden sind für die Sicherheit auf cloud verantwortlich. Ein solches Modell überlässt dem Kunden die vollständige Kontrolle über seine Sicherheitsimplementierung, die Reaktion auf Sicherheitsvorfälle kann jedoch komplex sein. Die Übernahme der Automatisierungsfunktionen von Vectra CDR für AWS Entity Lockdown verbessert die Reaktionsgeschwindigkeit Ihrer SecOps-Teams und vereinfacht die Reaktion auf Vorfälle, so dass Ihr Unternehmen besser vorbereitet ist, wenn ein Ereignis eintritt, und die Bedrohung minimieren kann, bevor sie in Ihrem Unternehmen Schaden anrichten kann.
So machen wir es:
SecOps müssen reagieren und untersuchen, wenn eine Abweichung von der Baseline auftritt, z. B. durch eine Fehlkonfiguration oder eine Änderung externer Faktoren. Vectra Die CDR for AWS Entity Lockdown-Lösung bereitet Ihr Team besser auf Sicherheitsereignisse vor, indem sie Folgendes bietet:
- AWS-Prinzip der geringsten Privilegien: Es muss nur eine SNS-Veröffentlichungsberechtigung offengelegt werden. Streng kontrollierter Zugriff.
- Automatisierter Arbeitsablauf: Die Lösung kann problemlos in bestehende Arbeitsabläufe integriert und automatisch aktiviert werden, um eine Out-of-Band-Kontrolle zu gewährleisten und so zu verhindern, dass Angriffe eskalieren und sich auswirken.
- Automatischer Prüfpfad: Die Lösung ermöglicht die Überprüfung der Einhaltung von Vorschriften und die Protokollierung.
- Regions- und kontoübergreifend: Arbeiten Sie von einem einzigen Standort aus in Ihrer gesamten AWS-Umgebung, um die Nutzung zu vereinfachen.
- Spezifisch/Zielgerichtet: Stellt sicher, dass die kompromittierten Anmeldedaten umfassend gesperrt werden, damit der Angreifer nicht einfach einen anderen Angriffspfad nutzen kann. Dadurch wird sichergestellt, dass nur die kompromittierten Anmeldeinformationen gesperrt werden, um eine Beeinträchtigung der normalen Geschäftsabläufe zu vermeiden.
Architektur und Design der AWS-Einhausung
Vectra CDR für AWS verwendet eine AWS SNS-Themennachricht, um eine Lambda-Funktion auszulösen. Zunächst wird die AWS SNS-Nachricht entweder manuell oder über ein Tool eines Drittanbieters, z. B. Amazon Security Hub oder SOAR, veröffentlicht. Dann löst der Lambda-Code weitere Aktionen aus, die auf dem Inhalt der Nachricht basieren. Die SNS-Nachricht erfordert zwei Nachrichtenattribute. Eine ARN der zu isolierenden Entität und eine ExtranalId. Der Benutzer legt die ExtranalId während der Bereitstellung der CloudFormation-Vorlage fest. Dieses Feld ist statisch und wird zur Validierung der SNS-Nachricht durch die Incident Response Lambda-Funktion verwendet.
Damit werden die folgenden Aufgaben erfüllt, wie in Abbildung 1 dargestellt:
- Eine AWS SNS-Nachricht wird mit einem AWS-Entity-ARN für Containment und ExternalId veröffentlicht.
- Eine AWS Lambda-Funktion wird durch die SNS-Nachricht aufgerufen. Die Lambda-Funktion führt die Geschäftslogik für die Vorfallsreaktion auf der Grundlage des Entitätstyps aus.
- Während des gesamten Prozesses wird eine AWS SNS-Audit-E-Mail an den Benutzer gesendet. Eine E-Mail für den Start des Prozesses, eine für Erfolg oder Misserfolg und eine, wenn die Nachricht in die Warteschlange für tote Buchstaben fällt.
Wenn die Lambda-Funktion aufgerufen wird, wird die folgende Geschäftslogik ausgeführt: Die Geschäftslogik der Vorfallsreaktion ist in Abbildung 2 dargestellt.
Bestimmen Sie den AWS-Entitätstyp. Unterstützte Entitäten: Lambda, IAM User, IAM Role und EC2.
DieLambda -Funktion fügt eine DenyAll AWS-verwaltete Richtlinie hinzu, wenn der Entitätstyp IAM Role oder User ist.
Wenn der Entitätstyp eine AWS Lambda-Funktion ist, wird die folgende Logik angewendet:
- Fügen Sie der Lambda-Ausführungsrolle die verwaltete AWS-Richtlinie DenyAll hinzu.
- Setzen Sie die Lambda-Funktions-Eigenschaft function_currency auf 0. Dadurch wird verhindert, dass die Funktion ausgelöst wird.
Die folgende Logik wird angewendet, wenn der Entitätstyp eine AWS EC2-Instanz ist.
Sicherheitsgruppenregeln beginnen mit einer impliziten Verweigerung des gesamten Datenverkehrs. Wenn keine Regeln vorhanden sind, erstellen Sie Regeln, die bestimmten Datenverkehr zulassen. Eingehender Datenverkehr wird unabhängig von den Regeln für ausgehenden Datenverkehr zugelassen und umgekehrt; auf diese Weise implementiert AWS zustandsabhängige Verbindungen innerhalb von Sicherheitsgruppen. Sie können jederzeit Regeln hinzufügen oder entfernen, und die Änderungen werden sofort auf die mit der Sicherheitsgruppe verbundenen Instanzen angewendet. Die Auswirkungen einiger Regeländerungen können jedoch davon abhängen, wie der Datenverkehr nachverfolgt wird. Das Verständnis der Funktionsweise verfolgter Verbindungen ist für die Implementierung einer effektiven Sicherheitsgruppeneinschränkung von entscheidender Bedeutung. Wenn eine Verbindung nachverfolgt wird, kann sie die Internetkonnektivität aufrechterhalten, obwohl sie einer Sicherheitsgruppe ohne Regeln zugeordnet ist. Sicherheitsgruppen verwenden die Verbindungsverfolgung, um Informationen über den Datenverkehr zur und von der Instanz zu verfolgen - auf diese Weise werden zustandsabhängige Verbindungen implementiert, auch wenn nicht alle Datenströme verfolgt werden. Es gibt eine Ausnahme... ICMP-Verkehr wird immer verfolgt.
Nicht verfolgte Verbindungen gelten für alle Verkehrsarten mit einer Vier-Null-Regel für alle Ports in beide Richtungen. Sie können ein Beispiel für verfolgte und nicht verfolgte Verbindungen sehen.
- TCP- oder UDP-Verkehrsströme für den gesamten Verkehr (0.0.0.0/0 Verfolgt. :/0) und es gibt eine entsprechende Regel in der anderen Richtung, die den gesamten Antwortverkehr (0.0.0.0/0 oder :/0) für alle Ports (0-65535) zulässt, dann wird dieser Verkehrsstrom nicht verfolgt - Nicht verfolgt.
- Eingehender und ausgehender TCP-Verkehr an Port 22 (SSH) wird verfolgt, da die Eingangsregel nur den Verkehr von 203.0.113.1/32 und nicht von allen IP-Adressen (0.0.0.0/0) zulässt - Verfolgt.
- Eingehender und ausgehender TCP-Verkehr an Port 80 (HTTP) wird nicht verfolgt, da die Regeln für eingehenden und ausgehenden Verkehr den Verkehr von allen IP-Adressen zulassen.
- ICMP-Verkehr wird immer verfolgt - Verfolgt.
Wenn Sie die ausgehende Regel für IPv4-Verkehr entfernen, wird der gesamte ein- und ausgehende IPv4-Verkehr verfolgt, einschließlich des Verkehrs auf Port 80 (HTTP). Dasselbe gilt für IPv6-Verkehr, wenn Sie die ausgehende Regel für IPv6-Verkehr entfernen. - Überwacht.
Sicherheitsgruppen sind sehr effektiv und zielen auf die Eingrenzung einer einzelnen Ec2-Instanz ab. Das Beenden von verfolgten und nicht verfolgten Verbindungen erfordert einen mehrstufigen Prozess, um aktive Verbindungen zu beenden und zukünftige zu verhindern. Alle nicht verfolgten Verbindungen werden sofort beendet, wenn die Vectra Entity Lockdown-Lösung angewendet wird. Es werden jedoch nur aktive verfolgte Verbindungen beendet, was sehr wichtig zu verstehen ist. In unserer Lösung sind aktive Verbindungen alle Verbindungen, bei denen kontinuierlich oder in Abständen von nicht mehr als einer Minute Netzwerkverkehr stattfindet.
Die folgende Lösung eignet sich für kontinuierlich aktive Verbindungen. Zum Beispiel, wenn die kompromittierte EC2-Instanz für Krypto-Mining verwendet wird oder Teil eines Ransomware-Angriffs ist.
Wenn die Incident Response Lambda-Funktion aufgerufen wird und der zu isolierende Entitätstyp eine AWS EC2-Instanz ist, werden die folgenden Aktionen durchgeführt.
- Fügen Sie eine bedingte Richtlinie hinzu, um dem Instance-Profil für eine gefährdete EC2-Instanz alle Aktionen zu verweigern. Viele Lösungen schlagen vor, die Instance Profile Role von der Instanz zu trennen. Eine solche Maßnahme würde die Instanz zwar daran hindern, neue Sitzungen zu initiieren, sie würde jedoch nicht die bestehenden Sitzungen aufheben. Wenn der Angreifer beispielsweise eine falsch konfigurierte Anwendung ausnutzt und Sicherheitsanmeldeinformationen aus den Metadaten der Instanz erhält, bleiben diese Anmeldeinformationen bis zu 12 Stunden lang aktiv.
- Überprüft die VPC, in der sich die EC2-Instanzen befinden, ob eine Sicherheitsgruppe für nicht verfolgte Verbindungen existiert; falls nicht, wird eine erstellt und die Sicherheitsgruppe dann auf die Instanz angewendet. Diese Sicherheitsgruppe hat eine einzige Eingangs- und Ausgangsregel von 0.0.0.0/0, die verfolgte in nicht verfolgte Verbindungen umwandelt.
- Überprüfen Sie die VPC auf das Vorhandensein einer Isolationssicherheitsgruppe. Wenn keine vorhanden ist, erstellen Sie eine und wenden Sie die Sicherheitsgruppe auf die Instanz an. Diese Sicherheitsgruppe hat keine Eingangs- und Ausgangsregeln. Durch die Zuweisung dieser Sicherheitsgruppe wird die EC2-Instanz vollständig isoliert.
Bereitstellen von Vectra CDR für AWS
Um Vectra CDR für AWS bereitzustellen, müssen Sie zunächst auf die CloudFormation-Vorlagen zugreifen. Wenn Sie ein AWS-Konto verwenden, benötigen Sie nur die Vorlage für die Bereitstellung der Incident Response Resource. Sie müssen jedoch zwei Vorlagen bereitstellen, wenn Sie eine Einrichtung mit mehreren Konten haben und eine kontenübergreifende Incident Response-Lösung wünschen. Wenn Sie die erste Vorlage in Ihrem AWS-Sicherheitskonto bereitstellen, werden die Ressourcen für die Reaktion auf Vorfälle gehostet. Die zweite Vorlage erstellt eine kontoübergreifende IAM-Rolle in den anderen Konten, die von der Lösung abgedeckt werden sollen. In der README der Lösung werden die AWS CloudFormation-Vorlagen und Stack-Details vollständig dokumentiert. Weitere Ressourcen finden Sie im GitHub-Repository.
Vectra CDR für AWS-Automatisierung
Um mit der Automatisierung zu beginnen, müssen Sie zunächst Vectra CDR für AWS CloudFormation Stack bereitstellen. Wenn Sie die AWS-Konsole verwenden, können Sie dann eine SNS-Nachricht über den Service-Ressourcen-Bildschirm veröffentlichen. Wenn Sie die AWS CLI oder das AWS SDK verwenden möchten, finden Sie den Incident Response SNS ARN auf der Registerkarte "AWS CloudFormation Stack Output". Eine detaillierte Anleitung für jeden Ansatz finden Sie in der README des GitHub-Repositorys.
Eingrenzung von AWS-Vorfällen
Wie bereits erwähnt, benötigt Ihr SOC-Analyst durch Befolgung der CloudFormation nur SNS-Veröffentlichungsrechte, um auf einen AWS-Vorfall zu reagieren. Ein Sicherheitsservice wie Amazon Security Hub oder SOAR kann auch eine Nachricht als Teil des Arbeitsablaufs des SecOps-Teams veröffentlichen. Daher benötigt der SOC-Analyst keine administrativen Berechtigungen für verdächtige AWS-Services. Wenn Sie die beschriebenen Schritte befolgen, ist Ihr SecOps-Team in der Lage, eine Reaktion auf einen Vorfall zu erstellen, indem es native AWS-Tools verwendet. Diese Methodik unterstützt auch die konto- und regionenübergreifende Eindämmung. Wenn Sie den Stack in jedem Konto löschen, ist eine manuelle Bereinigung erforderlich, um diese für die EC2-Isolierung erstellten Sicherheitsgruppen zu entfernen.
Die Reaktion auf Vorfälle ist ein wesentlicher Bestandteil einer Cybersicherheitsstrategie für alle Unternehmen. Mit AWS Incident Containment hat Ihr SecOps-Team die Gewissheit, dass es weiß, wie es die Isolierung einer EC2-Instanz, eines IAM-Benutzers und einer Rolle sowie einer Lambda-Funktion automatisieren kann, um auf verdächtige Entitäten in Ihrer AWS-Umgebung zu reagieren.
Was kommt als Nächstes?
Erleben Sie die Leistungsfähigkeit von Vectra CDR für AWS aus erster Hand mit unserer kostenlosen Testversion.