Réponse à un incident de sécurité

Les conseils fournis dans cet article sont destinés aux propriétaires d’entreprise, aux propriétaires d’organisations, aux gestionnaires de sécurité et aux équipes de sécurité. Toutefois, vous devez disposer du rôle propriétaire de l’entreprise pour effectuer plusieurs actions décrites dans cet article. Certaines étapes peuvent nécessiter une coordination avec les propriétaires de l’organisation ou les administrateurs de référentiel.

Présentation

Ce guide vous guide tout au long de la façon de répondre à un incident de sécurité, en décrivant les GitHub surfaces que vous pouvez utiliser pour valider et examiner une menace, ainsi que les outils que vous pouvez utiliser pour les contenir et les corriger.

Prerequisites

Dans l’idéal, vous disposez d’une visibilité du journal d’audit et de l’adresse IP source déjà activée pour l’entreprise (diffusion en continu des données vers un système SIEM (Security Information and Event Management) et vous avez accès à ces données. Consultez « Streaming de journaux d’audit pour votre entreprise ».

Tout au long de votre réponse

À mesure que vous progressez dans votre réponse, assurez-vous que vous :

• Conserver les preuves : prenez des captures d’écran d’activité suspecte, exportez des journaux ou des résultats de requête, puis enregistrez des copies des fichiers ou du code concernés avant le nettoyage.
• Conservez un enregistrement : documentez vos résultats (par exemple, heures, dates, indicateurs de compromission), référentiels affectés) et enregistrez chaque décision que vous prenez.
• Communiquer : informez les parties prenantes pertinentes (telles que les responsables de la sécurité et les responsables de l’ingénierie, ainsi que les équipes juridiques et de confidentialité si les données sensibles sont en danger) et conservez-les mises à jour.

Étape 1 : Évaluer le signal et valider rapidement

L’objectif est de déterminer rapidement si le signal que vous voyez est susceptible d’être une menace réelle et active.

1. Identifier

Essayez d’identifier la nature du signal que vous voyez. Par exemple, le signal affiche les indications des éléments suivants :

• Compromission des informations d’identification (alerte pour un secret divulgué, rapports d'informations d'identification détectées sur un site externe)
• Accès non autorisé ou compromission de compte (rapports de connexions suspectes, validations ou modifications inconnues)
• Exfiltration des données (rapports de modifications ou d’ajouts de fichiers suspects, exécutions de flux de travail inattendues, activité d’API inhabituelle, créations de référentiels inconnus ou modifications inattendues de visibilité du référentiel)
• Injection de code malveillante (rapports de modifications de code suspectes, exécutions de flux de travail inattendues, nouveaux fichiers ajoutés)
• Attaque de la chaîne d’approvisionnement (rapports de versions suspectes de package, alertes pour les dépendances vulnérables)

Pour vous aider à identifier ces signaux de menace au sein de votre organisation ou de votre entreprise, consultez Zones d’investigation courantes des incidents de sécurité.

Nous vous suggérons de ne pas consacrer trop de temps à l’inspection approfondie dans les étapes précédentes de votre enquête, car l’objectif initial est d’identifier le signal de menace afin de le valider et de stratèger votre réponse.

2. Valider

Recherchez des preuves pour vérifier que la menace potentielle est réelle et si elle est actuellement active ou non.

Les outils et surfaces suivants GitHub peuvent vous aider.

