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.
# 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`*