Outils d’investigation pour les incidents de sécurité

          GitHub Les principaux outils que vous pouvez utiliser pour examiner les incidents de sécurité, ce que chaque outil est le mieux utilisé et les considérations courantes qui affectent les données disponibles.

Dans cet article

Utilisez cette référence pour déterminer quels GitHub outils utiliser lors d’une enquête de sécurité, quelles questions chaque outil peut répondre et quels facteurs peuvent affecter les données que vous pouvez voir.

Remarque

La disponibilité de chaque outil (et les données qu’il fournit) varie en fonction GitHub du plan, de votre rôle et de vos 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).

Vue d’activité

Utiliser

  • Obtenez une vue d’ensemble de l’activité dans un référentiel spécifique, notamment les fusions, les poussées, les poussées forcées, les créations et suppressions de branches, attribuées à des acteurs spécifiques sur une période définie.
  • Corréler les apparitions suspectes de code avec les poussées ou les intégrations associées.
  • Répondez aux questions sur le moment où une modification a été apportée, qui l’a fait, dans quelle branche, et explorez l’historique des différences ou des validations.

Permissions

Accès en lecture au référentiel.

Ressources clés

Notes et limitations

  • L’affichage d’activité est le mieux utilisé comme surface de navigation initiale et de corrélation ; elle n’a pas la même puissance d’exhaustivité ou de requête que les exportations de journaux d’audit brutes.
  • Certains incidents nécessitent une corrélation entre les référentiels ou les organisations, ce qui peut être plus facile dans le journal d’audit.

Journaux d’audit

Utiliser

  • Répondez aux questions sur ce qui a changé, quand et par qui au sein d’une entreprise ou d’une organisation.
  • Examinez les événements qui peuvent avoir activé la compromission ou l’indiquer, tels que les modifications apportées à l’appartenance, aux rôles, aux autorisations ou à la génération ou à l’utilisation de jetons d’accès, etc.
  • Attribuer des actions pertinentes pour la sécurité à un acteur (utilisateur ou intégration) et créer une chronologie d’investigation.
  • Filtrez par acteur, action, adresse IP (si activé) ou jeton, pour identifier l’activité suspecte ou l’utilisation du jeton de trace.
  • Mettre en corrélation l’activité entre plusieurs référentiels ou organisations.

Permissions

  • Pour afficher le journal d’audit de l’organisation, vous devez être propriétaire de l’organisation.
  • Pour afficher le journal d’audit d’entreprise, vous devez être administrateur d’entreprise.
  • Pour afficher le journal de sécurité (compte personnel), vous devez être le propriétaire du compte.
  • Pour afficher les données du journal d’audit exportées vers un système SIEM (Security Information and Event Management) externe, le système de gestion des journaux ou d’autres outils et services, vous devez accéder à ce système.

Ressources clés

Notes et limitations

  • GitHubfournit trois journaux d’audit : les journaux****d’activité d’entreprise, d’organisation et de sécurité utilisateur.
  • L’interface utilisateur du GitHub journal d’audit a des fonctionnalités de filtrage et de recherche limitées . Pour cette raison, nous recommandons aux entreprises de diffuser en continu le journal d’audit d’entreprise vers un système SIEM externe ou de gestion des journaux pour des requêtes plus avancées.
    • Le streaming des journaux d’audit vers un système SIEM ou de gestion des journaux externe nécessite une configuration antérieure. Consultez « Streaming de journaux d’audit pour votre entreprise ».
    • Sans diffusion en continu du journal d’audit, vous ne pourrez pas exécuter de requêtes plus complexes, telles que la corrélation d’événements entre les organisations ou les référentiels, ou le fait de pivoter à partir d’un jeton spécifique à tous les événements associés.
    • Les données d’événements Git sont incluses dans le flux.
  • Nous vous recommandons de diffuser en continu des événements de demande d’API ; cela nécessite une configuration antérieure. Consultez « Streaming de journaux d’audit pour votre entreprise ».
  • Pour les entreprises sur GitHub Enterprise Cloud, nous vous recommandons d’afficher des adresses IP dans les journaux d’audit. Cela nécessite une configuration antérieure. Consultez « Affichage des adresses IP dans le journal d’audit de votre entreprise ».
  • Différents GitHub plans ont différentes offres de disponibilité des données et de rétention des données :
    • GitHub Free et GitHub Team les plans ne peuvent pas afficher l’activité de l’API ni les événements Git du tout.
    • Les organisations autonomes (organisations qui ne font pas partie d’une entreprise) ne peuvent pas diffuser en continu les journaux d’audit, ne peuvent pas afficher les événements de demande d’API et sont limitées à 7 jours pour les données d’événements Git.
    • Pour les entreprises utilisant GitHub Enterprise Cloud
      • Si votre entreprise utilise Enterprise Managed Users, le journal d’audit inclut également les journaux de sécurité utilisateur (événements liés aux comptes d’utilisateur, tels que l’activité de connexion et l’utilisation des jetons).
      • Si votre entreprise _n’utilise_Enterprise Managed Users pas, le GitHub journal d’audit inclut uniquement les événements liés au compte d’entreprise et aux organisations qu’il contient.
  • Les journaux d’audit n’incluent pas la consultation de page ni la télémétrie de navigation du référentiel.

