Plan de réponse aux incidents

Date d'effet : 2 juin 2026

Le présent Plan de réponse aux incidents (« Plan ») définit la manière dont STANDOUT Inc. (« nous ») détecte les incidents de sécurité, les interruptions de service et les violations de données affectant le service VATES (« Service »), y répond, s'en rétablit et en tire des enseignements. Le Plan se réfère à NIST SP 800-61 Rev.2 et à ISO/IEC 27035, et repose sur le principe de conception selon lequel les instruments de surveillance automatisés constituent la première ligne de détection.

1. Objet et champ d'application

Les objectifs du présent Plan sont :

• Détecter en temps utile les événements susceptibles d'affecter la disponibilité, la confidentialité ou l'intégrité du Service.
• Définir des procédures de confinement et de rétablissement qui minimisent l'impact.
• Respecter les obligations de notification envers les Clients affectés et les autorités réglementaires.
• Permettre l'amélioration continue de la qualité opérationnelle par une analyse post-incident structurée.

Le présent Plan s'applique à l'environnement de production du Service (EC2, Cloudflare et prestataires SaaS associés), au chemin de communication du Service vers les fournisseurs IA en amont, et à tous les stockages contenant des données du Client.

2. Définition de l'incident et classification de gravité

2.1 Définition d'un incident

Aux fins du présent Plan, un incident est tout événement correspondant à un ou plusieurs des éléments suivants :

• Suspicion d'accès non autorisé, de compromission d'identifiants ou d'intrusion système.
• Divulgation, altération ou perte non autorisée de données du Client, y compris de données personnelles.
• Panne ou dégradation significative des performances affectant les fonctionnalités essentielles du Service.
• Menaces de sécurité, y compris infection par maliciel, rançongiciel, ou attaques de la chaîne d'approvisionnement.
• Erreur opérationnelle, mauvaise configuration ou défaut logiciel entraînant un impact à grande échelle.

2.2 Classification de gravité

Chaque incident est classé au moment de la détection dans l'un des niveaux de gravité suivants :

• P1 (Critique) : Panne totale du Service, ou violation de données confirmée impliquant des données personnelles. Nécessite une réponse immédiate.
• P2 (Élevé) : Altération significative des fonctionnalités essentielles, indisponibilité pour des Clients spécifiques, ou anomalies d'authentification. Réponse initiale requise dans l'heure.
• P3 (Moyen) : Altération fonctionnelle partielle ou dégradation des performances avec des solutions de contournement disponibles. Une réponse pendant les heures ouvrées est acceptable.
• P4 (Faible) : Événements à impact utilisateur limité, dérive mineure de l'intégrité des journaux, ou redondance réduite des instruments de surveillance. Traités lors du prochain cycle de revue planifié.

3. Structure de réponse

3.1 Partie responsable

La partie responsable du présent Plan est Takuya Aoki, Managing Director de STANDOUT Inc. et responsable du développement de VATES. Tout pouvoir de décision et tout pouvoir de notification externe pendant un incident sont consolidés au sein de la partie responsable.

3.2 Instruments de détection automatisés

Le Service exploite une posture de surveillance continue entièrement automatisée composée des instruments suivants. Ils fonctionnent indépendamment de la partie responsable et déclenchent une notification immédiate dès que les conditions de seuil sont atteintes.

• Cloudflare Health Check : Sonde l'origine de production depuis plusieurs points d'observation géographiques à intervalles de 60 secondes.
• HetrixTools : Surveille les endpoints de production depuis plusieurs points d'observation mondiaux par un chemin indépendant de Cloudflare.
• Sentry : Capture les exceptions applicatives en temps réel et notifie la partie responsable.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset) : Bloque les schémas d'attaque connus en mode Block.
• Cloudflare DDoS Protection : Atténue en continu et automatiquement les attaques DDoS au niveau de la couche réseau, de la couche SSL/TLS et de la couche HTTP.
• Batch de détection d'anomalies (systemd timer) : Analyse les journaux d'audit toutes les cinq minutes et détecte trois catégories : taux de requêtes élevé, taux de refus d'autorisation élevé, et tentatives par force brute.
• Limitation de débit : Limitation de débit par tenant sur les endpoints d'usage et limitation fondée sur l'IP sur les endpoints d'authentification, rejetant automatiquement le trafic excédentaire.
• Alertes de sécurité configurables : Les Clients peuvent choisir quels événements opérationnels (solde bas, connexion depuis un nouvel emplacement, accès bloqué, échecs de connexion répétés) déclenchent des notifications par e-mail, avec des seuils de sensibilité par événement.
• Infrastructure de journal d'audit : Enregistre chaque appel d'API dans un journal d'audit infalsifiable à chaîne de hachage (SHA-256, séquence par tenant) et consolide les entrées pour une vérification indépendante.
• Tableau de bord d'état (9 pastilles de santé) : Visualise sur un seul écran l'audit, les anomalies, le GeoIP, les sauvegardes, le batch de suppression, la couverture du catalogue, la dérive de réconciliation, le killswitch et la santé du service.
• Sauvegarde automatisée : Chiffre les instantanés SQLite avec GPG AES-256 et conserve 30 générations quotidiennes.

