Remédier les incidents

Vue d'ensemble

Une remédiation efficace des incidents de secrets publics requiert une approche qui équilibre urgence et prise de décision éclairée. La clé est de distinguer les incidents qui nécessitent une action de sécurité immédiate de ceux qui peuvent être ignorés en toute sécurité car non pertinents pour votre organisation.

Comprendre les issues d'incident

La remédiation d'un incident public peut aboutir à deux issues :

Résoudre les incidents

Marquez les incidents comme Resolved lorsqu'ils représentent de réels risques de sécurité que vous avez traités via les étapes de remédiation appropriées (rotation des secrets, suppression de l'exposition, etc.).

Ignorer les incidents

Marquez les incidents comme Ignored lorsqu'ils ne sont pas pertinents pour votre organisation — par exemple des identifiants personnels sans rapport ou des faux positifs. Ignorer aide à nettoyer votre backlog d'incidents pour vous concentrer sur les vraies menaces sans être submergé par des alertes non pertinentes.

Avant de remédier : investiguer l'incident

Prenez le temps d'investiguer en profondeur votre incident et d'évaluer son impact potentiel. Il peut être difficile d'estimer les dommages potentiels en regardant uniquement le code environnant. N'oubliez pas que :

• Des données sensibles apparaissent souvent dans les projets personnels des développeurs
• Un seul identifiant avec des privilèges élevés peut compromettre toute une organisation
• Plusieurs applications peuvent partager le même secret
• Certains secrets peuvent permettre d'en découvrir d'autres (par exemple, des Slack tokens accédant à des fichiers partagés, des GitHub tokens accédant à des dépôts privés)

Utilisez les propriétés de l'incident pour évaluer si l'incident affecte réellement votre organisation.

Impliquer le développeur

Inclure le développeur responsable de l'incident dans le processus de remédiation est souvent essentiel, car il dispose de connaissances sur :

• Ce à quoi le secret donne accès
• Les services et applications qui en dépendent
• Les autres membres de l'équipe susceptibles d'être affectés
• Le contexte autour de l'exposition

GitGuardian propose deux moyens de collaborer avec les développeurs :

Partager le lien public de l'incident

Générez un lien public à envoyer au développeur impliqué pour obtenir un retour sur l'incident. Cette approche fonctionne que le développeur fasse encore partie de votre organisation ou de votre espace de travail ou non.

À utiliser avec prudence : ces liens sont accessibles publiquement sans authentification.

Donner accès au sein de la plateforme

Si le développeur impliqué est à la fois un employé actuel de votre organisation et un membre de votre espace de travail GitGuardian, vous pouvez lui donner un accès direct à l'incident. Il pourra consulter les détails dans la section Public Monitoring et fournir un retour directement via le tableau de bord.

C'est l'approche plus sûre puisqu'elle ne nécessite pas de générer des liens accessibles publiquement, mais elle n'est disponible que lorsque le développeur est déjà membre de l'espace de travail.

info

L'appartenance des développeurs à l'espace de travail est fréquente lorsque les organisations utilisent Internal Monitoring, car ils sont généralement ajoutés pour collaborer sur les incidents de sécurité internes.

Automatiser la remédiation avec des playbooks

Les playbooks GitGuardian peuvent automatiser les workflows de remédiation pour les incidents publics, vous aidant à gérer efficacement de gros volumes d'incidents.

Apprenez-en plus sur la configuration des playbooks pour votre espace de travail. La plupart des playbooks qui fonctionnent pour les incidents internes peuvent également être activés pour les incidents publics.

Consultez la liste complète des playbooks disponibles et leurs options de configuration.

Résoudre les incidents impactants confirmés

Lorsqu'un incident est confirmé comme pertinent et représente un risque de sécurité, voici quelques recommandations pour agir :

1. S'assurer que le secret compromis est révoqué

Une fois qu'un secret apparaît publiquement sur GitHub, vous devez le considérer comme compromis et garantir sa révocation immédiate. Selon les cas, cela peut nécessiter l'aide du développeur impliqué.

Si le secret est sous votre contrôle direct et utilisé dans vos systèmes et applications, voici des étapes plus détaillées que vous pouvez suivre :

• Stockez votre secret dans un Secret Manager s'il ne l'est pas déjà
• Corrigez le code de votre application pour référencer correctement le secret, s'il a aussi fuité dans votre base de code interne
• Générez de nouveaux identifiants pour remplacer ceux exposés
• Mettez à jour tous les systèmes et applications utilisant les anciens identifiants
• Révoquez ou désactivez les identifiants compromis

2. Optionnel : supprimer les preuves

En plus de révoquer le secret, vous pouvez vouloir éliminer toutes les traces du secret et du code environnant. Cela peut nécessiter l'aide du développeur impliqué pour :

• Supprimer le dépôt entièrement ou le rendre privé
• Réécrire l'historique git si techniquement faisable

attention

La suppression des preuves est optionnelle si le secret a été révoqué avec succès, puisqu'il ne peut plus être utilisé. Cependant, elle devient une action de mitigation nécessaire si le secret n'a pas pu être révoqué pour une raison quelconque.

3. Examiner les logs d'accès

Recherchez d'éventuels accès non autorisés :

• Vérifiez les logs pour détecter des activités suspectes utilisant les identifiants compromis
• Recherchez des preuves d'accès aux données, d'intrusion système ou de mouvement latéral
• Considérez que certains secrets donnent accès à d'autres secrets ou systèmes
• Prenez des actions de mitigation supplémentaires si vous découvrez d'autres expositions

Clôturer l'incident comme « Resolved »

Une fois les étapes de remédiation terminées, marquez l'incident avec le bouton « Resolved » et documentez votre raison en sélectionnant la ou les options appropriées :

• Repository made private or deleted
• DMCA takedown requested
• Secret revoked

Ignorer les incidents de secrets publics

Si votre investigation détermine qu'une fuite particulière n'a pas de lien avec votre entreprise ou ne présente aucun risque, vous pouvez clôturer l'incident comme « Ignored ».

Documentez la raison en sélectionnant la ou les options appropriées :

• Test credential
• Low risk secret
• False positive (not a secret)
• Developer not connected to the company
• Credential not related to the company