Skip to content

Latest commit

 

History

History
49 lines (36 loc) · 12.1 KB

de.Playbook_Development_Guide.md

File metadata and controls

49 lines (36 loc) · 12.1 KB

Playbook-Entwicklungshandbuch

Dieses Dokument wird nur zu Informationszwecken bereitgestellt. Es stellt die aktuellen Produktangebote und -praktiken von Amazon Web Services (AWS) zum Ausstellungsdatum dieses Dokuments dar, die sich ohne vorherige Ankündigung ändern können. Die Kunden sind dafür verantwortlich, ihre eigene unabhängige Bewertung der Informationen in diesem Dokument und jede Nutzung von AWS-Produkten oder -Dienstleistungen durchzuführen, von denen jede „wie besehen“ ohne ausdrückliche oder stillschweigende Gewährleistung jeglicher Art bereitgestellt wird. Dieses Dokument enthält keine Garantien, Zusicherungen, vertraglichen Verpflichtungen, Bedingungen oder Zusicherungen von AWS, seinen verbundenen Unternehmen, Lieferanten oder Lizenzgebern. Die Verantwortlichkeiten und Verbindlichkeiten von AWS gegenüber seinen Kunden werden durch AWS-Vereinbarungen kontrolliert, und dieses Dokument ist weder Teil noch ändert es eine Vereinbarung zwischen AWS und seinen Kunden.

© 2021 Amazon Web Services, Inc. oder seine verbundenen Unternehmen. Alle Rechte vorbehalten. Dieses Werk ist unter einer Creative Commons Attribution 4.0 International License lizenziert.

Dieser AWS-Inhalt wird gemäß den Bedingungen der AWS-Kundenvereinbarung bereitgestellt, die unter http://aws.amazon.com/agreement verfügbar ist, oder einer anderen schriftlichen Vereinbarung zwischen dem Kunden und entweder Amazon Web Services, Inc. oder Amazon Web Services EMEA SARL oder beiden.

Playbook als Code:

  • Die Playbooks sollten im Markdown-Format in einem Git-Repository gespeichert werden.
  • Erstellen Sie eine druckfreundliche, eigenständige Version jedes Playbooks, um sie mit Personen zu teilen, die keinen Zugriff auf das Git-Repository haben.
  • Es wird empfohlen, dass Mitglieder des Incident-Response-Teams das Git-Projekt verzweigen und in ihre lokale Umgebung klonen dürfen, wie PC, VDI oder Laptop.
  • Wenn Verbesserungen an der Zweigstelle vorgenommen werden, reichen Sie diese zur Überprüfung, Genehmigung und Zusammenführung mit dem Master ein.
  • Das Git-Projekt wird Dokumentation und Code hosten.
  • Erwägen Sie, die CD/CI-Pipeline zu verwenden, um die Verwaltung und Bereitstellung von Playbooks zu erleichtern.

