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. # Prozess Die Entwicklung gründlicher und klar definierter Prozesse zur Reaktion auf Vorfälle ist der Schlüssel zu einem erfolgreichen und skalierbaren Programm zur Reaktion auf Vorfälle. Wenn ein Sicherheitsereignis eintritt, helfen Ihnen klare Schritte und Workflows dabei, rechtzeitig zu reagieren. Möglicherweise verfügen Sie bereits über Prozesse zur Reaktion auf Vorfälle. Unabhängig von Ihrem aktuellen Status ist es wichtig, Ihre Prozesse zur Vorfallreaktion regelmäßig zu aktualisieren, zu wiederholen und zu testen. # Entwickeln und testen Sie einen Plan zur Reaktion auf Vorfälle Das erste Dokument, das für die Reaktion auf Vorfälle entwickelt werden muss, ist der *Plan zur Reaktion auf Vorfälle*. Der Vorfallreaktionsplan ist als Grundlage für Ihr Vorfallreaktionsprogramm und Ihre Vorfallreaktionsstrategie konzipiert. Ein Notfallplan ist ein Dokument auf hoher Ebene, das in der Regel die folgenden Abschnitte umfasst: + **Überblick über das Incident-Response-Team** — Beschreibt die Ziele und Funktionen des Incident-Response-Teams + **Rollen und Zuständigkeiten** — Führt die Beteiligten für die Reaktion auf Vorfälle auf und beschreibt ihre Rollen, wenn ein Vorfall eintritt + **Ein Kommunikationsplan — Erläutert** die Kontaktinformationen und die Art und Weise, wie Sie während eines Vorfalls kommunizieren werden Es hat sich bewährt, die out-of-band Kommunikation als Backup für die Kommunikation bei Zwischenfällen zu nutzen. Ein Beispiel für eine Anwendung, die einen sicheren out-of-band Kommunikationskanal bereitstellt, ist [AWS Wickr.](https://aws.amazon.com/wickr/) + **Phasen der Reaktion auf Vorfälle und zu ergreifende Maßnahmen** — Führt die Phasen der Reaktion auf Vorfälle auf, z. B. Erkennung, Analyse, Beseitigung, Eindämmung und Wiederherstellung — einschließlich der in diesen Phasen zu ergreifenden Maßnahmen auf hoher Ebene + **Definitionen für Schweregrad und Priorisierung von Vorfällen** — Erläutert, wie der Schweregrad eines Vorfalls klassifiziert wird, wie der Vorfall priorisiert wird und wie sich die Schweregraddefinitionen dann auf die Eskalationsverfahren auswirken Diese Abschnitte sind zwar in Unternehmen verschiedener Größen und Branchen üblich, der Vorfallreaktionsplan ist jedoch für jede Organisation individuell. Sie müssen einen Plan zur Reaktion auf Vorfälle erstellen, der für Ihr Unternehmen am besten geeignet ist. # Dokumentieren und zentralisieren Sie Architekturdiagramme Um schnell und präzise auf ein Sicherheitsereignis reagieren zu können, müssen Sie wissen, wie Ihre Systeme und Netzwerke aufgebaut sind. Das Verständnis dieser internen Muster ist nicht nur wichtig für die Reaktion auf Vorfälle, sondern auch für die Überprüfung der Konsistenz zwischen den Anwendungen, auf denen die Muster basieren, gemäß bewährten Methoden. Sie sollten auch sicherstellen, dass diese Dokumentation auf dem neuesten Stand ist und regelmäßig gemäß neuen Architekturmustern aktualisiert wird. Sie sollten Dokumentationen und interne Repositorien entwickeln, in denen unter anderem folgende Elemente detailliert beschrieben werden: + **AWS Kontostruktur** — Sie müssen wissen: + Wie viele AWS Konten haben Sie? + Wie sind diese AWS Konten organisiert? + Wer sind die Geschäftsinhaber der AWS Konten? + Verwenden Sie Service Control-Richtlinien (SCPs)? Falls ja, welche organisatorischen Leitplanken werden verwendet? SCPs + Beschränken Sie die Regionen und Dienste, die genutzt werden können? + Welche Unterschiede gibt es zwischen Geschäftsbereichen und Umgebungen (dev/test/prod)? + **AWS Servicemuster** + Welche AWS Dienste nutzen Sie? + Was sind die am häufigsten genutzten AWS Dienste? + **Architekturmuster** + Welche Cloud-Architekturen verwenden Sie? + **AWS Authentifizierungsmuster** + Wie authentifizieren sich Ihre Entwickler normalerweise? AWS + Verwenden Sie IAM-Rollen oder Benutzer (oder beides)? Ist Ihre Authentifizierung mit einem Identity Provider (IdP) AWS verbunden? + Wie ordnen Sie eine IAM-Rolle oder einen IAM-Benutzer einem Mitarbeiter oder System zu? + Wie wird der Zugriff gesperrt, wenn jemand nicht mehr autorisiert ist? + **AWS Autorisierungsmuster** + Welche IAM-Richtlinien verwenden Ihre Entwickler? + Verwenden Sie ressourcenbasierte Richtlinien? + **Protokollierung und Überwachung** + Welche Protokollierungsquellen verwenden Sie und wo werden sie gespeichert? + Aggregieren Sie AWS CloudTrail Logs? Falls ja, wo werden sie gespeichert? + Wie fragt man CloudTrail Logs ab? + Haben Sie Amazon GuardDuty aktiviert? + Wie greifen Sie auf GuardDuty Ergebnisse zu (z. B. Konsole, Ticketsystem, SIEM)? + Werden Ergebnisse oder Ereignisse in einem SIEM zusammengefasst? + Werden Tickets automatisch erstellt? + Welche Tools stehen zur Verfügung, um Protokolle für eine Untersuchung zu analysieren? + **Netzwerktopologie** + Wie sind Geräte, Endpunkte und Verbindungen in Ihrem Netzwerk physisch oder logisch angeordnet? + Wie verbindet sich Ihr Netzwerk mit? AWS + Wie wird der Netzwerkverkehr zwischen Umgebungen gefiltert? + **Externe Infrastruktur** + Wie werden nach außen gerichtete Anwendungen bereitgestellt? + Welche AWS Ressourcen sind öffentlich zugänglich? + Welche AWS Konten enthalten Infrastrukturen, die nach außen gerichtet sind? + Welche DDo S- oder externe Filterung gibt es? Die Dokumentation interner technischer Diagramme und Prozesse erleichtert den Incident-Response-Analysten die Arbeit und hilft ihnen, sich schnell das institutionelle Wissen anzueignen, um auf ein Sicherheitsereignis zu reagieren. Eine gründliche Dokumentation der internen technischen Prozesse vereinfacht nicht nur Sicherheitsuntersuchungen, sondern dient auch der Rationalisierung und Bewertung der Prozesse. # Entwickeln Sie Playbooks zur Reaktion auf Vorfälle Ein wichtiger Teil der Vorbereitung Ihrer Prozesse zur Vorfallreaktion ist die Entwicklung von Playbooks. Playbooks für die Vorfallreaktion enthalten eine Reihe von präskriptiven Anleitungen und Schritten, die Sie befolgen müssen, wenn ein Sicherheitsereignis eintritt. Eine klare Struktur und klare Schritte vereinfachen die Reaktion und verringern die Wahrscheinlichkeit menschlicher Fehler. # Wofür sollten Playbooks erstellt werden Playbooks sollten für Vorfallszenarien wie die folgenden erstellt werden: + **Erwartete Vorfälle** — Playbooks sollten für Vorfälle erstellt werden, die Sie erwarten. Dazu gehören Bedrohungen wie Denial of Service (DoS), Ransomware und die Kompromittierung von Anmeldeinformationen. + **Bekannte Sicherheitsfeststellungen oder Sicherheitswarnungen** — Playbooks sollten für Ihre bekannten Sicherheitsfeststellungen und -warnungen, wie z. B. Ergebnisse, erstellt werden. GuardDuty Möglicherweise erhalten Sie ein GuardDuty Ergebnis und denken: „Was nun?“ Um zu verhindern, dass ein GuardDuty Ergebnis falsch behandelt oder das Ergebnis ignoriert wird, sollten Sie für jedes potenzielle Ergebnis ein Playbook erstellen. GuardDuty [Einige Einzelheiten und Anleitungen zur Problembehebung finden Sie in der Dokumentation. GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html) Es ist erwähnenswert, dass dies standardmäßig nicht aktiviert GuardDuty ist und Kosten verursacht. Weitere Einzelheiten dazu GuardDuty finden Sie in Anhang A: Definitionen der Cloud-Funktionen -[Sichtbarkeit und Alarmierung](visibility-and-alerting.md). # Was sollte in Playbooks enthalten sein Playbooks sollten technische Schritte enthalten, die ein Sicherheitsanalyst ausführen muss, um einen potenziellen Sicherheitsvorfall angemessen zu untersuchen und darauf zu reagieren. Zu den Elementen, die in ein Playbook aufgenommen werden sollten, gehören: + **Überblick über das Playbook** — Auf welches Risiko- oder Vorfallszenario bezieht sich dieses Playbook? Was ist das Ziel des Playbooks? + **Voraussetzungen** — Welche Protokolle und Erkennungsmechanismen sind für dieses Vorfallszenario erforderlich? Wie lautet die erwartete Benachrichtigung? + **Informationen für Interessengruppen** — Wer ist beteiligt und wie lauten ihre Kontaktinformationen? Welche Aufgaben haben die einzelnen Stakeholder? + **Reaktionsschritte** — Welche taktischen Schritte sollten in allen Phasen der Reaktion auf Vorfälle ergriffen werden? Welche Abfragen sollte ein Analyst ausführen? Welcher Code sollte ausgeführt werden, um das gewünschte Ergebnis zu erzielen? + **Erkennen** — Wie wird der Vorfall erkannt? + **Analysieren** — Wie wird der Umfang der Auswirkungen bestimmt? + **Eindämmen** — Wie wird der Vorfall isoliert, um den Umfang einzuschränken? + **Ausrotten** — Wie wird die Bedrohung aus der Umwelt entfernt? + **Wiederherstellung** — Wie wird das betroffene System oder die betroffene Ressource wieder in Betrieb genommen? + **Erwartete Ergebnisse** — Was ist das erwartete Ergebnis des Playbooks, nachdem Abfragen und Code ausgeführt wurden? Um die Konsistenz der Informationen in jedem Playbook zu überprüfen, kann es hilfreich sein, eine Playbook-Vorlage zu erstellen, die Sie in Ihren anderen Sicherheits-Playbooks verwenden können. Einige der zuvor aufgeführten Elemente, wie z. B. Informationen zu Interessengruppen, können von mehreren Playbooks gemeinsam genutzt werden. Wenn das der Fall ist, können Sie eine zentrale Dokumentation für diese Informationen erstellen, im Playbook darauf verweisen und dann die expliziten Unterschiede im Playbook auflisten. Auf diese Weise müssen Sie nicht dieselben Informationen in all Ihren einzelnen Playbooks aktualisieren. Indem Sie eine Vorlage erstellen und allgemeine oder gemeinsam genutzte Informationen in Playbooks identifizieren, können Sie die Entwicklung von Playbooks vereinfachen und beschleunigen. Schließlich werden sich Ihre Playbooks wahrscheinlich im Laufe der Zeit weiterentwickeln. Sobald Sie sich vergewissert haben, dass die Schritte konsistent sind, bilden sich daraus die Voraussetzungen für die Automatisierung. # Beispiele für Playbooks Eine Reihe von Beispiel-Playbooks finden Sie in Anhang B unter. [Ressourcen aus dem Playbook](appendix-b-incident-response-resources.md#playbook-resources) Anhand der hier aufgeführten Beispiele können Sie erfahren, welche Playbooks Sie erstellen und was Sie in Ihre Playbooks aufnehmen sollten. Es ist jedoch wichtig, dass Sie Playbooks erstellen, die die Risiken berücksichtigen, die für Ihr Unternehmen am relevantesten sind. Sie müssen sicherstellen, dass die Schritte und Workflows in Ihren Playbooks Ihre Technologien und Prozesse beinhalten. # Führen Sie regelmäßige Simulationen durch Organizations wachsen und entwickeln sich im Laufe der Zeit, ebenso wie die Bedrohungslandschaft. Aus diesem Grund ist es wichtig, Ihre Fähigkeiten zur Reaktion auf Vorfälle kontinuierlich zu überprüfen. Simulationen sind eine Methode, mit der diese Bewertung durchgeführt werden kann. Simulationen verwenden reale Szenarien für Sicherheitsereignisse, die darauf ausgelegt sind, die Taktiken, Techniken und Verfahren eines Bedrohungsakteurs nachzuahmen (TTPs) und es einem Unternehmen zu ermöglichen, seine Fähigkeiten zur Reaktion auf Vorfälle zu testen und zu bewerten, indem es auf diese simulierten Cyberereignisse so reagiert, wie sie in der Realität auftreten könnten. Simulationen bieten eine Vielzahl von Vorteilen, darunter: + Validierung der Cybersicherheit und Stärkung des Vertrauens Ihres Vorfallreaktionsteams + Testen der Genauigkeit und Effizienz von Tools und Workflows + Optimierung der Kommunikations- und Eskalationsmethoden Ihres Vorfallreaktionsplans + Möglichkeit, auf weniger verbreitete Vektoren zu reagieren # Arten von Simulationen Es gibt drei Hauptarten von Simulationen: + **Übungen am Tisch — Beim Tabletop-Ansatz** für Simulationen handelt es sich ausschließlich um eine Diskussionsrunde, an der die verschiedenen Akteure der Incident-Response teilnehmen, um Rollen und Verantwortlichkeiten zu üben und etablierte Kommunikationsinstrumente und Playbooks zu nutzen. Die Durchführung von Übungen kann in der Regel an einem ganzen Tag an einem virtuellen Ort, einem physischen Ort oder einer Kombination aus beidem durchgeführt werden. Aufgrund des Diskussionscharakters stehen bei der Tabletop-Übung Prozesse, Menschen und Zusammenarbeit im Mittelpunkt. Technologie ist ein integraler Bestandteil der Diskussion; der tatsächliche Einsatz von Tools oder Skripten zur Reaktion auf Vorfälle ist jedoch in der Regel nicht Teil der Übung am Tisch. + **Purple Team-Übungen** *— Purple Team-Übungen erhöhen den Grad der Zusammenarbeit zwischen den Incident-Respondern (*Blue Team*) und den simulierten Bedrohungsakteuren (Red Team).* Das Blue Team besteht in der Regel aus Mitgliedern des Security Operations Center (SOC), kann aber auch andere Interessengruppen einbeziehen, die während eines tatsächlichen Cyberereignisses beteiligt wären. Das Red Team besteht in der Regel aus einem Penetrationstest-Team oder wichtigen Stakeholdern, die in offensiver Sicherheit geschult sind. Das Red Team arbeitet bei der Entwicklung eines Szenarios mit den Übungsleitern zusammen, damit das Szenario korrekt und durchführbar ist. Bei den Übungen von Purple Team liegt das Hauptaugenmerk auf den Erkennungsmechanismen, den Tools und den Standardarbeitsanweisungen (SOPs), die die Maßnahmen zur Reaktion auf Vorfälle unterstützen. + **Red Team-Übungen** — Während einer Red Team-Übung führt die Offensive (*Rotes Team*) eine Simulation durch, um ein bestimmtes Ziel oder eine Reihe von Zielen innerhalb eines vorher festgelegten Umfangs zu erreichen. Die Verteidiger (*blaues Team*) kennen nicht unbedingt den Umfang und die Dauer der Übung, sodass sie realistischer einschätzen können, wie sie auf einen tatsächlichen Vorfall reagieren würden. Da es sich bei den Übungen des Roten Teams um invasive Tests handeln kann, sollten Sie vorsichtig sein und Kontrollen durchführen, um sicherzustellen, dass die Übung Ihrer Umgebung nicht tatsächlich schadet. **Anmerkung** AWS verlangt von Kunden, dass sie die auf der [Penetrationstest-Website verfügbaren Richtlinien für Penetrationstests](https://aws.amazon.com/security/penetration-testing/) lesen, bevor sie Purple Team- oder Red Team-Übungen durchführen. In Tabelle 1 sind einige wichtige Unterschiede zwischen diesen Simulationstypen zusammengefasst. Es ist wichtig zu beachten, dass die Definitionen im Allgemeinen als lose Definitionen betrachtet werden und an die Bedürfnisse Ihres Unternehmens angepasst werden können. *Tabelle 1 — Arten von Simulationen* | | Übung am Tisch | Team-Übung in Violett | Rote Teamübung | | --- | --- | --- | --- | | Zusammenfassung | Übungen auf Papier, die sich auf ein bestimmtes Sicherheitsvorfallszenario konzentrieren. Diese können entweder anspruchsvoller oder technischer Natur sein und werden durch eine Reihe von Papiereinschüssen angetrieben. | Ein realistischeres Angebot im Vergleich zu Tischübungen. Bei den Purple Team-Übungen arbeiten die Moderatoren mit den Teilnehmern zusammen, um das Übungsengagement zu erhöhen und bei Bedarf Schulungen anzubieten. | Im Allgemeinen ein fortgeschritteneres Simulationsangebot. In der Regel besteht ein hohes Maß an Verdecktheit, sodass die Teilnehmer möglicherweise nicht alle Einzelheiten der Übung kennen. | | Erforderliche Ressourcen | Begrenzte technische Ressourcen erforderlich | Verschiedene Interessengruppen erforderlich und ein hohes Maß an technischen Ressourcen erforderlich | Verschiedene Interessengruppen waren erforderlich und es wurden umfangreiche technische Ressourcen benötigt | | Komplexität | Niedrig | Medium | Hoch | Erwägen Sie, in regelmäßigen Abständen Cybersimulationen durchzuführen. Jeder Übungstyp kann den Teilnehmern und der Organisation als Ganzes einzigartige Vorteile bieten. Sie können sich also dafür entscheiden, mit weniger komplexen Simulationstypen (wie Tischübungen) zu beginnen und zu komplexeren Simulationstypen (Red Team-Übungen) überzugehen. Wählen Sie auf der Grundlage Ihres Sicherheitsreifegrads, Ihrer Ressourcen und der gewünschten Ergebnisse einen Simulationstyp aus. Einige Kunden entscheiden sich aufgrund der Komplexität und der Kosten möglicherweise nicht für die Durchführung von Red Team-Übungen. # Lebenszyklus des Trainings Unabhängig von der Art der Simulation, die Sie wählen, folgen Simulationen im Allgemeinen diesen Schritten: 1. **Definieren Sie die wichtigsten Übungselemente** — Definieren Sie das Simulationsszenario und die Ziele der Simulation. Beide sollten von der Führungsebene akzeptiert werden. 1. **Identifizieren Sie die wichtigsten Interessengruppen** — Für eine Übung sind mindestens Übungsleiter und Teilnehmer erforderlich. Je nach Szenario können gegebenenfalls weitere Stakeholder einbezogen werden – etwa aus der Rechts- oder Kommunikationsabteilung oder aus der Geschäftsleitung. 1. **Erstellen und testen Sie das Szenario** — Das Szenario muss möglicherweise während der Erstellung neu definiert werden, wenn bestimmte Elemente nicht durchführbar sind. Als Ergebnis dieser Phase wird ein fertiges Szenario erwartet. 1. **Erleichterung der Simulation** — Die Art der Simulation bestimmt die verwendete Moderation (papiergestütztes Szenario im Vergleich zu einem hochtechnischen, simulierten Szenario). Die Übungsleiter sollten ihre Taktiken an den Übungsobjekten ausrichten und alle Übungsteilnehmer nach Möglichkeit einbeziehen, um den größtmöglichen Nutzen zu erzielen. 1. **Entwickeln Sie den After Action Report (AAR)** — Identifizieren Sie Bereiche, die gut gelaufen sind, Bereiche, die verbessert werden können, und mögliche Lücken. Der AAR sollte die Effektivität der Simulation sowie die Reaktion des Teams auf das simulierte Ereignis messen, damit der Fortschritt im Laufe der Zeit mit zukünftigen Simulationen verfolgt werden kann.