Graphe de dépendances

Utiliser

  • Vérifiez si un référentiel dépend d’un package vulnérable ou compromis (ou version).
  • Passez en revue les dépendances nouvelles ou suspectes qui ont pu être introduites lors d’un incident.
  • Filtrez et explorez les dépendances par écosystème ou relation (direct ou transitif).
  • Exportez une facture logicielle de matériaux (SBOM) à des fins d’audit ou pour préserver les preuves.

Permissions

  • Écrivez ou conservez l’accès au référentiel.

Ressources clés

Notes et limitations

  • Le graphique de dépendances est généré à partir de fichiers manifeste/verrou pris en charge (et soumissions au moment de la génération facultatives), de sorte qu’il peut être incomplet ou différent de ce qui a été réellement généré et déployé. Pour obtenir la vue la plus précise, en particulier pour les dépendances résolues pendant CI/build, vous devez compléter le graphique de dépendances avec la soumission de dépendance au moment de la génération (ou d’autres sources de build telles que les SBOMs).

          GitHub recherche de code

Utiliser

  • Recherchez les indicateurs de compromission (IoCs) dans les référentiels, tels que les flux de travail malveillants ou les noms de paquets.
  • Limitez rapidement le rayon d’explosion potentiel en vérifiant si des modèles de code suspects, tels qu’un secret fuite ou un extrait de code malveillant, apparaissent dans d’autres référentiels au sein de l’organisation ou de l’entreprise.
  • Limitez la recherche par différents qualificateurs qui peuvent être utiles pendant un incident, par exemple :
    • Effectuez une recherche dans un référentiel, une organisation ou une entreprise spécifique (à l’aide des qualificateurs, repo: etcorg:``enterprise:.).
    • Rechercher dans des chemins de fichier spécifiques (path:.github/workflows repo:ORG-NAME/REPO-NAME).

Autorisations requises

  • Pour effectuer une recherche dans des référentiels publics, vous devez être connecté à votre GitHub compte.
  • Pour effectuer une recherche dans des référentiels privés, vous devez disposer d’un accès en lecture à ces référentiels.

Ressources clés

Notes et limitations

  • Prend en charge la recherche regex.
  • Recherche uniquement dans la branche par défaut d’un référentiel. Si le code suspect a été introduit dans une branche non par défaut et n’a pas été fusionné, il n’est pas trouvé par recherche de code.
  • Vous pouvez utiliser la recherche de code pour déterminer si un modèle ou un IoC est présent, mais il ne fournit pas de contexte tel que lorsque le code a été ajouté ou par qui. Vous devez utiliser la recherche de code conjointement avec d'autres outils, tels que les journaux d'audit, la vue d'activité ou la vérification de la vue de la responsabilité, de l'historique des validations et de l'historique des pull requests d'un dépôt.

Vue d’ensemble de la sécurité et alertes de sécurité

Utiliser

  • Consultez une vue générale de toutes les alertes de sécurité (secret scanning, code scanning et Dependabot alertes) dans les dépôts d'une organisation ou entreprise.
  • Triez ce qui GitHub a déjà détecté et identifiez les référentiels affectés.
  • Suivez les nouvelles alertes créées lors d’un incident (ce qui peut indiquer une exploitation ou une propagation actives).

Autorisations requises

  • Pour afficher les données des organisations au niveau de l’entreprise, un administrateur d’entreprise doit avoir le rôle propriétaire de l’organisation ou gestionnaire de sécurité dans les organisations concernées.
  • Pour afficher les données des référentiels au niveau de l’organisation, le rôle propriétaire de l’organisation ou gestionnaire de sécurité est requis.

Ressources clés

Notes et limitations

  • Les alertes pour les secrets divulguées, le code vulnérable, les dépendances vulnérables et les programmes malveillants ne sont visibles que si les fonctionnalités pertinentes ont été activées et configurées avant l’incident.

Exécutions et journaux de flux de travail

Utiliser

  • Vérifiez ce qui a été exécuté dans CI/CD à un moment donné (par exemple, les commandes exécutées ou la dépendance installée).
  • Examinez les exécutions de flux de travail suspectes, telles que celles déclenchées par un utilisateur inconnu ou à un moment inhabituel, pour voir quelles actions ont été effectuées, quels secrets ont été consultés et quel code a été exécuté.
  • Déterminez si un flux de travail avait accès à des secrets.

Autorisations requises

  • Accès en lecture au référentiel.

Ressources clés

Notes et limitations

  • GitHub réduit automatiquement les secrets dans les journaux de flux de travail.
  • Par défaut, les journaux de flux de travail sont conservés GitHub pendant 90 jours, mais vous pouvez configurer cette période de rétention pour qu’elles soient plus longues (jusqu’à 400 jours pour les dépôts privés).