Reagieren auf einen Sicherheitsvorfall

Die Anleitung in diesem Artikel richtet sich an Unternehmensbesitzer, Organisationsbesitzer, Sicherheitsmanager und Sicherheitsteams. Sie müssen jedoch über die Rolle des Unternehmensbesitzers verfügen, um mehrere der in diesem Artikel beschriebenen Aktionen auszuführen. Einige Schritte erfordern möglicherweise die Koordination mit Organisationsbesitzern oder Repositoryadministratoren.

Introduction

In diesem Leitfaden erfahren Sie, wie Sie auf einen Sicherheitsvorfall reagieren, die GitHub Oberflächen, die Sie verwenden können, um eine Bedrohung zu überprüfen und zu untersuchen, und die Tools, die Sie verwenden können, um ihn einzudämten und zu beheben.

Voraussetzungen

Im Idealfall haben Sie die Sichtbarkeit von Überwachungsprotokollstreaming und Quell-IP-Adressen bereits für das Unternehmen aktiviert (Streamen der Daten in ein SIEM-System (Security Information and Event Management) und Sie haben Zugriff auf diese Daten. Siehe Streaming des Überwachungsprotokolls für Ihre Organisation.

Während der gesamten Antwort

Stellen Sie beim Durchlaufen Ihrer Antwort folgendes sicher:

• Bewahren Sie Nachweise auf: Erstellen Sie Screenshots verdächtiger Aktivitäten, exportieren Sie Protokolle oder Abfrageergebnisse, und speichern Sie Kopien betroffener Dateien oder Code, bevor Sie die Bereinigung durchführen.
• Bewahren Sie einen Datensatz auf: Dokumentieren Sie Ihre Ergebnisse (z. B. Uhrzeiten, Datumsangaben, Indikatoren für Kompromittierung (IoCs), Repositorys, die betroffen sind), und notieren Sie jede entscheidung, die Sie treffen.
• Kommunikation: Benachrichtigen Sie relevante Projektbeteiligte (z. B. Sicherheitsleiter und Engineering-Manager sowie Rechts- und Datenschutzteams, wenn vertrauliche Daten gefährdet sind), und halten Sie sie auf dem neuesten Stand.

Schritt 1: Bewerten des Signals und Schnelles Überprüfen des Signals

Ziel ist es, schnell zu bestimmen, ob das angezeigte Signal wahrscheinlich eine echte und aktive Bedrohung ist.

1. Identifizieren

Versuchen Sie, die Art des angezeigten Signals zu identifizieren. Zeigt z. B. das Signal Hinweise auf:

• Kompromittierung von Anmeldeinformationen (Warnung für einen geheimen Schlüssel, Berichte über Anmeldeinformationen, die auf einer externen Website gefunden wurden)
• Unbefugter Zugriff oder Kontokompromittierung (Berichte verdächtiger Anmeldungen, unbekannter Commits oder Änderungen)
• Datenexfiltration (Berichte verdächtiger Dateiänderungen oder Ergänzungen, unerwartete Workflowausführungen, ungewöhnliche API-Aktivitäten, unbekannte Repositoryerstellungen oder unerwartete Sichtbarkeitsänderungen des Repositorys)
• Einfügung bösartiger Code (Berichte verdächtiger Codeänderungen, unerwartete Workflowausführungen, hinzugefügte neue Dateien)
• Supply Chain-Angriff (Berichte verdächtiger Paketversionen, Warnungen für anfällige Abhängigkeiten)

Hilfe zum Identifizieren dieser Bedrohungssignale in Ihrer Organisation oder Ihrem Unternehmen finden Sie unter Allgemeine Untersuchungsbereiche für Sicherheitsvorfälle.

Es wird empfohlen, dass Sie in den früheren Phasen Ihrer Untersuchung nicht zu viel Zeit für eine umfassende Untersuchung aufwenden, da das anfängliche Ziel darin besteht, das Bedrohungssignal zu identifizieren , um es zu überprüfen und Ihre Antwort zu strategieren.

2. Überprüfen

Überprüfen Sie auf Nachweise, um zu überprüfen, ob die potenzielle Bedrohung real ist und ob sie derzeit aktiv ist.

Die folgenden GitHub Tools und Oberflächen können Ihnen helfen.

Werkzeug/Oberfläche	Purpose
Sicherheitsübersicht und Sicherheitswarnungen	Überprüfen von Sicherheitswarnungen in Ihrer Organisation oder Ihrem Unternehmen
Überwachungsprotokolle	Suchen Sie nach Ereignissen im Zusammenhang mit dem signal, das Sie untersuchen, z. B. Tokenerstellung, Berechtigungsänderungen oder Sichtbarkeitsänderungen des Repositorys
Aktivitätsansicht	Anzeigen einer Zeitachse mit Pushes, Commits und Verzweigungsaktivitäten für ein bestimmtes Repository
[

          GitHub Codesuche](/code-security/reference/security-incident-response/investigation-tools#github-code-search) | Suchen nach bekannten Kompromittierungsindikatoren, z. B. bestimmten Dateinamen oder Codemustern, über Repositorys hinweg |

| Abhängigkeitsdiagramm | Überprüfen, ob Repositorys von einer bestimmten Paket- oder Paketversion abhängen | | Workflowausführung und -protokolle | Überprüfen des Workflowausführungsverlaufs und Überprüfen der Protokollausgabe für verdächtige Aktivitäten |

Ausführliche Informationen zu den einzelnen Tools finden Sie unter Untersuchungstools für Sicherheitsvorfälle.

Die Validierungsphase kann schnell sein:

• Ziel ist es, genügend Beweise zu sammeln, um festzustellen, ob das Signal wahrscheinlich eine echte und aktive Bedrohung ist.
• Wenn Sie das Signal nicht schnell als falsch positives Ergebnis ausschließen können, gehen Sie davon aus, dass es wirklich ist.
• Eine umfassende Untersuchung kann später durchgeführt werden.

3. Entscheiden

Anhand der gesammelten Beweise bestimmen Sie drei Dinge:

1.        **Ist dies eine echte Bedrohung?** Wenn Sie das Signal nicht schnell und sicher als falsch positives Signal ausschließen können, behandeln Sie es als real, und fahren Sie mit der Eindämmung fort.
   

2.        **Ist die Bedrohung noch aktiv?** Wenn der Angreifer weiterhin Zugriff hat oder Aktivitäten aktiv sind, priorisieren Sie zuerst sofortige Eindämmungsaktionen. Wenn der Kompromiss historisch erscheint, müssen Sie ihre Antwort dennoch untersuchen und beheben, aber Möglicherweise haben Sie mehr Zeit, um Ihre Antwort zu planen.
   

3.        **Was ist der potenzielle Umfang?** Überlegen Sie, wie weit die Kompromittierung erreicht werden kann – eine einzelne Anmeldeinformation, ein Repository, eine Organisation oder das gesamte Unternehmen. Auf diese Weise können Sie Ihre Antwort entsprechend skalieren.
   

Falls zweifelsfrei, behandeln Sie die Bedrohung als real, und skalieren Sie Ihre Antwort als Nachweise.

Schritt 2: Die Bedrohung enthalten

Im nächsten Schritt wird davon ausgegangen, dass Sie mit einer echten und aktiven Bedrohung umgehen. Das Ziel besteht nun darin, das laufende Risiko sofort zu reduzieren , indem Sie bisher wissen, was Sie wissen.

Es gibt mehrere Eindämmungsaktionen, die Sie ausführen können, um den Zugriff und die Funktionen des Angreifers einzuschränken.

Widerrufen kompromittierter Anmeldeinformationen

Bei verfügbar gemachten oder ausgenutzten Anmeldeinformationen besteht die sofortige Aktion darin, die betroffenen Anmeldeinformationen zu widerrufen, um weiteren Missbrauch zu verhindern.

• Sperr- und Eindämmungsoptionen

  Es gibt zusätzliche Optionen zum Blockieren des Zugriffs auf Anmeldeinformationen. Eine vollständige Liste nach Anmeldeinformationstyp finden Sie unter Referenz zu GitHub-Anmeldeinformationstypen.

• Notfallaktionen (schwerwiegender Vorfall)

  Unternehmensbesitzer GitHub Enterprise Cloud können massenweise Notfallaktionen ergreifen, um den Zugriff im gesamten Unternehmen zu sperren. Für Unternehmen mit Enterprise Managed Users, umfasst dies das Löschen aller Benutzertoken und Schlüssel. Hierbei handelt es sich um aktionen mit hoher Wirkung, die Automatisierungen unterbrechen und für wichtige Vorfälle reserviert werden sollten. Siehe Reagieren auf Sicherheitsvorfälle in Ihrem Unternehmen.

Zugriff einschränken

Um den Zugriff auf das Unternehmen, die Organisation oder das Repository einzuschränken, gibt es mehrere sofortige Aktionen, die Sie ausführen können.

• Konfigurieren von IP-Zulassungslisten

  Verhindern, dass unbekannte oder verdächtige IP-Adressen auf die Organisation oder das Unternehmen zugreifen. Siehe Einschränken des Netzwerkdatenverkehrs in deinem Unternehmen mit einer Liste zugelassener IP-Adressen (Unternehmensadministratoren) und Verwaltung erlaubter IP-Adressen für deine Organisation (Organisationsbesitzer).

• Entfernen kompromittierter oder verdächtiger Benutzer

  Entfernen Sie den Benutzer, oder sperren Sie das Konto. Siehe Entfernen eines Mitglieds aus deiner Organisation (Organisationsbesitzer).

• Ändern der Sichtbarkeit des Repositorys in privat

  Ändern Sie die Sichtbarkeit des betroffenen Repositorys auf "Privat", und beschränken Sie die Fähigkeit anderer Personen, weitere Änderungen vorzunehmen. Wenn beispielsweise vertraulicher Code in einem öffentlichen Repository verfügbar gemacht wurde, das zur Organisation gehört, oder wenn ein böswilliger Akteur die Sichtbarkeitseinstellung des Repositorys von privat in öffentlich geändert hat, können Sie die Sichtbarkeit des Repositorys ändern. Siehe Sichtbarkeit eines Repositorys festlegen (Repositoryadministratoren und Organisationsbesitzer) und Einschränken von Änderungen der Sichtbarkeit von Repositorys in deiner Organisation (Organisationsbesitzer).

• Notfallaktionen (schwerwiegender Vorfall)

  Unternehmensbesitzer GitHub Enterprise Cloud können massenweise Notfallaktionen ergreifen, um den Zugriff im gesamten Unternehmen zu sperren. Dazu gehört das Sperren von SSO , um den Zugriff aller Nichtbesitzer zu blockieren und alle Benutzer-SSO-Autorisierungen in allen Organisationen zu widerrufen. Hierbei handelt es sich um aktionen mit hoher Wirkung, die Automatisierungen unterbrechen und für wichtige Vorfälle reserviert werden sollten. Siehe Reagieren auf Sicherheitsvorfälle in Ihrem Unternehmen.

Deaktivieren von schädlichen Artefakten und Aktivitäten

• Beenden bösartiger Workflows

  Wenn Sie vermuten, dass ein GitHub Actions Workflow oder Runner als Teil eines aktiven Angriffs verwendet wird, können Sie die folgenden Aktionen ausführen:

  • Der laufende Workflow wird für ein betroffenes Repository abgebrochen. Siehe Einen Workflow-Lauf abbrechen.
  • Deaktivieren Sie GitHub Actions für ein betroffenes Repository in einer Organisation oder für eine bestimmte Organisation. Siehe Deaktivieren oder Einschränken von GitHub Actions für Ihre Organisation (Organisationsbesitzer) und Erzwingen von Richtlinien für GitHub Actions in Ihrem Unternehmen (Unternehmensadministratoren).
  • Entfernen Sie selbst gehostete Läufer. Siehe Selbst-gehostete Runner entfernen.

• Deaktivieren von Webhooks

  Wenn Sie vermuten, dass ein kompromittiertes Repository oder ein Organisationswebhook als Livedatenexfiltrationskanal verwendet wird, können Sie ihn deaktivieren. Siehe Deaktivieren von Webhooks.

• Löschen bösartiger Verzweigungen

  Wenn Sie Verzweigungen identifiziert haben, die schädlichen Code oder Workflows enthalten, löschen Sie sie sofort, um die Ausführung zu verhindern. Siehe Erstellen und Löschen von Branches in deinem Repository.

Schritt 3: Vollständige Untersuchung

Nach sofortigem Eindämmung besteht das Ziel nun darin, den vollständigen Umfang und die Auswirkungen des Vorfalls zu verstehen, alle IoCs und Persistenzmechanismen zu identifizieren und die Beweise zu sammeln, die Sie benötigen, um die Bedrohung zu enthalten und vollständig zu beheben.

1. Basierend auf den bisher gesammelten Signalen und den bisher gesammelten Erkenntnissen entwickeln Sie eine Arbeitshypothese darüber, was passiert ist, und entscheiden Sie, welche zusätzlichen Beweise Sie benötigen, um diese Hypothese zu beweisen oder zu widerlegen.

2. Berücksichtigen Sie die verschiedenen Untersuchungsbereiche , die in Allgemeine Untersuchungsbereiche für Sicherheitsvorfälle beschrieben sind, um Ihre Untersuchung zu unterstützen.

   Beschränken Sie Ihre Untersuchung nicht auf eine einzelne Anfragezeile. Viele Angriffe verwenden eine Kombination von Techniken, z. B. die Installation bösartiger Pakete in Kombination mit der Ausnutzung von Anmeldeinformationen, Workflowdateieinfügungen und Datenexfiltration. Stellen Sie sicher, dass Sie alle potenziellen Angriffsvektoren untersuchen.

3.        **Dokumentieren Sie** bisher alle bekannten IoCs, die auf allen Oberflächen nach GitHubSpuren suchen.
   

4.        **Inventarisieren Sie** alle betroffenen Workflows, Repositorys und Organisationen, um den Umfang des Vorfalls systematisch zu erfassen.
   

   • Fügen Sie den Repositorynamen, den Betroffenen (Code, geheime Schlüssel, Workflows) und die Zeitachse des Kompromittierungs ein.
   • Erstellen Sie eine Liste aller betroffenen Konten und Anmeldeinformationen. Beachten Sie, welche Token, SSH-Schlüssel oder andere Anmeldeinformationen möglicherweise verfügbar gemacht oder missbraucht wurden.

5.        **Überprüfen Sie** Ihre Arbeitstheorie anhand der Beweise.
   

   • Überprüfen Sie die gesammelten Nachweise. Unterstützt sie Ihre anfängliche Hypothese?
   • Erwägen Sie alternative Erklärungen. Könnte es eine andere Ursache für die Aktivität geben, die Sie beobachtet haben?
   • Wenn Ihre Hypothese widerlegt ist, bilden Sie eine neue Hypothese, die auf dem Nachweis basiert, und wiederholen Sie die Untersuchungsschritte nach Bedarf.

6.        **Kreisen Sie zurück, um einzudämmen** , wenn Sie neue IoCs oder Nachweise für laufende Aktivitäten entdecken, die sofortige Maßnahmen erfordern.
   

Sobald Sie ein hohes Vertrauen in Ihr Verständnis für das Geschehen und die Ursache haben, dokumentieren Sie Ihre Ergebnisse, und fahren Sie mit der Behebung fort.

Schritt 4: Beheben

Das Ziel besteht nun darin, alle Spuren von Kompromittierungen zu entfernen, die Ursache zu beheben und Systeme in einem sicheren Zustand wiederherzustellen. Abhilfemaßnahmen hängen von der Ausbeutung ab, die Sie konfrontiert haben, aber einige bewährte Methoden sind wie folgt.

Drehen von Token und geheimen Schlüsseln

Selbst wenn Sie nicht sicher sind, dass anmeldeinformationen kompromittiert wurden, drehen Sie sie, wenn es eine Möglichkeit der Gefährdung gibt.

• Generieren Sie neue Token und geheime Schlüssel, um alle widerrufenen oder verfügbar gemachten Zu ersetzen.
• Drehen Sie geheime Schlüssel, die auf GitHub Repository-, Umgebungs- und Organisationsebene gespeichert sind.
• Aktualisieren Sie alle Anmeldeinformationen in externen Systemen, auf die möglicherweise mithilfe kompromittierter Token zugegriffen wurde.
• Erwägen Sie, Tokenablaufrichtlinien zu aktivieren, um eine regelmäßige Drehung in Zukunft zu fördern. Siehe Erzwingen von Richtlinien für persönliche Zugriffstoken in deinem Unternehmen.

Überwachung auf Persistenzmechanismen

Sie müssen nach Persistenzmechanismen suchen, die der Angreifer möglicherweise eingerichtet hat, um den Zugriff auch nach Ihren anfänglichen Eindämmungsaktionen aufrechtzuerhalten.

Dies umfasst, aber nicht beschränkt auf die Überprüfung auf Dinge wie:

• Verdächtige oder unbekannte Workflowdateien, die möglicherweise hinzugefügt oder geändert wurden.
• Neue Webhooks, die auf unbekannte Domänen zeigen.
• Neue selbst gehostete Läufer.
• Änderungen an selbst gehosteten Läufern.
• Neu installierte GitHub Apps oder OAuth app Autorisierungen.
• Neue Bereitstellungsschlüssel, die Repositorys hinzugefügt wurden.
• Neue Binärdateien oder ausführbare Dateien.

Überwachen und Erneutes Installieren von Abhängigkeiten

Kompromittierte Abhängigkeiten können als Angriffsvektor dienen. Stellen Sie sicher, dass Sie eine vollständige Überwachung Ihrer Abhängigkeiten durchführen und sie aus vertrauenswürdigen Quellen erneut installieren.

• Überprüfen Sie Dependabot Warnungen für anfällige Abhängigkeiten und, sofern verfügbar, Dependabot malware alerts für bösartige Pakete. (Dependabot malware alerts sind derzeit für das npm-Ökosystem verfügbar.) Um weitere Schadsoftware-Empfehlungen zu untersuchen, suchen type:malware Sie im GitHub Advisory Database Abhängigkeitsdiagramm nach Übereinstimmungen und überwachen Sie es.
• Heften Sie Abhängigkeiten an bekannte Versionen an, oder übernehmen Sie SHAs, und installieren Sie es aus der Paketregistrierung erneut.

Überprüfen der Wartung

Vergewissern Sie sich, dass Ihre Korrekturmaßnahmen erfolgreich waren.

• Überprüfen Sie code scanning Warnungen, um zu bestätigen, dass Coderisiken behoben wurden, und es wurden keine neuen Sicherheitsrisiken eingeführt.
• Überprüfen Sie secret scanning Warnungen, um zu bestätigen, dass keine geheimen Schlüssel in repositorys verfügbar bleiben und dass alle Warnungen behoben wurden.
• Überprüfen und überwachen Sie weiterhin Überwachungsprotokolle und andere relevante Oberflächen in den kommenden Tagen und Wochen nach dem Vorfall.

Schritt 5. Dokument

Eine gründliche Dokumentation ist für die verbleibenden Phasen und für zukünftige Referenzen unerlässlich.

• Zeichnen Sie alle IoCs auf, die während der Untersuchung ermittelt wurden.
• Dokumentieren Sie alle ausgeführten Korrekturschritte, einschließlich Zeitstempel und der Personen, die jede Aktion ausgeführt haben.
• Verwalten Sie Inventare betroffener Repositorys, Workflows und Konten.
• Dokumentieren Sie getroffene Entscheidungen und die zugrunde stehenden Gründe.
• Beachten Sie alle Compliance-, rechtlichen oder Datenschutzauswirkungen. Überlegen Sie, ob dieser Vorfall eine Datenschutzverletzung darstellt, die eine Benachrichtigung erfordert.

Schritt 6: Reflektieren und härten

Das Ziel besteht nun darin, aus dem Vorfall zu lernen und Ihren Sicherheitsstatus zu stärken, um ähnliche Vorfälle zu verhindern.

1. Schreiben Sie eine Vorfallzusammenfassung. Dies sollte eine Zeitachse von Ereignissen von der ersten Anzeige bis zur Lösung sowie die Ursachenanalyse, Entscheidungen und Ergriffenen Maßnahmen sowie die gelernten Erkenntnisse umfassen.

2. Verfolgen Sie alle ausstehenden Aktionselemente aus dem Sicherheitsvorfall als Probleme, z. B. verbleibende Wartungsaufgaben und alle Sicherheitsverbesserungen, die basierend auf den gelernten Erkenntnissen implementiert werden müssen.

3. Wenn Sie noch keins haben, stellen Sie sicher, dass Ihr Unternehmen oder Team über einen up-to-Date Security Incident Response Plan verfügt. Dazu sollten definierte Rollen und Verantwortlichkeiten, Eskalationspfade, Kommunikationsprotokolle, Kriterien für die Klassifizierung von Schweregraden und schrittweise Reaktionsverfahren für allgemeine Bedrohungstypen gehören. Copilot kann helfen, diesen Plan basierend auf Ihren spezifischen Anforderungen und Ressourcen zu generieren und zu verfeinern. Weitere Anleitungen finden Sie unter "Was ist die Reaktion auf Vorfälle".

Nächste Schritte

• Falls noch nicht geschehen, erwägen Sie die Härtung Ihres Sicherheitsstatus, um das Risiko zukünftiger Vorfälle zu verringern. Siehe Schutz vor Sicherheitsbedrohungen.