Skip to main content

Zones d’investigation courantes des incidents de sécurité

Références pour l'examen des incidents de sécurité sur plusieurs vecteurs d’attaque, y compris les outils et surfaces clés à examiner GitHub.

Cet article de référence vous montre les GitHub outils à utiliser et les GitHub surfaces à vérifier lorsque vous répondez à un incident de sécurité. Utilisez cet article pour guider votre enquête sur les principales catégories de menaces.

Pour obtenir des conseils complets sur la façon de répondre à un incident de sécurité, y compris les stratégies d’isolement, consultez Réponse à un incident de sécurité.

Important

La disponibilité de chaque outil (et les données qu’il fournit) varie en fonction GitHub du plan, du rôle, des autorisations, de l’activation des fonctionnalités et de la configuration avant incident (par exemple, la diffusion en continu du journal d’audit et la divulgation d’adresses IP nécessitent une configuration antérieure). Pour plus d’informations, consultez « Outils d’investigation pour les incidents de sécurité ».

Sachez que les incidents de sécurité réels impliquent rarement un seul vecteur d’attaque. Une compromission des informations d’identification peut entraîner une injection de code malveillante, ce qui peut activer l’exfiltration des données. Lorsque vous analysez un signal de menace, préparez-vous à passer à d’autres domaines d’investigation, et à faire des allers-retours entre l’isolement, des investigations plus profondes et des remédiations, au fur et à mesure que vous découvrez de nouveaux indicateurs de compromission et que votre compréhension du modèle de menace évolue.

Informations d’identification exposées ou compromises

Cette section peut s’appliquer quand :

Vous soupçonnez qu’un jeton ou une clé a été volé ou exploité, ou avez reçu une secret scanning alerte, ou trouvé des informations d’identification exposées dans le code, les journaux ou un référentiel public.

Les points à vérifier

  • Recherchez dans le journal d’audit :
  • Examinez secret scanning les alertes pour analyser les résultats pertinents afin d’évaluer l’emplacement, l’exposition et la validité d’un secret divulgué.
  • Utilisez la vue d’ensemble de la sécurité pour votre entreprise ou votre organisation pour identifier les tendances ou les activités entre les référentiels.
  • Utilisez GitHub la recherche de code pour vérifier les secrets exposés dans le code, .env les fichiers ou les fichiers de configuration dans les référentiels.

Outils clés

