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

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

Utilisation de l’affichage d’activité pour afficher les modifications apportées à un référentiel

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 :
- ```
          Les offres GitHub Free et GitHub Team ne peuvent pas afficher l’activité de l’API ni les événements Git.
```
- 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 la CI/le build, vous devriez compléter le graphe de dépendances avec une soumission de dépendances au moment du build (ou avec d’autres éléments de provenance de build, tels que des SBOM).

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

Recherche de code

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é.
Passez en revue les informations d’identification auxquelles une tâche de workflow avait accès, y compris l’élément par défaut GITHUB_TOKEN, les jetons personal access tokens, GitHub App, les autres informations d’identification stockées comme secrets et les jetons d’accès obtenus pendant l’exécution du workflow.
Récupérez les journaux par programmation via l’API REST à des fins d’archivage, d’investigation ou d’automatisation.

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 workflow.
Par défaut, les journaux de flux de travail sont conservés pendant GitHub 90 jours, mais vous pouvez configurer cette période de rétention. La rétention maximale est de 400 jours. La rétention peut être configurée au niveau de l’entreprise, de l’organisation ou du référentiel. Si une exécution de flux de travail s’est produite en dehors de votre fenêtre de rétention configurée, les journaux peuvent ne plus être disponibles. Pour plus d’informations, consultez Gestion des paramètres de GitHub Actions pour un référentiel, Configuration de la période de rétention des artefacts et des journaux GitHub Actions dans votre organisation ou Application de stratégies pour GitHub Actions dans votre entreprise.
Les exécutions de flux de travail (y compris leurs journaux) peuvent également être supprimées via l’API REST. Pour vérifier si une exécution a été supprimée, recherchez les événements workflows.delete_workflow_run dans le journal d’audit.
La valeur par défaut GITHUB_TOKEN émise pour chaque travail est limitée à ce travail et expire lorsque le travail se termine ou après sa durée de vie maximale effective (jusqu’à 24 heures sur les exécuteurs auto-hébergés). Même si une étape a capturé le jeton, elle ne peut pas être réutilisée une fois la tâche terminée. Pour plus d’informations, consultez « GITHUB_TOKEN ».
D’autres informations d’identification référencées dans les flux de travail, telles que personal access tokensles GitHub App jetons d’installation ou les clés API tierces stockées en tant que secrets, ont leur propre cycle de vie et n’expirent pas lorsque le travail se termine. Si une étape de flux de travail a exposé l’une de ces informations d’identification, le jeton reste valide jusqu’à ce qu’il soit révoqué ou expire en fonction de sa propre stratégie. Tout identifiant ayant pu être exposé doit être considéré comme compromis et être renouvelé ou remplacé immédiatement. Passez en revue le fichier de flux de travail et le référentiel, l’organisation et les secrets d’environnement pour déterminer les informations d’identification qui ont été accessibles. Pour plus d’informations, consultez « Utilisation de secrets dans GitHub Actions ».
Vous pouvez télécharger des journaux d’activité pour une exécution complète du flux de travail ou pour un travail spécifique par programmation à l’aide de l’API REST. Les deux points de terminaison retournent une URL de redirection valide pendant une minute. Pour plus d’informations, consultez « Points de terminaison d'API REST pour l'exécution des workflows » et « Points de terminaison d’API REST pour les tâches de workflow ».
Les journaux d’exécution de flux de travail capturent uniquement la sortie standard des étapes de flux de travail. L’activité qui n’écrit pas dans la sortie standard, comme les appels réseau, les modifications du système de fichiers ou les processus en arrière-plan, n’apparaît pas dans les journaux.
Pour les exécuteurs hébergés par GitHub, l’environnement de l’exécuteur est éphémère et est détruit une fois le job terminé. GitHub ne conserve pas de données au-delà des journaux d’exécution du workflow pour ces runners. Pour les exécuteurs auto-hébergés, des données de télémétrie supplémentaires au niveau de l’hôte ou du réseau peuvent être disponibles issues de votre propre infrastructure.
Pour une investigation plus complète, mettez en corrélation les journaux d’exécution de flux de travail avec les événements du journal d’audit. Les événements tels que git.clone, , git.fetch``git.push, protected_branch.createet protected_branch.policy_override peuvent fournir un contexte supplémentaire. Étant donné que les événements Git dans les journaux d’audit hébergés sur GitHub ne sont actuellement conservés que pendant 7 jours au sein des entreprises, il est important de configurer à l’avance la diffusion en continu des journaux d’audit de l’entreprise pour ce type d’enquête. Pour plus d’informations, consultez « Préparation d’un incident de sécurité ».

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

Dans cet article