Outil / surface	Objectif
Vue d’ensemble de la sécurité et alertes de sécurité	Passer en revue les alertes de sécurité au sein de votre organisation ou de votre entreprise
Journaux d’audit	Rechercher des événements liés au signal que vous examinez, tels que la création de jetons, les modifications d’autorisation ou les modifications de visibilité du référentiel
Vue d’activité	Afficher une chronologie des envois (push), des validations et de l’activité de branche pour un référentiel spécifique
[

          GitHub recherche de code](/code-security/reference/security-incident-response/investigation-tools#github-code-search) | Rechercher des indicateurs connus de compromission, tels que des noms de fichiers ou des modèles de code spécifiques, entre les dépôts |

| Graphe des dépendances | Vérifier si les référentiels dépendent d’un package ou d’une version de package spécifique | | Exécutions et journaux de flux de travail | Revoyez l’historique d’exécution du flux de travail et inspectez la sortie des logs pour une activité suspecte. |

Pour plus d’informations sur chaque outil, consultez Outils d’investigation pour les incidents de sécurité.

La phase de validation peut être rapide :

• Visez à recueillir suffisamment de preuves pour déterminer si le signal est susceptible d’être une menace réelle et active .
• Si vous ne pouvez pas rapidement exclure le signal comme un faux positif, supposons qu’il est réel.
• Une investigation approfondie peut être effectuée ultérieurement.

3. Décider

En fonction de la preuve recueillie, déterminez trois éléments :

1.        **Est-ce une véritable menace ?** Si vous ne pouvez pas rapidement et en toute confiance exclure le signal comme un faux positif, traitez-le comme réel et passez à l’endiguement.
   

2.        **La menace est-elle toujours active ?** Si l’attaquant semble toujours avoir accès ou que l’activité est en cours, hiérarchiser d’abord les actions de confinement immédiates. Si la compromission apparaît historique, vous devez toujours examiner et corriger, mais vous pouvez avoir plus de temps pour planifier votre réponse.
   

3.        **Quelle est l’étendue potentielle ?** Réfléchissez à l’étendue de la compromission : une seule information d’identification, un référentiel, une organisation ou toute l’entreprise. Cela vous aidera à mettre à l’échelle votre réponse de manière appropriée.
   

Si vous avez un doute, traitez la menace comme réelle et réduisez votre réponse au fur et à mesure que les preuves le permettent.

Étape 2 : Contenir la menace

L’étape suivante suppose que vous traitez d’une menace réelle et active. L’objectif est maintenant de réduire immédiatement les risques continus à l’aide de ce que vous savez jusqu’à présent.

Il existe plusieurs actions de confinement que vous pouvez choisir d’effectuer pour limiter l’accès et les fonctionnalités de l’attaquant.

Révoquer les informations d’identification compromises

Pour les informations d’identification exposées ou exploitées, l’action la plus immédiate que vous pouvez entreprendre consiste à révoquer les informations d’identification affectées pour empêcher toute utilisation incorrecte.

• Révoquer via l’API

  Si le jeton est l’un des types suivants et que la valeur littérale du jeton est connue, vous (ou n’importe qui) pouvez le révoquer en envoyant une demande via l’API REST. Consultez « Révocation ».

  • Personal access token (classic)
  • Fine-grained personal access token
  • OAuth app jeton d’accès
  • GitHub App jeton d’accès utilisateur
  • GitHub App jeton d’actualisation

• Options de révocation et de confinement

  Il existe des options supplémentaires pour bloquer l’accès aux informations d’identification. Pour obtenir une liste complète par type d’informations d’identification, consultez Référence des types d'identifiants GitHub.

• Actions d’urgence (incident majeur)

  Les propriétaires d’entreprise sur GitHub Enterprise Cloud peuvent prendre des mesures d’urgence en bloc pour verrouiller l’accès au sein de leur entreprise. Pour les entreprises avec Enterprise Managed Users, cela inclut la suppression de tous les jetons et clés utilisateur. Il s’agit d’actions à impact élevé qui interrompent les automatisations et doivent être réservées aux incidents majeurs. Consultez « Réponse aux incidents de sécurité dans votre entreprise ».

Restreindre l’accès

Pour restreindre l’accès à l’entreprise, à l’organisation ou au référentiel, il existe plusieurs actions immédiates que vous pouvez effectuer.

• Configurer des listes d’autorisation IP

  Empêcher les adresses IP inconnues ou suspectes d’accéder à l’organisation ou à l’entreprise. Consultez Restriction du trafic réseau vers votre entreprise avec une liste d’adresses IP autorisées (administrateurs d’entreprise) et Gestion des adresses IP autorisées pour votre organisation (propriétaires d’organisations).

• Supprimer les utilisateurs compromis ou suspects

  Supprimez l’utilisateur ou suspendez le compte. Consultez Suppression d’un membre de votre organisation (propriétaires d’organisations).

• Modifier la visibilité du référentiel en privé

  Modifiez la visibilité du référentiel affecté en privé et limitez la capacité d’autres personnes à apporter d’autres modifications. Par exemple, si du code sensible a été exposé dans un référentiel public appartenant à l’organisation ou si un acteur malveillant a changé le paramètre de visibilité du référentiel de privé à public, vous pouvez modifier la visibilité du référentiel. Consultez Définition de la visibilité du dépôt (administrateurs de référentiels et propriétaires d’organisations) et Restriction des changements de visibilité des dépôts dans votre organisation (propriétaires d’organisations).

• Actions d’urgence (incident majeur)

  Les propriétaires d’entreprise sur GitHub Enterprise Cloud peuvent prendre des mesures d’urgence en bloc pour verrouiller l’accès au sein de leur entreprise. Il s’agit notamment de verrouiller l’authentification unique pour bloquer tout accès non propriétaire et révoquer toutes les autorisations d’authentification unique des utilisateurs dans les organisations. Il s’agit d’actions à impact élevé qui interrompent les automatisations et doivent être réservées aux incidents majeurs. Consultez « Réponse aux incidents de sécurité dans votre entreprise ».

Désactiver les artefacts et l’activité malveillants

• Arrêter les exécutions de flux de travail malveillantes

  Si vous pensez qu’un GitHub Actions workflow ou un exécuteur est utilisé dans le cadre d’une attaque active, vous pouvez effectuer les actions suivantes :

  • Annuler les exécutions de flux de travail en cours pour un référentiel affecté. Consultez « Annulation d’une exécution de workflow ».
  • Désactivez GitHub Actions pour un dépôt affecté dans une organisation, ou pour une certaine organisation. Consultez Désactivation ou limitation des GitHub Actions pour votre organisation (propriétaires d’organisations) et Application de stratégies pour GitHub Actions dans votre entreprise (administrateurs d’entreprise).
  • Supprimez les exécuteurs auto-hébergés. Consultez « Suppression d’exécuteurs auto-hébergés ».

• Désactiver les webhooks

  Si vous pensez qu’un dépôt compromis ou un webhook d’organisation est utilisé comme canal d’exfiltration de données actives, vous pouvez le désactiver. Consultez « Désactivation des webhooks ».

• Supprimer des branches malveillantes

  Si vous avez identifié des branches qui contiennent du code ou des flux de travail malveillants, supprimez-les immédiatement pour empêcher l’exécution. Consultez « Création et suppression de branches dans votre référentiel ».

Étape 3 : Examiner entièrement

Après l’endiguement immédiat, l’objectif est maintenant de comprendre l’étendue et l’impact complets de l’incident, d’identifier tous les ioCs et les mécanismes de persistance, et de recueillir les preuves dont vous avez besoin pour contenir et corriger entièrement la menace.

1. En fonction des signaux que vous avez vus et des preuves recueillies jusqu'à présent, élaborez une hypothèse de travail sur ce qui s'est passé et décidez quelles preuves supplémentaires vous devrez réunir pour prouver ou invalider cette hypothèse.

2. Considérez les différents domaines d’investigation décrits dans Zones d’investigation courantes des incidents de sécurité pour vous aider à guider votre enquête.

   Ne limitez pas votre enquête à une seule ligne d’enquête. De nombreuses attaques utilisent une combinaison de techniques, telles que l’installation de packages malveillants combinée à l’exploitation des informations d’identification, aux injections de fichiers de flux de travail et à l’exfiltration des données. Vérifiez que vous examinez tous les vecteurs d’attaque potentiels.

3.        **Documentez** tous les IoCs connus jusqu’à présent, en recherchant des traces sur toutes les surfaces de GitHub.
   

4.        **Stockez** tous les flux de travail, référentiels et organisations concernés pour capturer systématiquement l’étendue de l’incident.
   

   • Incluez le nom du référentiel, ce qui a été affecté (code, secrets, workflows) et la chronologie de compromission.
   • Créez une liste de tous les comptes et informations d’identification affectés. Notez quels jetons, clés SSH ou autres informations d’identification peuvent avoir été exposés ou mal utilisés.

5.        **Validez** votre hypothèse de travail contre les preuves.
   

   • Passez en revue les preuves que vous avez recueillies. Prend-il en charge votre hypothèse initiale ?
   • Envisagez d’autres explications. Y a-t-il une autre cause pour l’activité que vous avez observée ?
   • Si votre hypothèse est réfutée, formez une nouvelle hypothèse basée sur les faits et répétez les étapes de l'investigation si nécessaire.

6.        **Revenez à l’isolement** si vous découvrez de nouveaux IoCs ou des preuves d’activités en cours qui nécessitent une action immédiate.
   

Une fois que vous avez une grande confiance dans votre compréhension de ce qui s’est passé et de la cause racine, documentez vos résultats et passez à la correction.

Étape 4 : Corriger

L’objectif est maintenant de supprimer toutes les traces de compromission, de corriger la cause racine et de restaurer les systèmes à un état sécurisé. Les actions de correction dépendent de l’exploitation que vous avez rencontrée, mais certaines bonnes pratiques sont les suivantes.

Rotation de jetons et de secrets

Même si vous n’êtes pas certain qu’une information d’identification a été compromise, faites-la pivoter s’il existe une possibilité d’exposition.

• Générez de nouveaux jetons et secrets pour remplacer tous les jetons révoqués ou susceptibles d’avoir été exposés.
• Faire pivoter les secrets stockés au GitHub niveau du référentiel, de l’environnement et de l’organisation.
• Mettez à jour les informations d’identification dans les systèmes externes qui ont pu être accessibles à l’aide de jetons compromis.
• Envisagez d’activer les stratégies d’expiration des jetons pour encourager la rotation régulière à l’avenir. Consultez « Application de stratégies pour les jetons d’accès personnels dans votre entreprise ».

Audit pour les mécanismes de persistance

Vous devrez vérifier les mécanismes de persistance que l’attaquant a peut-être établis pour maintenir l’accès même après vos actions initiales de confinement.

Cela inclut, mais n’est pas limité à, la vérification des éléments tels que :

• Fichiers de flux de travail suspects ou inconnus qui ont peut-être été ajoutés ou modifiés.
• Nouveaux webhooks pointant vers des domaines inconnus.
• Nouveaux exécuteurs auto-hébergés.
• Modifications apportées aux exécuteurs auto-hébergés.
• Nouvelles autorisations GitHub Apps ou OAuth app installées.
• Nouvelles clés de déploiement ajoutées aux référentiels.
• Nouveaux fichiers binaires ou exécutables.

Auditer et réinstaller les dépendances

Les dépendances compromises peuvent servir de vecteur d’attaque. Veillez à effectuer un audit complet de vos dépendances et à les réinstaller à partir de sources approuvées.

• Passez en revue les alertes pour les Dependabot dépendances vulnérables et, le cas échéant, Dependabot malware alerts pour les packages malveillants. (Dependabot malware alerts sont actuellement disponibles pour l’écosystème npm.) Pour examiner d’autres avis sur les programmes malveillants, recherchez type:malware dans le graphe de dépendances et auditez vos correspondances.
• Épinglez des dépendances à des versions connues ou validez des contrats SHA et réinstallez-les à partir de votre registre de packages.

Vérifier la correction

Vérifiez que vos efforts de correction ont réussi.

• Passez en revue code scanning les alertes pour vérifier que les vulnérabilités du code ont été résolues et aucune nouvelle vulnérabilité n’a été introduite.
• Passez en revue secret scanning les alertes pour vérifier qu’aucun secret n’est exposé dans tous les référentiels et que toutes les alertes ont été résolues.
• Passez en revue et surveillez les journaux d’audit et d’autres surfaces pertinentes au cours des prochains jours et semaines après l’incident.

Étape 5. Document

Une documentation approfondie est essentielle pour les phases restantes et pour les références futures.

• Enregistrez tous les IoCs découverts pendant l’enquête.
• Documentez toutes les étapes de correction effectuées, y compris les horodatages et les personnes qui ont effectué chaque action.
• Conservez des inventaires de référentiels, de flux de travail et de comptes affectés.
• Documentez les décisions prises et le raisonnement derrière eux.
• Notez les implications en matière de conformité, de droit ou de confidentialité. Déterminez si cet incident constitue une violation de données qui nécessite une notification.

Étape 6 : Refléter et renforcer

L’objectif est maintenant d’apprendre de l’incident et de renforcer votre posture de sécurité pour empêcher les incidents similaires.

1. Écrivez un résumé des incidents. Cela doit inclure une chronologie des événements de première indication à la résolution, ainsi que l’analyse de la cause racine, les décisions et les actions prises et les leçons apprises.

2. Suivez les éléments d’action en suspens de l’incident de sécurité en tant que problèmes, tels que les tâches de correction restantes et toutes les améliorations de sécurité qui doivent être implémentées en fonction des leçons apprises.

          Copilot peut vous aider à créer ces éléments, et vous pouvez affecter des problèmes bien définis pour Copilot de manière indépendante. Voir [AUTOTITLE](/copilot/how-tos/use-copilot-agents/coding-agent/create-a-pr#assigning-an-issue-to-copilot).
   

3. Si vous n’en avez pas encore, assurez-vous que votre entreprise ou votre équipe dispose d’un plan de réponse aux incidents de sécurité up-todate. Cela doit inclure des rôles et responsabilités définis, des chemins d’escalade, des protocoles de communication, des critères de classification de gravité et des procédures de réponse pas à pas pour les types de menaces courants. Copilot peut vous aider à générer et à affiner ce plan en fonction de vos besoins et ressources spécifiques. Pour obtenir des conseils supplémentaires, consultez La réponse aux incidents.

Étapes suivantes

• Si vous ne l’avez pas déjà fait, envisagez de renforcer votre posture de sécurité pour réduire le risque d’incidents futurs. Consultez « Protection contre les menaces de sécurité ».