ToolObjectif
Journal d’auditUtilisation des jetons de trace
Vue d’ensemble de la sécuritéAfficher les alertes et activités de sécurité au niveau de l’organisation et/ou de l’entreprise, en particulier les alertes secret scanning.
[
          GitHub recherche de code](/code-security/reference/security-incident-response/investigation-tools#github-code-search) | Rechercher des informations d’identification exposées dans le code |

Ressources clés

Compromission d’accès et de compte non autorisés

Cette section peut s’appliquer quand :

Vous avez remarqué une activité de connexion inhabituelle, vu des validations inattendues ou des modifications, ou détecté un comportement suspect de compte.

Les points à vérifier

  • Recherchez dans le journal d’audit les modifications d’accès, d’autorisations ou de rôle des membres. Par exemple, recherchez des événements tels que org.add_member, , repo.add_member``org.add_outside_collaborator``org.update_member, repo.update_member, , role.create, . role.update
  • Pour tous les événements suspects dans le journal d’audit, identifiez l’acteur. Vérifiez si l’acteur est un utilisateur inconnu, un compte potentiellement compromis ou une application non reconnue.
  • Si la visibilité de l’adresse IP est activée, vérifiez si l’adresse IP associée à des événements inhabituels ou une activité suspecte est reconnue.
  • Recherchez dans le journal d’audit les événements relatifs aux clés ou applications nouvellement créées, par exemple public_key.create, integration_installation.create.
  • Passez en revue le journal d’audit pour les modifications inattendues du référentiel, telles que les nouveaux référentiels publics ou les modifications de visibilité des référentiels (privés à publics), par exemple repo.create. repo.access
  • Utilisez la vue d’activité (au niveau du référentiel) pour générer une chronologie des envois push récents. Recherchez les pushs à partir d'acteurs inattendus, les pushs forcés ou les noms de branche inhabituels.

Outils clés

ToolObjectif
Journaux d’auditRechercher et vérifier des actions, des acteurs et des adresses IP
Vue d’activitéRéviser l'activité pour des dépôts spécifiques

Ressources clés

Exfiltration de données

Cette section peut s’appliquer quand :

Vous avez détecté des téléchargements volumineux, une activité d'API inhabituelle ou des rapports indiquant que vos données apparaissent à l'extérieur.

Les points à vérifier

  • Rechercher dans les journaux d'audit les opérations Git de volume élevé (git.clone, git.fetch) ou les demandes d'API, en particulier provenant d'un acteur inconnu (actor) ou d'une adresse IP (si la visibilité de l'adresse IP est activée), qui indiquent une collecte massive de données.
    • Notez que les événements Git dans le journal d’audit ont des exigences d’accès et des stratégies de rétention spéciales qui diffèrent des autres événements du journal d’audit. Pour GitHub Enterprise Cloud, vous pouvez accéder aux événements Git via l'API REST, et les données sont conservées pendant sept jours, à moins que vous ne diffusiez le journal d'audit. Pour GitHub Enterprise Server, les événements Git doivent être activés dans la configuration du journal d’audit et ne sont pas inclus dans les résultats de recherche.
    • De même, la capture de l’activité d’API dans les journaux d’audit nécessite une configuration antérieure et n’est pas disponible par défaut.
  • Vérifiez les journaux d’audit pour la réplication des référentiels ou les événements d’exposition, par exemple, les modifications de visibilité des référentiels (du privé au public), les nouveaux référentiels inattendus créés (tels que les nouveaux référentiels publics) ou les référentiels renommés ou transférés (repo.create, repo.access (modifications de visibilité), repo.rename). repo.transfer
  • Recherchez les mécanismes sortants, par exemple les webhooks créés ou mis à jour (hook.create ou des événements similaires dans les journaux d’audit) et vérifiez si un webhook pointe vers un domaine non reconnu.

Outils clés

ToolObjectif
Journaux d’auditRechercher des actions pertinentes

Ressources clés

Modifications de code et de flux de travail malveillantes

Cette section peut s’appliquer quand :

Vous avez trouvé du code suspect dans votre référentiel, un chercheur de sécurité a signalé un problème ou vous avez remarqué un comportement inattendu de flux de travail.

Les points à vérifier

  • Passez en revue l’onglet Actions pour les exécutions de flux de travail inattendues, en particulier celles déclenchées par des utilisateurs inconnus ou à des moments inhabituels.
  • Inspectez les journaux d’exécution du flux de travail à la recherche de résultats suspects.
  • Utilisez GitHub la recherche de code pour rechercher des fichiers suspects ou des ajouts de code, en particulier dans les fichiers de flux de travail (.github/workflows/), les scripts shell ou les fichiers de configuration.
  • Utilisez la vue Activité pour rechercher des envois (push) vers des noms de branche inhabituels, des envois forcés (force pushes), et des envois à partir d'acteurs inattendus.
  • Vérifiez les journaux d’audit pour connaître les modifications apportées aux paramètres de sécurité ou les actions de désactivation (recherchez des événements tels que repository_ruleset.destroy, repository_secret_scanning_push_protection.disableou d’autres .delete, .disabledes .destroy événements).
  • Vérifiez les journaux d’audit des événements liés aux nouveaux exécuteurs auto-hébergés ajoutés (par exemple, les événements org.register_self_hosted_runner / repo.register_self_hosted_runner).
  • Vérifiez le Dependabot alerts ou les GitHub Advisory Database pour les consignes liées à l'utilisation de GitHub Actions dans vos processus de travail.

Outils clés

ToolObjectif
Exécutions et journaux de flux de travailExaminer l'exécution du workflow et inspecter la sortie du journal
Vue d’activitéIdentifier les push inattendus, les push forcés ou les push provenant d’acteurs inconnus
[
          GitHub recherche de code](/code-security/reference/security-incident-response/investigation-tools#github-code-search) | Rechercher des modèles de code suspects |

| Journaux d’audit | Filtrer par action pour rechercher les modifications des paramètres de sécurité |

Ressources clés

Attaques contre les programmes malveillants et la chaîne d’approvisionnement

Cette section peut s’appliquer quand :

Vous avez reçu un programme malveillant ou une alerte de dépendance, suspectez un package malveillant ou notez des dépendances inattendues dans vos projets.

Les points à vérifier

  • Recherchez une Dependabot alerte de programme malveillant, qui peut vous indiquer des détails sur le package malveillant (par exemple, le nom du package, les versions affectées et la version corrigée), ainsi que les étapes de correction. Actuellement pris en charge uniquement pour les paquets dans l’écosystème npm.
  • Recherchez dans le GitHub Advisory Database pour voir si GitHub fait des rapports d'avis sur les dépendances (ou les versions de dépendance) que vos projets utilisent. Pour les programmes malveillants spécifiquement, recherchez type:malware dans la base de données de conseil.
  • Utilisez GitHub la recherche de code pour rechercher des références au package ou à l’action soupçonnés au sein de votre organisation.
  • Passez en revue le graphique des dépendances de vos référentiels pour identifier les dépendances nouvelles ou inattendues.
  • Utilisez l’affichage d’activité et vérifiez l’historique des validations pour passer en revue les modifications récentes apportées aux manifestes de dépendance ou aux fichiers de verrou (par exemple, package.json, , package-lock.json``Gemfile.lock). Vérifiez les vues de blame et les pull requests pour identifier qui a introduit les modifications et si elles ont été examinées.
  • Passez en revue les alertes de sécurité récemment créées dans la vue d’ensemble de la sécurité de votre organisation.

Outils clés

ToolObjectif
[
          GitHub recherche de code](/code-security/reference/security-incident-response/investigation-tools#github-code-search)| Rechercher des références au package ou à l’action soupçonné |

| Graphe des dépendances | Visualiser et passer en revue les dépendances | | Dependabot Alertes | Examiner les alertes relatives aux dépendances vulnérables | | GitHub Advisory Database| Rechercher type:malware | | Vue d’activité | Passer en revue les poussées récentes vers les dépôts | | Vue d’ensemble de la sécurité | Passer en revue les alertes de sécurité récentes au sein d’une organisation ou d’une entreprise |

Ressources clés

Lectures complémentaires