Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Operationen Der Betrieb ist der Kern der Reaktion auf Vorfälle. Hier finden die Maßnahmen zur Reaktion und Behebung von Sicherheitsvorfällen statt. Der Betrieb umfasst die folgenden fünf Phasen: *Erkennung*, *Analyse*, *Eindämmung*, *Beseitigung* und *Wiederherstellung*. Eine Beschreibung dieser Phasen und der Ziele finden Sie in Tabelle 3. *Tabelle 3 — Betriebsphasen* | Phase | Ziel | | --- | --- | | Erkennung | Identifizieren eines potenziellen Sicherheitsereignisses. | | Analyse | Stellen Sie fest, ob es sich bei einem Sicherheitsereignis um einen Vorfall handelt, und beurteilen Sie den Umfang des Vorfalls. | | Eindämmung | Minimieren und Beschränken des Umfangs des Sicherheitsereignisses. | | Ausrottung | Entfernen nicht autorisierter Ressourcen oder Artefakte im Zusammenhang mit dem Sicherheitsereignis. Implementieren von Abhilfemaßnahmen zur Behebung der Ursache des Sicherheitsvorfalls. | | Erholung | Stellen Sie die Systeme in einen bekannten sicheren Zustand zurück und überwachen Sie diese Systeme, um sicherzustellen, dass die Bedrohung nicht erneut auftritt. | Die Phasen sollen als Leitfaden für die Reaktion auf Sicherheitsvorfälle und deren Behandlung dienen, damit Sie effektiv und nachhaltig reagieren können. Die tatsächlichen Maßnahmen, die Sie ergreifen, sind abhängig vom jeweiligen Vorfall. Bei einem Vorfall mit Ransomware müssen beispielsweise andere Schritte ausgeführt werden als bei einem Vorfall, an dem ein öffentlicher Amazon-S3-Bucket beteiligt ist. Darüber hinaus folgen diese Phasen nicht unbedingt aufeinander. Nach der Eindämmung und Beseitigung müssen Sie möglicherweise zur Analyse zurückkehren, um zu ermitteln, ob Ihre Maßnahmen wirksam waren. # Erkennung Eine Warnung ist der Hauptbestandteil der Erkennungsphase. Sie generiert eine Benachrichtigung, um den Prozess zur Reaktion auf Vorfälle auf der Grundlage der relevanten Aktivität der AWS Kontobedrohung einzuleiten. Die Genauigkeit von Warnmeldungen ist eine Herausforderung. Es ist nicht immer möglich, mit absoluter Sicherheit zu bestimmen, ob ein Vorfall eingetreten ist, im Gange ist oder ob er in future passieren wird. Hier sind ein paar Gründe: + Erkennungsmechanismen basieren auf Basisabweichungen, bekannten Mustern und Benachrichtigungen von internen oder externen Stellen. + Aufgrund der Unvorhersehbarkeit der Technologie und der Menschen bzw. *der Mittel* und *Akteure von Sicherheitsvorfällen ändern sich die* Ausgangswerte im Laufe der Zeit. Durch neuartige oder modifizierte *Taktiken, *Techniken* und *Verfahren* der Bedrohungsakteure* entstehen bösartige Muster (). TTPs + Änderungen an Mitarbeitern, Technologien und Prozessen werden nicht sofort in den Prozess zur Reaktion auf Vorfälle integriert. Einige werden im Verlauf einer Untersuchung entdeckt. # Quellen der Warnung Sie sollten erwägen, die folgenden Quellen zur Definition von Warnmeldungen zu verwenden: + **Ergebnisse** — AWS Dienste wie [Amazon GuardDuty, Amazon](https://aws.amazon.com/guardduty/) [Macie [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), Amazon](https://aws.amazon.com/macie/) [Inspector [AWS Config](https://aws.amazon.com/config/)](https://aws.amazon.com/inspector/), [IAM Access Analyzer und [Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html)](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) generieren Ergebnisse, die zur Erstellung von Warnmeldungen verwendet werden können. + **Protokolle** — AWS Service-, Infrastruktur- und Anwendungsprotokolle, die in Amazon S3 S3-Buckets und CloudWatch Protokollgruppen gespeichert sind, können analysiert und korreliert werden, um Warnmeldungen zu generieren. + **Abrechnungsaktivität** — Eine plötzliche Änderung der Abrechnungsaktivität kann auf ein Sicherheitsereignis hinweisen. Folgen Sie der Dokumentation unter [Einrichtung eines Fakturierungsalarms zur Überwachung Ihrer geschätzten AWS Gebühren](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html), um dies zu überprüfen. + Informationen zu **Cyberbedrohungen** — Wenn Sie einen Feed mit Informationen zu Cyberbedrohungen eines Drittanbieters abonnieren, können Sie diese Informationen mit anderen Protokollierungs- und Überwachungstools korrelieren, um potenzielle Indikatoren für Ereignisse zu identifizieren. + **Partner-Tools** — Partner im AWS Partner Network (APN) bieten erstklassige Produkte, mit denen Sie Ihre Sicherheitsziele erreichen können. Bei der Reaktion auf Vorfälle können Partnerprodukte mit Endpoint Detection and Response (EDR) oder SIEM dabei helfen, Ihre Ziele bei der Reaktion auf Vorfälle zu unterstützen. Weitere Informationen finden Sie unter [Sicherheitspartnerlösungen](https://aws.amazon.com/security/partner-solutions/) und [Sicherheitslösungen im AWS Marketplace](https://aws.amazon.com/marketplace/solutions/security). + **AWS Vertrauen und Sicherheit** — Wir Support könnten Kunden kontaktieren, wenn wir missbräuchliche oder böswillige Aktivitäten feststellen. + **Einmaliger Kontakt** — Da es Ihre Kunden, Entwickler oder andere Mitarbeiter in Ihrem Unternehmen sein können, denen etwas Ungewöhnliches auffällt, ist es wichtig, dass Sie Ihr Sicherheitsteam über eine bekannte und gut bekannt gemachte Methode kontaktieren. Zu den beliebtesten Optionen gehören Ticketsysteme, Kontakt-E-Mail-Adressen und Webformulare. Wenn Ihre Organisation mit der breiten Öffentlichkeit zusammenarbeitet, benötigen Sie möglicherweise auch einen Sicherheitsmechanismus für die Öffentlichkeit. Weitere Informationen zu Cloud-Funktionen, die Sie bei Ihren Untersuchungen nutzen können, finden Sie [Anhang A: Definitionen der Cloud-Funktionen](appendix-a-cloud-capability-definitions.md) in diesem Dokument. # Erkennung als Teil der Sicherheitskontrolltechnik Erkennungsmechanismen sind ein integraler Bestandteil der Entwicklung der Sicherheitskontrolle. Sobald *Richtlinien* und *präventive* Kontrollen definiert sind, sollten entsprechende *detektive* und *reaktive* Kontrollen eingeführt werden. Beispielsweise richtet eine Organisation eine Direktive für den Root-Benutzer eines AWS Kontos ein, die nur für bestimmte und sehr genau definierte Aktivitäten verwendet werden sollte. Sie verbinden sie mit einer präventiven Kontrolle, die mithilfe der Service Control Policy (SCP) einer AWS Organisation implementiert wird. Wenn Root-Benutzeraktivitäten über den erwarteten Basiswert hinausgehen, wird das Security Operations Center (SOC) durch eine detektive Kontrolle, die mit einer EventBridge Regel und einem SNS-Thema implementiert wurde, benachrichtigt. Bei der Reaktionssteuerung wählt das SOC das passende Playbook aus, führt Analysen durch und arbeitet, bis der Vorfall behoben ist. Sicherheitskontrollen lassen sich am besten anhand der Bedrohungsmodellierung der Workloads definieren, in denen sie ausgeführt werden. AWS Die Wichtigkeit detektiver Kontrollen wird anhand der Business Impact Analysis (BIA) für die jeweilige Arbeitslast festgelegt. Durch detektivische Kontrollen ausgelöste Warnmeldungen werden nicht unmittelbar nach ihrem Eingang behandelt, sondern auf der Grundlage ihrer anfänglichen Kritikalität, die im Laufe der Analyse angepasst werden muss. Die Festlegung der anfänglichen Kritikalität dient als Hilfe bei der Priorisierung. Der Kontext, in dem die Warnung ausgelöst wurde, bestimmt ihre tatsächliche Kritikalität. Beispielsweise verwendet eine Organisation Amazon GuardDuty als Bestandteil der Detective Control, die für EC2-Instances verwendet wird, die Teil eines Workloads sind. Das Ergebnis `Impact:EC2/SuspiciousDomainRequest.Reputation` wird generiert und informiert Sie darüber, dass die aufgelistete Amazon EC2 EC2-Instance innerhalb Ihres Workloads einen Domainnamen abfragt, bei dem der Verdacht besteht, dass er bösartig ist. Diese Warnung ist standardmäßig auf einen niedrigen Schweregrad eingestellt. Im Verlauf der Analysephase wurde festgestellt, dass mehrere hundert EC2-Instances dieses Typs von einem nicht autorisierten Akteur bereitgestellt `p4d.24xlarge` wurden, was die Betriebskosten des Unternehmens erheblich in die Höhe trieb. Zu diesem Zeitpunkt trifft das Incident-Response-Team die Entscheidung, die Kritikalität dieser Warnung auf *hoch* zu setzen, wodurch das Gefühl der Dringlichkeit verstärkt und weitere Maßnahmen beschleunigt werden. Beachten Sie, dass der Schweregrad des GuardDuty Befundes nicht geändert werden kann. # Implementierungen von Detective Control Es ist wichtig zu verstehen, wie Detective Controls implementiert werden, da sie dazu beitragen, zu bestimmen, wie die Warnung für ein bestimmtes Ereignis verwendet wird. Es gibt zwei Hauptimplementierungen von technischen Detektivkontrollen: + Die **Verhaltenserkennung** basiert auf mathematischen Modellen, die allgemein als maschinelles Lernen (ML) oder künstliche Intelligenz (KI) bezeichnet werden. Die Erkennung erfolgt durch Inferenz. Daher spiegelt die Warnung möglicherweise nicht unbedingt ein aktuelles Ereignis wider. + Die **regelbasierte Erkennung** ist deterministisch. Kunden können die genauen Parameter dafür festlegen, bei welcher Aktivität gewarnt werden soll, und das ist sicher. Moderne Implementierungen von Erkennungssystemen, wie z. B. ein Intrusion Detection System (IDS), verfügen in der Regel über beide Mechanismen. Im Folgenden finden Sie einige Beispiele für regelbasierte und verhaltensbasierte Erkennungen mit. GuardDuty + Wenn das Ergebnis generiert `Exfiltration:IAMUser/AnomalousBehavior` wird, werden Sie darüber informiert, dass „in Ihrem Konto eine ungewöhnliche API-Anfrage festgestellt wurde“. Wenn Sie sich die Dokumentation genauer ansehen, erfahren Sie, dass „das ML-Modell alle API-Anfragen in Ihrem Konto auswertet und ungewöhnliche Ereignisse identifiziert, die mit den von Gegnern verwendeten Techniken in Verbindung stehen“, was darauf hindeutet, dass es sich bei diesem Befund um verhaltensbedingte Ergebnisse handelt. + Zu diesem Ergebnis `Impact:S3/MaliciousIPCaller` werden API-Aufrufe vom Amazon S3 S3-Service analysiert und das `SourceIPAddress` Protokollelement mit einer Tabelle mit öffentlichen IP-Adressen verglichen CloudTrail, die Feeds mit Bedrohungsinformationen enthält. GuardDuty Sobald es eine direkte Übereinstimmung mit einem Eintrag findet, generiert es das Ergebnis. Wir empfehlen die Implementierung einer Mischung aus verhaltensbasierten und regelbasierten Warnmeldungen, da es nicht immer möglich ist, regelbasierte Warnmeldungen für jede Aktivität innerhalb Ihres Bedrohungsmodells zu implementieren. # Personengestützte Erkennung Bis zu diesem Zeitpunkt haben wir über technologiegestützte Erkennung gesprochen. Die andere wichtige Erkennungsquelle sind Personen innerhalb oder außerhalb der Organisation des Kunden. *Insider* können als Mitarbeiter oder Auftragnehmer definiert werden, und *Außenstehende* sind Entitäten wie Sicherheitsforscher, Strafverfolgungsbehörden, Nachrichtendienste und soziale Medien. Obwohl die technologiegestützte Erkennung systematisch konfiguriert werden kann, gibt es eine Vielzahl von Formen, wie z. B. E-Mails, Tickets, Post, Nachrichtenbeiträge, Telefonanrufe und persönliche Interaktionen. Es kann davon ausgegangen werden, dass technologiegestützte Erkennungsbenachrichtigungen nahezu in Echtzeit zugestellt werden, es gibt jedoch keine Zeitvorgaben für die Erkennung durch Personen. Es ist unerlässlich, dass die Sicherheitskultur personengestützte Erkennungsmechanismen einbezieht, erleichtert und unterstützt, um einen umfassenden Sicherheitsansatz zu gewährleisten. # Zusammenfassung Bei der Erkennung ist es wichtig, eine Mischung aus regelbasierten und verhaltensorientierten Warnmeldungen zu haben. Darüber hinaus sollten Sie über Mechanismen verfügen, mit denen Personen sowohl intern als auch extern ein Ticket zu einem Sicherheitsproblem einreichen können. Menschen können eine der wertvollsten Quellen für Sicherheitsereignisse sein. Daher ist es wichtig, über Prozesse zu verfügen, mit denen Menschen Bedenken äußern können. Sie sollten die Bedrohungsmodelle Ihrer Umgebung verwenden, um mit der Erkennung von Gebäuden zu beginnen. Mithilfe von Bedrohungsmodellen können Sie Warnmeldungen erstellen, die auf Bedrohungen basieren, die für Ihre Umgebung am relevantesten sind. Schließlich können Sie Frameworks wie MITRE ATT&CK verwenden, um die Taktiken, Techniken und Verfahren von Bedrohungsakteuren zu verstehen (). TTPs Es kann hilfreich sein, das MITRE ATT&CK-Framework als gemeinsame Sprache für Ihre verschiedenen Erkennungsmechanismen zu verwenden. # Analyse Protokolle, Abfragefunktionen und Bedrohungsinformationen sind nur einige der unterstützenden Komponenten, die für die Analysephase erforderlich sind. Viele der zur Erkennung verwendeten Protokolle werden auch für Analysen verwendet und erfordern das Onboarding und die Konfiguration von Abfragetools. # Validierung, Umfang und Bewertung der Auswirkungen der Warnung Während der Analysephase wird eine umfassende Protokollanalyse mit dem Ziel durchgeführt, Warnmeldungen zu validieren, den Umfang zu definieren und die Auswirkungen einer möglichen Gefährdung zu bewerten. + Die *Validierung* der Warnung ist der Ausgangspunkt der Analysephase. Incident-Responder werden nach Protokolleinträgen aus verschiedenen Quellen suchen und sich direkt mit den Eigentümern der betroffenen Workloads in Verbindung setzen. + Die Festlegung des *Geltungsbereichs* ist der nächste Schritt, bei dem alle beteiligten Ressourcen inventarisiert und die Kritikalität der Warnmeldungen angepasst wird, nachdem sich die Beteiligten einig sind, dass es sich wahrscheinlich nicht um ein falsches Positivsignal handelt. + Schließlich wird in der *Folgenabschätzung* die tatsächliche Betriebsunterbrechung detailliert beschrieben. Sobald die betroffenen Workload-Komponenten identifiziert sind, können die Ergebnisse des Scopings mit dem Recovery Point Objective (RPO) und dem Recovery Time Objective (RTO) des jeweiligen Workloads korreliert werden. Dabei wird die Wichtigkeit der Alerts berücksichtigt, wodurch die Ressourcenzuweisung und alle weiteren Aktivitäten eingeleitet werden. Nicht alle Vorfälle beeinträchtigen unmittelbar den Betrieb eines Workloads, der einen Geschäftsprozess unterstützt. Vorfälle wie die Offenlegung vertraulicher Daten, der Diebstahl geistigen Eigentums oder die Entführung von Ressourcen (wie beim Mining von Kryptowährungen) können einen Geschäftsprozess möglicherweise nicht sofort stoppen oder schwächen, können jedoch zu einem späteren Zeitpunkt Konsequenzen haben. # Reichern Sie Sicherheitsprotokolle und Ergebnisse an ## Bereicherung mit Bedrohungsinformationen und organisatorischem Kontext Im Laufe der Analyse müssen die interessierenden Observablen angereichert werden, um die Warnung besser kontextualisieren zu können. Wie im Abschnitt Vorbereitung beschrieben, kann die Integration und Nutzung von Informationen über Cyberbedrohungen hilfreich sein, um mehr über eine Sicherheitsfeststellung zu erfahren. Threat Intelligence Services werden verwendet, um öffentlichen IP-Adressen, Domainnamen und Datei-Hashes Reputation und Eigentumsrechte zuzuweisen. Diese Tools sind als kostenpflichtige und als kostenlose Dienste erhältlich. Kunden, die Amazon Athena als Tool zur Protokollabfrage verwenden, profitieren von den Vorteilen von AWS Glue-Jobs, um Bedrohungsinformationen als Tabellen zu laden. Die Threat-Intelligence-Tabellen können in SQL-Abfragen verwendet werden, um Protokollelemente wie IP-Adressen und Domainnamen zu korrelieren und so eine erweiterte Ansicht der zu analysierenden Daten zu erhalten. AWS GuardDuty stellt Kunden keine Bedrohungsinformationen direkt zur Verfügung, aber Dienste wie Amazon nutzen Bedrohungsinformationen zur Anreicherung und Generierung von Erkenntnissen. Sie können auch benutzerdefinierte Bedrohungslisten hochladen, die auf Ihren eigenen Bedrohungsinformationen GuardDuty basieren. ## Bereicherung durch Automatisierung Automatisierung ist ein integraler Bestandteil der AWS Cloud Unternehmensführung. Sie kann in den verschiedenen Phasen des Incident-Response-Lebenszyklus eingesetzt werden. In der Erkennungsphase gleicht die regelbasierte Automatisierung anhand von Protokollen die für das Bedrohungsmodell relevanten Muster ab und ergreift geeignete Maßnahmen, z. B. das Senden von Benachrichtigungen. In der Analysephase kann der Erkennungsmechanismus genutzt und die Warnmeldung an eine Engine weitergeleitet werden, die in der Lage ist, Protokolle abzufragen und Observables zur Kontextualisierung des Ereignisses anzureichern. **Die Warnstelle besteht in ihrer grundlegenden Form aus einer Ressource und einer Identität.** Beispielsweise könnten Sie eine Automatisierung implementieren, um AWS API-Aktivitäten abzufragen CloudTrail , die von der Identität oder Ressource der Warnmeldungsstelle zum Zeitpunkt der Warnung ausgeführt wurden. Dadurch erhalten Sie zusätzliche Einblicke`eventSource`, einschließlich`eventName`,`SourceIPAddress`, und `userAgent` identifizierter API-Aktivitäten. Durch die automatisierte Ausführung dieser Abfragen können Responder Zeit bei der Triage sparen und zusätzlichen Kontext erhalten, um fundiertere Entscheidungen treffen zu können. Im Blogbeitrag [Wie man AWS Security Hub Hub-Ergebnisse mit Konto-Metadaten anreichert](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/), finden Sie ein Beispiel dafür, wie Sie mithilfe von Automatisierung Sicherheitsergebnisse anreichern und Analysen vereinfachen können. # Sammeln und analysieren Sie forensische Beweise Forensik ist, wie im [Vorbereitung](preparation.md) Abschnitt dieses Dokuments erwähnt, der Prozess der Erfassung und Analyse von Artefakten bei der Reaktion auf Vorfälle. On AWS ist auf Infrastrukturdomänenressourcen wie die Erfassung von Netzwerkdatenverkehrspaketen, Speicherabbilder des Betriebssystems und für Dienstdomänenressourcen wie Protokolle anwendbar. AWS CloudTrail Der forensische Prozess weist die folgenden grundlegenden Merkmale auf: + **Konsistent** — Er folgt exakt den dokumentierten Schritten, ohne Abweichungen. + **Wiederholbar** — Es führt zu exakt den gleichen Ergebnissen, wenn es gegen dasselbe Artefakt wiederholt wird. + **Üblich** — Es ist öffentlich dokumentiert und weit verbreitet. Es ist wichtig, dass für Artefakte, die bei der Reaktion auf Vorfälle gesammelt wurden, eine Kontrollkette eingehalten wird. Neben der Speicherung der Artefakte in schreibgeschützten Repositorys können Automatisierung und die automatische Generierung der Dokumentation dieser Sammlung hilfreich sein. Die Analyse sollte nur an exakten Replikaten der gesammelten Artefakte durchgeführt werden, um die Integrität zu wahren. # Sammeln Sie relevante Artefakte Unter Berücksichtigung dieser Merkmale und auf der Grundlage der entsprechenden Warnmeldungen und der Bewertung der Auswirkungen und des Umfangs müssen Sie die Daten sammeln, die für weitere Untersuchungen und Analysen relevant sind. Verschiedene Arten und Quellen von Daten, die für eine Untersuchung relevant sein könnten, darunter service/control Ebenenprotokolle (CloudTrail, Amazon S3 S3-Datenereignisse, VPC Flow Logs), Daten (Amazon S3 S3-Metadaten und Objekte) und Ressourcen (Datenbanken, Amazon EC2 EC2-Instances). Service/control Flugzeug-Logs können für lokale Analysen gesammelt oder idealerweise direkt über native AWS Dienste (falls zutreffend) abgefragt werden. Daten (einschließlich Metadaten) können direkt abgefragt werden, um relevante Informationen zu erhalten oder die Quellobjekte abzurufen. Verwenden Sie beispielsweise die, AWS CLI um Amazon S3 S3-Bucket- und Objektmetadaten abzurufen und Quellobjekte direkt abzurufen. Ressourcen müssen auf eine Weise gesammelt werden, die dem Ressourcentyp und der beabsichtigten Analysemethode entspricht. Datenbanken können beispielsweise gesammelt werden, indem ein copy/snapshot System erstellt wird, auf dem die Datenbank ausgeführt wird, ein System mit copy/snapshot der gesamten Datenbank selbst oder durch Abfragen und Extrahieren bestimmter Daten und Protokolle aus der Datenbank, die für die Untersuchung relevant sind. Für Amazon EC2 EC2-Instances gibt es einen bestimmten Datensatz, der gesammelt werden sollte, und eine bestimmte Reihenfolge der Erfassung, die durchgeführt werden sollte, um die größtmögliche Menge an Daten für Analysen und Untersuchungen zu erfassen und aufzubewahren. Konkret lautet die Reihenfolge, in der die Antwort die meisten Daten aus einer Amazon EC2 EC2-Instance abruft und speichert, wie folgt: 1. **Instance-Metadaten abrufen** — Erfassen Sie Instance-Metadaten, die für die Untersuchung und Datenabfragen relevant sind (Instance-ID, Typ, IP-Adresse, VPC/subnet ID, Region, Amazon Machine Image (AMI) -ID, angehängte Sicherheitsgruppen, Startzeit). 1. **Instanzschutz und Tags** aktivieren — Aktivieren Sie Instance-Schutzmaßnahmen wie Kündigungsschutz, Einstellung des Shutdown-Verhaltens auf Stopp (falls auf Beenden gesetzt), Deaktivieren von Delete on Termination-Attributen für die angehängten EBS-Volumes und Anwenden geeigneter Tags sowohl für die visuelle Kennzeichnung als auch für die Verwendung in möglichen Reaktionsautomatisierungen (z. B. beim Anwenden eines Tags mit dem Namen `Status` und Wert von`Quarantine`, führen Sie eine forensische Erfassung von Daten durch und isolieren Sie die Instanz). 1. **Festplatte abrufen (EBS-Snapshots)** — Erfassen Sie einen EBS-Snapshot der angehängten EBS-Volumes. Jeder Snapshot enthält die Informationen, die Sie benötigen, um Ihre Daten (ab dem Zeitpunkt, an dem der Snapshot erstellt wurde) auf einem neuen EBS-Volume wiederherzustellen. Sehen Sie sich den Schritt zur Durchführung der response/artifact Live-Erfassung an, wenn Sie Instance-Speicher-Volumes verwenden. 1. **Speicher abrufen** — Da EBS-Snapshots nur Daten erfassen, die auf Ihr Amazon EBS-Volume geschrieben wurden, was möglicherweise Daten ausschließt, die von Ihren Anwendungen oder Ihrem Betriebssystem im Speicher gespeichert oder zwischengespeichert werden, ist es unerlässlich, ein Systemspeicher-Image mit einem geeigneten Open-Source-oder kommerziellen Tool eines Drittanbieters zu erwerben, um verfügbare Daten aus dem System abzurufen. 1. **(Optional) Live-Antwort-/Artefakterfassung** durchführen — Führen Sie eine gezielte Datenerfassung (disk/memory/logs) über Live-Response auf dem System nur durch, wenn Festplatte oder Arbeitsspeicher nicht anderweitig abgerufen werden können oder wenn ein triftiger geschäftlicher oder betrieblicher Grund vorliegt. Dadurch werden wertvolle Systemdaten und Artefakte verändert. 1. **Instance außer Betrieb** nehmen — Trennen Sie die Instance von Auto Scaling Scaling-Gruppen, heben Sie die Registrierung der Instance bei Load Balancers auf und passen Sie ein vorgefertigtes Instance-Profil mit minimierten oder keinen Berechtigungen an oder wenden Sie es an. 1. **Instanz isolieren oder eindämmen** — Stellen Sie sicher, dass die Instanz effektiv von anderen Systemen und Ressourcen in der Umgebung isoliert ist, indem Sie aktuelle und future Verbindungen zu und von der Instance beenden und verhindern. Weitere Informationen finden Sie [Eindämmung](containment.md) im Abschnitt dieses Dokuments. 1. **Wahl des Responders** — Wählen Sie je nach Situation und Zielen eine der folgenden Optionen aus: + Das System außer Betrieb nehmen und herunterfahren (empfohlen). Schalten Sie das System ab, sobald die verfügbaren Beweise vorliegen, um zu überprüfen, wie die Instanz am wirksamsten gegen mögliche future Auswirkungen auf die Umwelt vorbeugen kann. + Führen Sie die Instance weiterhin in einer isolierten Umgebung aus, die für die Überwachung instrumentiert ist. Es wird zwar nicht als Standardansatz empfohlen, aber wenn eine Situation eine kontinuierliche Beobachtung der Instance erfordert (z. B. wenn zusätzliche Daten oder Indikatoren für eine umfassende Untersuchung und Analyse der Instance benötigt werden), können Sie erwägen, die Instance herunterzufahren, ein AMI der Instance zu erstellen und die Instance in Ihrem speziellen forensischen Konto in einer Sandbox-Umgebung neu zu starten, die so konfiguriert ist, dass sie vollständig isoliert und mit Instrumentierung konfiguriert ist, um eine nahezu kontinuierliche Überwachung der Instance zu ermöglichen. (für Beispiel: VPC Flow Logs oder VPC Traffic Mirroring). **Anmerkung** Um verfügbare flüchtige (und wertvolle) Daten zu erfassen, ist es wichtig, den Arbeitsspeicher vor Live-Reaktionsaktivitäten oder der Systemisolierung oder dem Herunterfahren zu erfassen. # Entwickeln Sie Erzählungen Dokumentieren Sie während der Analyse und Untersuchung die ergriffenen Maßnahmen, die durchgeführten Analysen und die identifizierten Informationen, die in den nachfolgenden Phasen und schließlich in einem Abschlussbericht verwendet werden können. Diese Schilderungen sollten kurz und präzise sein und bestätigen, dass relevante Informationen enthalten sind, um ein effektives Verständnis des Vorfalls zu gewährleisten und einen genauen Zeitplan einzuhalten. Sie sind auch hilfreich, wenn Sie Personen außerhalb des Kernteams für die Reaktion auf Vorfälle einbeziehen. Ein Beispiel: **** *Die Marketing- und Vertriebsabteilung erhielt am 15. März 2022 eine Lösegeldforderung, in der die Zahlung in Kryptowährung gefordert wurde, um die öffentliche Veröffentlichung möglicher sensibler Daten zu verhindern. Das SOC stellte fest, dass die Amazon RDS-Datenbank, die zu Marketing und Vertrieb gehört, am 20. Februar 2022 öffentlich zugänglich war. Das SOC fragte die RDS-Zugriffsprotokolle ab und stellte fest, dass die IP-Adresse 198.51.100.23 am 20. Februar 2022 mit den Anmeldeinformationen von *Major* Mary, einer der Webentwicklerinnen`mm03434`, verwendet wurde. Das SOC hat VPC Flow Logs abgefragt und festgestellt, dass ungefähr 256 MB an Daten am selben Tag an dieselbe IP-Adresse übertragen wurden (Zeitstempel 20.02.20T 15:50 \$100Z). Das SOC hat anhand von Open-Source-Bedrohungsinformationen festgestellt, dass die Anmeldeinformationen derzeit im Klartext im öffentlichen Repository verfügbar sind. `https[:]//example[.]com/majormary/rds-utils`* # Eindämmung Eine Definition von Eindämmung in Bezug auf die Reaktion auf Vorfälle ist der Prozess oder die Implementierung einer Strategie bei der Behandlung eines Sicherheitsereignisses, die darauf abzielt, den Umfang des Sicherheitsereignisses zu minimieren und die Auswirkungen einer unbefugten Nutzung innerhalb der Umgebung einzudämmen. Eine Eindämmungsstrategie hängt von einer Vielzahl von Faktoren ab und kann sich von Organisation zu Organisation in Bezug auf die Anwendung der Eindämmungstaktiken, den Zeitpunkt und den Zweck unterscheiden. Der [NIST SP 800-61 Leitfaden zur Behandlung von Computersicherheitsvorfällen](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) beschreibt mehrere Kriterien für die Bestimmung der geeigneten Eindämmungsstrategie, darunter: + Mögliche Beschädigung und Diebstahl von Ressourcen + Notwendigkeit der Beweissicherung + Verfügbarkeit von Diensten (Netzwerkkonnektivität, für externe Parteien bereitgestellte Dienste) + Zeit und Ressourcen, die für die Umsetzung der Strategie benötigt wurden + Wirksamkeit der Strategie (teilweise oder vollständige Eindämmung) + Dauer der Lösung (Notfalllösung muss innerhalb von vier Stunden entfernt werden, vorübergehende Behelfslösung muss in zwei Wochen entfernt werden, permanente Lösung) Hinsichtlich der verfügbaren AWS Dienste lassen sich die grundlegenden Maßnahmen zur Eindämmung jedoch in drei Kategorien unterteilen: + **Eingrenzung von Quellen** — Verwenden Sie Filter und Routing, um den Zugriff von einer bestimmten Quelle aus zu verhindern. + **Technik und Zugriffskontrolle — Sperren** Sie den Zugriff, um unbefugten Zugriff auf die betroffenen Ressourcen zu verhindern. + **Zieleindämmung** — Verwenden Sie Filterung und Routing, um den Zugriff auf eine Zielressource zu verhindern. # Quell-Containment Quelleneinhausung ist die Verwendung und Anwendung von Filtern oder Routing innerhalb einer Umgebung, um den Zugriff auf Ressourcen von einer bestimmten Quell-IP-Adresse oder einem bestimmten Netzwerkbereich aus zu verhindern. Beispiele für die Eingrenzung von Quellen mithilfe von AWS Diensten werden hier hervorgehoben: + **Sicherheitsgruppen** — Das Erstellen und Anwenden isolierter Sicherheitsgruppen auf Amazon EC2 EC2-Instances oder das Entfernen von Regeln aus einer vorhandenen Sicherheitsgruppe kann dazu beitragen, unbefugten Datenverkehr zu einer Amazon EC2 EC2-Instance oder AWS -Ressource einzudämmen. Es ist wichtig zu beachten, dass bestehende nachverfolgte Verbindungen nicht aufgrund wechselnder Sicherheitsgruppen geschlossen werden — nur future Datenverkehr wird von der neuen Sicherheitsgruppe effektiv blockiert (weitere Informationen zu verfolgten und nicht verfolgten Verbindungen finden Sie in [diesem Incident Response Playbook](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md) und in der [Verbindungsverfolgung von Sicherheitsgruppen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)). + **Richtlinien** — Amazon S3 S3-Bucket-Richtlinien können so konfiguriert werden, dass sie Datenverkehr von einer IP-Adresse, einem Netzwerkbereich oder einem VPC-Endpunkt blockieren oder zulassen. Richtlinien ermöglichen es, verdächtige Adressen und den Zugriff auf den Amazon S3 S3-Bucket zu blockieren. Weitere Informationen zu Bucket-Richtlinien finden Sie unter [Hinzufügen einer Bucket-Richtlinie mithilfe der Amazon S3 S3-Konsole](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html). + **AWS WAF **— Web-Zugriffskontrolllisten (Web ACLs) können konfiguriert werden AWS WAF , um eine detaillierte Kontrolle über Webanfragen zu ermöglichen, auf die Ressourcen antworten. Sie können einem IP-Set, für das konfiguriert ist AWS WAF, eine IP-Adresse oder einen Netzwerkbereich hinzufügen und Vergleichsbedingungen wie Sperren auf den IP-Satz anwenden. Dadurch werden Webanfragen an eine Ressource blockiert, wenn die IP-Adresse oder die Netzwerkbereiche des ursprünglichen Datenverkehrs mit den in den IP-Set-Regeln konfigurierten Bereichen übereinstimmen. Ein Beispiel für die Eindämmung von Quellen ist in der folgenden Abbildung zu sehen. Ein Incident-Response-Analyst ändert eine Sicherheitsgruppe einer Amazon EC2 EC2-Instance, um neue Verbindungen nur auf bestimmte IP-Adressen zu beschränken. Wie im Aufzähler Sicherheitsgruppen angegeben, werden bestehende nachverfolgte Verbindungen nicht aufgrund von Änderungen der Sicherheitsgruppen heruntergefahren. ![\[Diagramm, das ein Beispiel für die Quellensperre zeigt\]](http://docs.aws.amazon.com/de_de/security-ir/latest/userguide/images/source-containment-example.png) **Anmerkung** Sicherheitsgruppen und Netzwerk-ACLs filtern keinen Datenverkehr zu Amazon Route 53 Wenn Sie eine EC2-Instance enthalten und verhindern möchten, dass diese externe Hosts kontaktiert, stellen Sie sicher, dass Sie auch die DNS-Kommunikation explizit blockieren. # Technik und Eingrenzung des Zugriffs Verhindern Sie die unbefugte Nutzung einer Ressource, indem Sie die Funktionen und IAM-Prinzipale einschränken, die Zugriff auf die Ressource haben. Dazu gehört die Einschränkung der Berechtigungen von IAM-Prinzipalen, die Zugriff auf die Ressource haben. Dazu gehört auch der vorübergehende Widerruf von Sicherheitsanmeldeinformationen. Beispiele für Technik und Zugriffskontrolle mithilfe von AWS Diensten werden hier hervorgehoben: + **Berechtigungen einschränken** — Die einem IAM-Prinzipal zugewiesenen Berechtigungen sollten dem [Prinzip der geringsten](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) Rechte entsprechen. Während eines aktiven Sicherheitsereignisses müssen Sie jedoch möglicherweise den Zugriff auf eine Zielressource von einem bestimmten IAM-Prinzipal aus noch weiter einschränken. In diesem Fall ist es möglich, den Zugriff auf eine Ressource einzuschränken, indem dem IAM-Prinzipal die entsprechenden Berechtigungen entzogen werden. Dies erfolgt mit dem IAM-Dienst und kann mithilfe des AWS-Managementkonsole AWS CLI, des oder eines AWS SDK angewendet werden. + **Schlüssel widerrufen** — IAM-Zugriffsschlüssel werden von IAM-Prinzipalen für den Zugriff auf oder die Verwaltung von Ressourcen verwendet. [Dabei handelt es sich um langfristige statische Anmeldeinformationen zum Signieren programmatischer Anfragen an die AWS CLIAWS OR-API. Sie beginnen mit dem Präfix *AKIA* (weitere Informationen finden Sie im Abschnitt *Grundlegendes zu eindeutigen ID-Präfixen* unter IAM-Identifikatoren).](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html) Um den Zugriff für einen IAM-Prinzipal einzuschränken, wenn ein IAM-Zugriffsschlüssel kompromittiert wurde, kann der Zugriffsschlüssel deaktiviert oder gelöscht werden. Es ist wichtig, Folgendes zu beachten: + Ein Zugriffsschlüssel kann reaktiviert werden, nachdem er deaktiviert wurde. + Ein Zugriffsschlüssel kann nicht wiederhergestellt werden, sobald er gelöscht wurde. + Ein IAM-Prinzipal kann bis zu zwei Zugriffsschlüssel gleichzeitig haben. + Benutzer oder Anwendungen, die den Zugriffsschlüssel verwenden, verlieren den Zugriff, sobald der Schlüssel entweder deaktiviert oder gelöscht wird. + **Temporäre Sicherheitsanmeldedaten widerrufen** — Temporäre Sicherheitsanmeldedaten können von einer Organisation verwendet werden, um den Zugriff auf AWS Ressourcen zu kontrollieren. Sie beginnen mit dem Präfix *ASIA* (weitere Informationen finden Sie im Abschnitt *Grundlegendes zu eindeutigen ID-Präfixen* unter [IAM-Identifikatoren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)). Temporäre Anmeldeinformationen werden in der Regel von IAM-Rollen verwendet und müssen nicht rotiert oder explizit gesperrt werden, da sie eine begrenzte Lebensdauer haben. In Fällen, in denen vor Ablauf der temporären Anmeldeinformationen ein Sicherheitsereignis eintritt, müssen Sie möglicherweise die effektiven Berechtigungen der vorhandenen temporären Anmeldeinformationen ändern. Dies kann [mithilfe des darin enthaltenen IAM-Dienstes](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) abgeschlossen werden. AWS-Managementkonsole Temporäre Sicherheitsanmeldedaten können auch für IAM-Benutzer ausgestellt werden (im Gegensatz zu IAM-Rollen). Zum Zeitpunkt der Erstellung dieses Artikels gibt es jedoch keine Möglichkeit, die temporären Sicherheitsanmeldedaten für einen IAM-Benutzer innerhalb von zu widerrufen. AWS-Managementkonsole Bei Sicherheitsereignissen, bei denen der IAM-Zugriffsschlüssel eines Benutzers durch einen nicht autorisierten Benutzer kompromittiert wird, der temporäre Sicherheitsanmeldedaten erstellt hat, können die temporären Sicherheitsanmeldedaten auf zwei Arten gesperrt werden: + Fügen Sie dem IAM-Benutzer eine Inline-Richtlinie hinzu, die den Zugriff auf die Dauer der Ausgabe des Sicherheitstokens verhindert (weitere Informationen finden Sie im Abschnitt Sperren des *Zugriffs auf temporäre Sicherheitsanmeldeinformationen, die vor einem bestimmten Zeitpunkt ausgestellt wurden*, unter [Berechtigungen für temporäre Sicherheitsanmeldeinformationen deaktivieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html)). + Löschen Sie den IAM-Benutzer, dem die kompromittierten Zugriffsschlüssel gehören. Erstellen Sie den Benutzer bei Bedarf erneut. + **AWS WAF**- Bestimmte Techniken, die von nicht autorisierten Benutzern eingesetzt werden, beinhalten häufig auftretende bösartige Datenverkehrsmuster, wie z. B. Anfragen, die SQL-Injection und Cross-Site Scripting (XSS) beinhalten. AWS WAF kann mithilfe der integrierten Regelanweisungen so konfiguriert werden, dass der Datenverkehr mithilfe dieser Techniken abgeglichen und abgewiesen wird AWS WAF . Ein Beispiel für Technik und Zugriffskontrolle finden Sie in der folgenden Abbildung. Ein Incident-Responder rotiert die Zugriffsschlüssel oder entfernt eine IAM-Richtlinie, um zu verhindern, dass ein IAM-Benutzer auf einen Amazon S3 S3-Bucket zugreift. ![\[Das Diagramm zeigt ein Beispiel für Technik und Zugriffskontrolle\]](http://docs.aws.amazon.com/de_de/security-ir/latest/userguide/images/technique-and-access-containment.png) # Eindämmung des Ziels Unter Destination Containment versteht man die Anwendung von Filterung oder Routing innerhalb einer Umgebung, um den Zugriff auf einen Zielhost oder eine Zielressource zu verhindern. In einigen Fällen beinhaltet die Eindämmung von Zielen auch eine Form der Resilienz, um zu überprüfen, ob legitime Ressourcen repliziert werden, um ihre Verfügbarkeit sicherzustellen. Ressourcen sollten aus Gründen der Isolierung und Eindämmung von diesen Formen der Resilienz getrennt werden. Zu den Beispielen für die Eindämmung von Zielen mithilfe von Diensten gehören: AWS + **Netzwerk ACLs ** — Für Netzwerke ACLs (Netzwerke ACLs), die in Subnetzen konfiguriert sind, die AWS Ressourcen enthalten, können Ablehnungsregeln hinzugefügt werden. Diese Ablehnungsregeln können angewendet werden, um den Zugriff auf eine bestimmte AWS Ressource zu verhindern. Die Anwendung der Network Access Control List (Network ACL) wirkt sich jedoch auf alle Ressourcen im Subnetz aus, nicht nur auf die Ressourcen, auf die ohne Autorisierung zugegriffen wird. Regeln, die in einer Netzwerk-ACL aufgeführt sind, werden von oben nach unten verarbeitet. Daher sollte die erste Regel in einer vorhandenen Netzwerk-ACL so konfiguriert werden, dass nicht autorisierter Datenverkehr zur Zielressource und zum Zielsubnetz verweigert wird. Alternativ kann eine völlig neue Netzwerk-ACL mit einer einzigen Ablehnungsregel für eingehenden und ausgehenden Verkehr erstellt und dem Subnetz zugeordnet werden, das die Zielressource enthält, um den Zugriff auf das Subnetz mithilfe der neuen Netzwerk-ACL zu verhindern. + **Herunterfahren** — Das vollständige Herunterfahren einer Ressource kann wirksam sein, um die Auswirkungen einer unbefugten Nutzung einzudämmen. Das Herunterfahren einer Ressource verhindert auch den legitimen Zugriff für geschäftliche Zwecke und verhindert, dass flüchtige forensische Daten abgerufen werden. Daher sollte dies eine gezielte Entscheidung sein und anhand der Sicherheitsrichtlinien eines Unternehmens beurteilt werden. + **Isolierung VPCs — Isolierte** VPCs können verwendet werden, um Ressourcen effektiv einzudämmen und gleichzeitig Zugriff auf legitimen Datenverkehr zu gewähren (z. B. Antiviren- (AV) - oder EDR-Lösungen, die Zugriff auf das Internet oder eine externe Managementkonsole erfordern). Isolierte VPCs können vor einem Sicherheitsereignis so vorkonfiguriert werden, dass gültige IP-Adressen und Ports zugelassen werden, und gezielte Ressourcen können während eines aktiven Sicherheitsereignisses sofort in diese Isolierungs-VPC verschoben werden, um die Ressource einzudämmen und gleichzeitig zu ermöglichen, dass legitimer Datenverkehr von der Zielressource in nachfolgenden Phasen der Reaktion auf Vorfälle gesendet und empfangen werden kann. Ein wichtiger Aspekt bei der Verwendung einer isolierten VPC besteht darin, dass Ressourcen wie EC2-Instances vor der Verwendung in der neuen isolierten VPC heruntergefahren und neu gestartet werden müssen. Bestehende EC2-Instances können nicht in eine andere VPC oder eine andere Availability Zone verschoben werden. Folgen Sie dazu den unter [Wie verschiebe ich meine Amazon EC2 EC2-Instance in ein anderes Subnetz, eine Availability Zone oder](https://aws.amazon.com/premiumsupport/knowledge-center/move-ec2-instance/) eine VPC? beschriebenen Schritte. + **Auto Scaling Scaling-Gruppen und Load Balancer** — AWS Ressourcen, die Auto Scaling Scaling-Gruppen und Load Balancern zugeordnet sind, sollten im Rahmen der Zielbeschränkungen getrennt und deregistriert werden. Das Trennen und Deregistrieren von AWS Ressourcen kann mit dem SDK, und durchgeführt werden. AWS-Managementkonsole AWS CLI AWS Das folgende Diagramm zeigt ein Beispiel für die Eindämmung von Zielen. Ein Incident Response Analyst fügt einem Subnetz eine Netzwerk-ACL hinzu, um eine Netzwerkverbindungsanfrage von einem nicht autorisierten Host zu blockieren. ![\[Das Diagramm zeigt ein Beispiel für die Eindämmung von Zielen\]](http://docs.aws.amazon.com/de_de/security-ir/latest/userguide/images/destination-containment.png) # Zusammenfassung Die Eindämmung ist ein Schritt der Reaktion auf Vorfälle und kann manuell oder automatisiert erfolgen. Die allgemeine Eindämmungsstrategie sollte sich an den Sicherheitsrichtlinien und Geschäftsanforderungen eines Unternehmens orientieren und sicherstellen, dass negative Auswirkungen vor der Beseitigung und Wiederherstellung so effizient wie möglich abgemildert werden. # Beseitigung Bei der Beseitigung von Sicherheitsvorfällen handelt es sich um die Entfernung verdächtiger oder nicht autorisierter Ressourcen, um das Konto wieder in einen bekannten sicheren Zustand zu versetzen. Die Strategie zur Beseitigung hängt von mehreren Faktoren ab, die von den Geschäftsanforderungen Ihres Unternehmens abhängen. Der [NIST SP 800-61 Leitfaden zur Behandlung von Computersicherheitsvorfällen](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) enthält mehrere Schritte zur Beseitigung: 1. Identifizieren und beheben Sie alle Sicherheitslücken, die ausgenutzt wurden. 1. Entfernen Sie Malware, unangemessene Materialien und andere Komponenten. 1. Wenn weitere betroffene Hosts entdeckt werden (z. B. neue Malware-Infektionen), wiederholen Sie die Erkennungs- und Analyseschritte, um alle anderen betroffenen Hosts zu identifizieren und den Vorfall dann einzudämmen und zu beseitigen. Bei AWS Ressourcen kann dies anhand der Ereignisse, die mithilfe verfügbarer Protokolle oder automatisierter Tools wie CloudWatch Logs und Amazon GuardDuty erkannt und analysiert werden, weiter verfeinert werden. Diese Ereignisse sollten als Grundlage für die Entscheidung dienen, welche Abhilfemaßnahmen durchgeführt werden sollten, um die Umgebung ordnungsgemäß wieder in einen bekannten sicheren Zustand zu versetzen. Im ersten Schritt der Ausrottung wird festgestellt, welche Ressourcen innerhalb des AWS Kontos betroffen sind. Dies wird durch die Analyse Ihrer verfügbaren Protokolldatenquellen und Ressourcen und automatisierter Tools erreicht. + Identifizieren Sie nicht autorisierte Aktionen, die von den IAM-Identitäten in Ihrem Konto ausgeführt wurden. + Identifizieren Sie unbefugte Zugriffe oder Änderungen an Ihrem Konto. + Identifizieren Sie die Erstellung nicht autorisierter Ressourcen oder IAM-Benutzer. + Identifizieren Sie Systeme oder Ressourcen mit nicht autorisierten Änderungen. Sobald die Liste der Ressourcen identifiziert ist, sollten Sie jede einzelne überprüfen, um festzustellen, welche Auswirkungen das Löschen oder Wiederherstellen der Ressource auf Ihr Unternehmen hat. Wenn beispielsweise ein Webserver Ihre Geschäftsanwendung hostet und das Löschen dieser Anwendung zu Ausfallzeiten führen würde, sollten Sie erwägen, die Ressource aus verifizierten sicheren Backups wiederherzustellen oder das System von einem sauberen AMI aus neu zu starten, bevor Sie den betroffenen Server löschen. Sobald Sie Ihre Geschäftsauswirkungsanalyse abgeschlossen haben, sollten Sie anhand der Ereignisse aus Ihrer Protokollanalyse die Konten überprüfen und die entsprechenden Abhilfemaßnahmen durchführen, z. B.: + Schlüssel rotieren oder löschen — durch diesen Schritt wird dem Akteur die Möglichkeit genommen, weiterhin Aktivitäten innerhalb des Accounts auszuführen. + Potenziell nicht autorisierte IAM-Benutzeranmeldedaten rotieren. + Löschen Sie unbekannte oder nicht autorisierte Ressourcen. **Wichtig** Wenn Sie Ressourcen für Ihre Untersuchung behalten müssen, sollten Sie erwägen, diese Ressourcen zu sichern. Wenn Sie beispielsweise aus regulatorischen, behördlichen oder rechtlichen Gründen eine Amazon EC2 EC2-Instance behalten müssen, [erstellen Sie einen Amazon EBS-Snapshot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html), bevor Sie die Instance entfernen. + Bei Malware-Infektionen müssen Sie sich möglicherweise an einen AWS Partner oder einen anderen Anbieter wenden. AWS bietet keine systemeigenen Tools zur Analyse oder Entfernung von Malware. Wenn Sie jedoch das GuardDuty Malware-Modul für Amazon EBS verwenden, sind möglicherweise Empfehlungen für die bereitgestellten Ergebnisse verfügbar. Sobald Sie die identifizierten betroffenen Ressourcen gelöscht haben, AWS empfiehlt Ihnen, eine Sicherheitsüberprüfung Ihres Kontos durchzuführen. Dies kann mithilfe von AWS Config Regeln, mithilfe von Open-Source-Lösungen wie Prowler und/oder durch andere Anbieter ScoutSuite geschehen. Sie sollten auch in Betracht ziehen, Sicherheitslücken in Ihren öffentlich zugänglichen Ressourcen (Internet) zu scannen, um das Restrisiko einzuschätzen. Die Beseitigung ist ein Schritt der Reaktion auf Vorfälle und kann je nach Vorfall und betroffenen Ressourcen manuell oder automatisiert erfolgen. Die Gesamtstrategie sollte sich an den Sicherheitsrichtlinien und Geschäftsanforderungen eines Unternehmens orientieren und sicherstellen, dass negative Auswirkungen durch das Entfernen ungeeigneter Ressourcen oder Konfigurationen gemildert werden. # Wiederherstellung Bei der Wiederherstellung werden Systeme in einen bekannten sicheren Zustand zurückversetzt, wobei vor der Wiederherstellung überprüft wird, ob Backups sicher sind oder nicht vom Vorfall betroffen sind. Außerdem werden Tests durchgeführt, um sicherzustellen, dass die Systeme nach der Wiederherstellung ordnungsgemäß funktionieren, und die Behebung von Sicherheitslücken im Zusammenhang mit dem Sicherheitsereignis. Die Reihenfolge der Wiederherstellung hängt von den Anforderungen Ihres Unternehmens ab. Im Rahmen des Wiederherstellungsprozesses sollten Sie eine Analyse der Geschäftsauswirkungen durchführen, um mindestens Folgendes zu ermitteln: + Geschäftsprioritäten oder Abhängigkeiten + Der Sanierungsplan + Authentifizierung und Autorisierung Der NIST SP 800-61 Leitfaden zur Behandlung von Computersicherheitsvorfällen enthält mehrere Schritte zur Wiederherstellung von Systemen, darunter: + Wiederherstellung von Systemen aus sauberen Backups. + Stellen Sie sicher, dass die Backups vor der Wiederherstellung auf den Systemen geprüft wurden, um sicherzustellen, dass die Infektion nicht vorhanden ist, und um ein erneutes Auftreten des Sicherheitsereignisses zu verhindern. Backups sollten im Rahmen von Disaster-Recovery-Tests regelmäßig überprüft werden, um sicherzustellen, dass der Backup-Mechanismus ordnungsgemäß funktioniert und die Datenintegrität den Wiederherstellungszielen entspricht. + Verwenden Sie nach Möglichkeit Backups, die vor dem Zeitstempel des ersten Ereignisses erstellt wurden, das im Rahmen der Ursachenanalyse ermittelt wurde. + Neuaufbau von Systemen von Grund auf, einschließlich der Neubereitstellung aus einer vertrauenswürdigen Quelle mithilfe von Automatisierung, manchmal in einem neuen Konto. AWS + Kompromittierte Dateien durch saubere Versionen ersetzen. Sie sollten dabei große Vorsicht walten lassen. Sie müssen absolut sicher sein, dass die Datei, die Sie wiederherstellen, als sicher gilt und von dem Vorfall nicht betroffen ist + Patches installieren. + Passwörter ändern. + Dazu gehören Passwörter für IAM-Prinzipale, die möglicherweise missbraucht wurden. + Wenn möglich, empfehlen wir die Verwendung von Rollen für IAM-Prinzipale und den Verbund als Teil einer Strategie der geringsten Rechte. + Verschärfung der Netzwerkperimetersicherheit (Firewall-Regelsätze, Zugriffskontrolllisten für Boundary-Router). Sobald die Ressourcen wiederhergestellt sind, ist es wichtig, die gewonnenen Erkenntnisse zu nutzen, um Richtlinien, Verfahren und Leitfäden zur Reaktion auf Vorfälle zu aktualisieren. Zusammenfassend lässt sich sagen, dass es unerlässlich ist, einen Wiederherstellungsprozess zu implementieren, der die Rückkehr zu bekanntermaßen sicheren Betriebsabläufen erleichtert. Die Wiederherstellung kann lange dauern und erfordert eine enge Verknüpfung mit Eindämmungsstrategien, um die geschäftlichen Auswirkungen gegen das Risiko einer erneuten Infektion abzuwägen. Die Wiederherstellungsverfahren sollten Schritte zur Wiederherstellung von Ressourcen und Diensten, IAM-Prinzipalen und zur Durchführung einer Sicherheitsüberprüfung des Kontos zur Bewertung des Restrisikos umfassen. # Schlussfolgerung Jede Betriebsphase hat eigene Ziele, Techniken, Methoden und Strategien. Tabelle 4 fasst diese Phasen und einige der in diesem Abschnitt behandelten Techniken und Methoden zusammen. *Tabelle 4 — Betriebsphasen: Ziele, Techniken und Methoden* | Phase | Ziel | Techniken und Methoden | | --- | --- | --- | | Erkennung | Identifizieren eines potenziellen Sicherheitsereignisses. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/security-ir/latest/userguide/operations-conclusion.html) | | Analyse | Stellen Sie fest, ob es sich bei dem Sicherheitsereignis um einen Vorfall handelt, und beurteilen Sie den Umfang des Vorfalls. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/security-ir/latest/userguide/operations-conclusion.html) | | Eindämmung | Minimiert und begrenzt die Auswirkungen des Sicherheitsereignisses. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/security-ir/latest/userguide/operations-conclusion.html) | | Ausrottung | Entfernen nicht autorisierter Ressourcen oder Artefakte im Zusammenhang mit dem Sicherheitsereignis. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/security-ir/latest/userguide/operations-conclusion.html) | | Wiederherstellung | Stellen Sie den zweifelsfrei funktionierenden Zustand der Systeme wieder her und überwachen Sie diese Systeme, um sicherzustellen, dass die Bedrohung nicht erneut auftritt. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/security-ir/latest/userguide/operations-conclusion.html) |