Politique de Réponse aux Incidents

1. Introduction

Ce document décrit la politique de réponse aux incidents pour l’application DeskCamera. DeskCamera est une application de diffusion d’écran installée localement, conçue pour fonctionner au sein du réseau local du client. Elle ne fournit aucun service cloud, ne stocke ni ne traite de données utilisateur et ne transmet aucun contenu en direct aux serveurs de DeskCamera.

2. Objectif

Garantir que DeskCamera dispose d’une approche structurée pour identifier, gérer et résoudre les incidents de sécurité susceptibles d’affecter le développement logiciel, la distribution ou l’infrastructure de support.

3. Portée

Couvre les incidents de sécurité liés au code source de DeskCamera, à la chaîne de compilation, aux dépendances tierces, aux systèmes de distribution et aux outils de développement internes.

4. Types d’incidents couverts

• Accès non autorisé aux dépôts de code
• Compromission des certificats de signature ou de l’environnement de build
• Vulnérabilités dans la chaîne d’approvisionnement (bibliothèques tierces)
• Mauvaises configurations affectant l’intégrité des installateurs distribués
• Vulnérabilités dans les outils utilisés pendant le cycle de développement logiciel (SDLC)

5. Rôles et responsabilités

• CTO – Supervise la gestion des incidents et approuve les mesures critiques
• Équipe de développement – Évalue les détails techniques, corrige le code et restaure les systèmes
• Responsable de la sécurité – Coordonne les enquêtes, maintient les journaux et assure la communication

6. Processus de gestion des incidents

6.1. Identification

• Surveillance automatisée des CVE (Common Vulnerabilities and Exposures) via des flux de sécurité
• Revues manuelles de code et détection d’anomalies lors des opérations de routine

6.2. Évaluation

• Classification selon la gravité (Critique, Élevée, Moyenne, Faible)
• Vérification de l’impact sur les logiciels distribués

6.3. Contention et atténuation

• Révocation immédiate des identifiants compromis
• Isolement des environnements ou pipelines affectés
• Suppression ou correction des bibliothèques tierces vulnérables

6.4. Rétablissement

• Restauration de l’environnement propre à partir de sauvegardes
• Re-signature des builds avec des clés vérifiées
• Re-tests et validation de l’intégrité des installateurs publiés

7. Communication

• Interne : Tous les incidents sont enregistrés et transmis à la direction
• Externe : Les clients sont informés dans les 24 heures uniquement si l’intégrité des builds ou des mécanismes de mise à jour est compromise

8. Revue post-incident

• Analyse de la cause racine sous 5 jours ouvrables
• Mise à jour des procédures de sécurité si nécessaire
• Le rapport d’incident est conservé en interne et utilisé lors des formations annuelles sur la sécurité

9. Revue et tests

• Cette politique est révisée chaque année par le CTO
• Des exercices internes de type tabletop sont réalisés périodiquement pour tester la réponse aux incidents