3.3 Délégation de la réponse de première ligne à l'automatisation

Les étapes de détection et de tri sont assurées par les instruments automatisés ci-dessus en tant que première ligne. La partie responsable n'intervient qu'à réception de notifications dépassant les seuils. Cette conception garantit qu'une couverture de détection 24/7 est physiquement établie, sans dépendre de l'emplacement ou de la disponibilité de la partie responsable.

4. Processus de réponse

4.1 Détection

Lorsqu'un ou plusieurs des instruments automatisés décrits à la section 3.2 détectent une anomalie, la partie responsable est immédiatement notifiée via Sentry, e-mail et alertes du tableau de bord. Les signalements des Clients sont reçus à [email protected] et enregistrés sous forme de ticket dans le même flux.

4.2 Tri

À réception d'une notification, la partie responsable confirme la gravité en examinant :

• L'étendue de l'impact (tous les Clients / Client spécifique / Instance individuelle).
• Si des données personnelles, des identifiants d'authentification ou des informations de facturation sont affectés.
• L'implication de facteurs externes (pannes des fournisseurs IA en amont, pannes Cloudflare, pannes AWS).
• La corrélation avec des schémas d'attaque connus (journaux WAF, résultats de détection d'anomalies, alertes GeoIP).

4.3 Confinement

Selon la gravité, une ou plusieurs des mesures de confinement suivantes sont appliquées :

• Suspension des Instances affectées via la machine à états pour un isolement immédiat.
• Ajout des adresses IP sources à une liste de refus (par Client ou globale).
• Révocation de session en masse par JWT jti.
• Activation du killswitch (arrêt total du trafic, mesure de dernier recours).
• Activation du « Under Attack Mode » de Cloudflare contre les attaques L7.

4.4 Rétablissement

Après confinement, les causes profondes sont éliminées et les actions suivantes sont menées :

• Restauration à partir d'une sauvegarde selon les besoins (procédures documentées dans docs/RESTORE.md).
• Rotation des identifiants affectés (clés API, secrets JWT, clés de chiffrement des sauvegardes, etc.).
• Application de correctifs, de corrections de configuration et de corrections de code en production.
• Vérification sur les environnements de staging et de production.
• Observation continue pendant au moins 24 heures via les instruments de surveillance.

4.5 Post-incident

Après confirmation du rétablissement, la partie responsable :

• Documente la chronologie, la cause profonde, l'étendue de l'impact et les actions de réponse.
• Identifie les mesures préventives et les intègre à la feuille de route de mise en œuvre.
• Le cas échéant, notifie les Clients affectés et les autorités réglementaires (voir section 5).
• Réinjecte les améliorations dans le présent Plan et les documents opérationnels associés.

5. Notification des Clients et des autorités réglementaires

5.1 Notification de violation de données personnelles

Si une acquisition, une perte ou une divulgation non autorisée de données personnelles est confirmée, nous fournissons une notification conformément à :

• Règlement général sur la protection des données de l'UE (RGPD) article 33 : Notification à l'autorité de contrôle dans les 72 heures suivant la prise de connaissance.
• RGPD article 34 : Lorsqu'un risque élevé est identifié, notification aux personnes concernées affectées sans retard injustifié.
• Loi sur la protection des informations personnelles (Japon) : Signalement à la Commission de protection des informations personnelles et notification aux personnes concernées, conformément aux ordonnances et règles applicables.
• Autres juridictions applicables : Notifications requises par les lois nationales ou régionales applicables en matière de protection des données.

5.2 Notification d'interruption de service

Pour les interruptions de service classées P1 ou P2, nous notifions les Clients affectés sans retard injustifié, en indiquant le délai de rétablissement attendu et toute mesure d'atténuation provisoire. Les canaux de notification sont [email protected] et la console d'administration du Service.

5.3 Méthode de notification

Les notifications sont délivrées principalement par e-mail à l'adresse enregistrée du Client, complétées si besoin par des bannières dans la console d'administration.

6. Post-mortem et cycle d'apprentissage

À la suite d'un incident P1 ou P2, la partie responsable effectue un Post-mortem et documente les éléments suivants. Le document est conservé en interne et communiqué aux Clients et aux auditeurs sur demande.

• Chronologie des événements, de la détection au rétablissement.
• Analyse des causes profondes (facteurs techniques et opérationnels).
• Étendue quantifiée de l'impact.
• Évaluation du processus de réponse.
• Mesures préventives et échéances cibles.

Les Post-mortems sont menés en tant que Post-mortems sans reproche (Blameless Post-Mortems), axés sur l'amélioration structurelle plutôt que sur la responsabilité individuelle.

7. Maintenance et revue du Plan

7.1 Revue périodique

Le présent Plan est revu au moins une fois par an, ainsi qu'après tout incident significatif, lors de changements importants de l'architecture du Service, et lors de modifications des lois et réglementations applicables.

7.2 Historique des révisions

L'historique des révisions du présent Plan est conservé en interne et communiqué aux Clients et aux auditeurs sur demande.

8. Contact

Pour signaler un incident ou pour toute question concernant le présent Plan :

STANDOUT Inc.
E-mail : [email protected]

Dernière mise à jour : 2 juin 2026