Playbook-Struktur:

  1. Bedrohlich: Beschreibt die Bedrohung, die vom Playbook behoben wurde
  2. Endgame: Beschreibt die gewünschten Ergebnisse für das Playbook basierend auf der Sicherheitsperspektive des _ [*AWS Cloud Adoption Framework (CAF) *] (https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf)_ und branchenakzeptierten Sicherheitsmustern wie Schwachstellenbewertung und Folgenanalyse.
  3. Antwortschritte: Bietet Schritt-für-Schritt-Verfahren in chronologischer Reihenfolge, um auf das Ereignis basierend auf * [NIST 800-61r2 - Computersicherheits-Incident-Response Guide] (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf) * zu reagieren. Beziehen Sie sich auf Abbildung A.
  4. Simulation [CODE]: Bietet Schritt-für-Schritt-Verfahren zum Generieren der Indikatoren, die erforderlich sind, um die Warnung auszulösen, die die Antwort auslöst.
  5. Einstufung, Handhabung und Erkennung: Kategorisiert das Playbook nach [MITRE ATT&CK Unternehmenstaktik] (https://attack.mitre.org/tactics/enterprise/), zählt die zum Ausführen des Playbooks erforderlichen Tools auf, zählt die Indikatoren (auch bekannt als Ergebnisse) auf, die für die Erkennung der Warnung verwendet werden Quellen, die erforderlich sind, um Indikatoren zu generieren und die Analyse zu erleichtern, sowie die beteiligten Teams
  6. **Prozess zur Handhabung von Vorfällen **: Präskriptive Anleitungen für jede Disziplin der Antwort. Diese befinden sich nicht in chronologischer Ausführungsreihenfolge, sie dienen als Referenz, während sie 3 durchlaufen. Antwortschritte. Während des gesamten Antwortprozesses ist es wichtig, alle durchgeführten Aktionen zu dokumentieren und alle gesammelten Beweise in einem bekannten Repository mit ordnungsgemäßen Ansprüchen basierend auf dem Reaktionsteam RACI für Vorfälle zu zentralisieren. Es ist auch wichtig, während der Reaktion geeignete Kommunikationskanäle mit zentralisierten Orchestrierungsfunktionen zu haben, die es den Mitgliedern des Incident-Response-Teams ermöglichen, sich auf ihre Aufgaben in ihren Fachgebieten zu konzentrieren. Die zentralisierte Orchestrierungsfunktion sorgt dafür, dass die ordnungsgemäße Kommunikation fließt und sichergestellt wird, dass alle erforderlichen Aktivitäten mit geschäftlichem Wissen und Genehmigung durchgeführt werden.
  7. Analyse - Warnvalidierung: Der Inhalt der Benachrichtigung für die Warnung muss direkt mit den quellengenerierenden Indikatoren (dh „Grundwahrheit „) überprüft werden. Dies ist aus mindestens zwei Gründen erforderlich. Erstens werden die ursprünglichen Indikatoren im Allgemeinen transformiert, während sie durch verschiedene Systeme fließen, bis sie das Vorfallreaktionsteam erreichen, was zu einer unbeabsichtigten Änderung kritischer Vorfalldaten führen könnte. Zweitens könnte die Benachrichtigung aufgrund eines Computerkonfigurationsfehlers oder eines menschlichen Konfigurationsfehlers generiert worden sein.
  8. Analyse - Alarm-Triage: Durchsuchen Sie basierend auf den von der Warnung dargestellten Indikatoren die Protokolle, die verwendet wurden, um sie zu generieren, Gebäudekontext, um die Analyse zu erleichtern.
  9. Analyse - Bereich: Suchen Sie Nachweise in den verfügbaren und warnbezogenen Protokollquellen, um die Aktivität zu ermitteln, die der Akteur während des Lebenszyklus des Ereignisses durchgeführt hat.
  10. Analyse - Auswirkung: Bestimmen Sie, welche Workloads und Komponenten von der Aktivität des Akteurs und ihrem Umfang beeinflusst wurden. Formulieren Sie eine Hypothese, um mit dem umfassenderen Reaktionsteam für Vorfälle zu diskutieren, um die Auswirkungen auf das Unternehmen zu ermitteln und die nächsten Schritte zu priorisieren.
  11. **Eindämmung: ** Bestimmen Sie die Eindämmungsstrategie für den Vorfall während des Fortschritts oder des Endes der Analysephase. Die geeignete Strategie hängt von Umfang und Wirkung ab und wird von Workload-Eigentümern genehmigt. Eindämmungsaktivitäten sollten an der Bedrohungsmodellierung der betroffenen Workload und dem tatsächlichen Kontext während der Reaktion auf Vorfälle ausgerichtet sein. Es sollten einige verschiedene oder ergänzende Eindämmungsoptionen verfügbar sein, um mögliche Kollateraleffekte wie Ausfallzeiten, Datenvernichtung infolge von Eindämmungsmaßnahmen zu minimieren. In dieser Phase muss die gebührende Sorgfalt bei der Beweiserhebung eingehalten werden. Obwohl die forensische Datenaggregation während der Analyse begann, z. B. CloudTrail-Protokolle, VPC Flow-Protokolle und GuardDuty-Protokolle, ist dies der am besten geeignete Zeitpunkt für Snapshots und Backups, Lambda die Dienste neu konfiguriert werden, um weitere Aktivitäten zu verhindern, z. B. entfernung.
  12. Tilgung & Wiederherstellung: Vom Widersacher bereitgestellte Ressourcen werden deaktiviert oder vollständig entfernt, und die Schwachstellen und Konfigurationsprobleme aller betroffenen Ressourcen werden identifiziert. Nach der Genehmigung des Workload-Besitzers werden alle Ressourcen ordnungsgemäß neu konfiguriert und Sicherheitsupdates werden angewendet, um die Erfolgswahrscheinlichkeit mit denselben oder ähnlichen Exploits zu verringern. Die Neubewertung der Sicherheitslage der Arbeitsbelastung ist abgeschlossen. Wenn nach Konfigurationsänderungen und Sicherheitsupdates angewendet wurden, sollten Empfehlungen für mittel- und langfristige Architekturänderungen ausgearbeitet und zur Bewertung durch die verantwortlichen und verantwortlichen Teams eingereicht werden, wenn die Sicherheitslage der Arbeitsbelastung immer noch ein inakzeptables Risiko für das Unternehmen darstellt.
  13. Aktivität nach Vorfall: Nachdem alle vorherigen Phasen abgeschlossen sind, wird eine eingehende Analyse des Vorfalls in Form von „Lektionen gelernt“ -Sitzungen durchgeführt. Der Zeitplan für die Reaktion auf Vorfälle wird veröffentlicht und diskutiert, wobei er sich auf die Änderungen konzentriert, die vorgenommen werden müssen, um die Bereitschaft für den nächsten Sicherheitsvorfall zu verbessern. In dieser Phase liegt der Fokus des Incident-Response-Teams darauf, Richtlinien-, Präventions-, Erkennungs- und Reaktionskontrollen (siehe Abbildung B) nicht nur für die betroffene Arbeitsbelastung, sondern auch für alle Workloads des Unternehmens zu verbessern.

! [Bild] (/images/nist_life_cycle.png)

Abbildung A - Lebenszyklus der Reaktion auf Incident Response

! [Bild] (/images/image-caf-sec.png)

Abbildung B - Sicherheitsperspektive des AWS Cloud Adoption Framework

Entwicklungsprozess:

  1. Wählen Sie die Bedrohung aus, die das Playbook ansprechen soll, und beschreiben Sie sie im 1. Bedrohungsabschnitt. Geben Sie so viele Referenzen wie nötig an, die dem Playbook-Reader helfen würden, es zu verstehen.
  2. Überprüfen Sie den Abschnitt „Playbook-Vorlage“ ``2. Beenden Sie den Spielabschnitt ```und nehmen Sie Änderungen vor oder behalten Sie sie wie es ist. Diese basieren auf AWS-Sicherheits- und Branchenmustern wie der [Sicherheitsperspektive des CAF] (https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf), [Sicherheitssäule des AWS Well-Architected Framework] (https://d1.awsstatic.com/whitepapers/architecture/AWS-Security-Pillar.pdf), [Amazon Web Services: Überblick über Sicherheitsprozesse] (https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf), [Leitfaden zur Reaktion auf AWS Security Incident Response] (https://d1.awsstatic.com/whitepapers/aws_security_incident_response.pdf) und [NIST Special Publication 800-61r2 Computer Security Incident Handling Guide] ( https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf).
  3. Füllen Sie den Abschnitt ```5 aus. Klassifizierung, Handhabung und Erkennung von Vorfällen“ mit den entsprechenden Informationen. Sie können später zu diesem Abschnitt zurückkehren, wenn Sie während des Aufbaus anderer Abschnitte des Playbooks neue Indikatoren, andere Tools, die Sie verwenden möchten, usw. aufdecken.
  4. Definieren Sie Schritte, um die Indikatoren für die Bedrohung auszulösen. Dokumentieren Sie den Prozess, die AWS-Ressourcen, den IAM-Prinzipal, die erforderlichen Richtlinien und den erforderlichen Code, wie AWS CLI-Befehle, AWS SDK-basierter Code, vorzugsweise in ein Shell-Skript oder ein unterstütztes Sprachcodeprogramm eingeschlossen. Fügen Sie Screenshots hinzu, die die verschiedenen Protokolle veranschaulichen, die von der Simulationsaktivität mit einem Analysetool wie CloudWatch Insights oder Athena generiert werden.
  5. Entwickeln Sie Antwortschritte unter dem Abschnitt 3. Abschnitt Antwort, der die NIST-IR-Lebenszyklusphase hervorhebt, zu der jeder Schritt gehört. Die Schritte sollten in der chronologischen Reihenfolge aufgeführt werden, die am Bedrohungsmodell der betroffenen Arbeitslast ausgerichtet ist. Machen Sie im Playbook deutlich, dass die chronologische Reihenfolge nicht unveränderlich ist und je nach Kontext des Ereignisses geändert werden kann. Es wird empfohlen, dass Abweichungen vom festgelegten Ausführungsauftrag einen zuvor genehmigten Überprüfungsprozess durchlaufen müssen, um das Risiko von Maßnahmen zu minimieren, die die betroffene Arbeitsbelastung weiter schädigen könnten.
  6. Erstellen Sie AWS CLI-Befehle und Athena-Abfragen, die jede Phase des NIST-IR-Lebenszyklus im Abschnitt 6 unterstützen. Prozess der Handhabung von Vorfällen . Die Reihe von Abfragen und Befehlen sollte die Anforderungen jeder Phase aus einer allgemeinen Perspektive erfüllen und ihre Ausgabe in Form von Screenshots dokumentiert werden. Die Befehle werden für das betroffene Konto unter Verwendung einer Rolle ausgeführt, die den Ansprüchen des Incident Responders ähnelt oder gleich ist. Die Abfragen werden für die zugehörigen Log-Repositorys mit Athena bis zum Minimum CloudTrail- und VPC Flow-Protokolle ausgeführt. Wenn die zu analysierenden Protokolle nicht über Athena verfügbar sind, verwenden Sie das verfügbare Analysetool, z. B. eine SIEM- oder Big-Data-Lösung.