Dans le cadre de l’incendie du Datacentre OVH de Strasbourg le 10 mars 2021, qui a ébranlé les activités en France au moins, PiaLab a décidé de publier son expérience (dans la mesure où les informations communiquées ne compromettent pas son système d’information et sa protection des données), conformément aux bonnes pratiques en matière de sécurité de l’information (ISO27001 §5.1 et §7.4, ISO27701 §5.5.4 et §7.3.7) et dans un objectif de progression tant interne qu’externe.
Cette communication n’a pas prétention à présenter un idéal, mais à présenter les choses telles que PiaLab les a vécues et y a répondu, dans l’urgence de la gestion de crise, avec l’objectif toutefois d’inciter les lecteurs à se questionner sur la maîtrise de leurs propres risques, pour s’assurer que les mesures déployées sont suffisantes, et dans la négative, à s’y pencher pour y remédier.
Le présent document s’adresse aux personnes dont le métier est la prise en charge des risques et/ou du système d’information en organisation. Il se pourrait qu’un manque de connaissances dans ces domaines rende son contenu difficile à aborder.
Vos commentaires sont les bienvenus en bas de ce billet, faîtes-nous vos retours, partagez votre propre expérience.
Identification de l’incident
Chez OVH
Le mercredi 10 mars 2021 vers 1h du matin, un incendie se déclare dans le datacentre SBG2 d’OVH. L’ensemble des services de Strasbourg sont coupés et ne seront pas relancés dans des délais raisonnables. SBG2 est complètement détruit ainsi que un tiers de SBG1.
Nous disposons de serveurs identifiés « SBG3 » sur nos factures, sur lesquels reposent tous les services en production de PiaLab.
Notons que les datacentres d’OVH à Strasbourg sont nommés SBG1, SBG2, SBG3 et SBG4.
Chez PiaLab
Les processus critiques
Les processus critiques internes de l’entreprise sont globalement épargnés des flammes. En effet, les actifs supports liés (messagerie électronique, messagerie chiffrée et instantanée réservée aux communications d’urgence et fichiers de travail) ne sont pas touchés, ou peuvent fonctionner en mode dégradé sans interruption générale.
Les services de logiciel « SaaS » que PiaLab offre à ses clients (le logiciel éponyme de tenue du registre des traitements et des DPIA) sont quant à eux inaccessibles, pénalisant directement nos clients. Ces services sont classifiés « critiques ».
Les processus non-critiques
En dehors, entre autres, de la comptabilité et de la vente (non concernés par l’incident) plusieurs processus classifiés comme non critiques pour leur disponibilité sont inopérants : la gestion de projet, l’intranet, la messagerie instantanée courante, le site web, les registres réglementaires de protection des données.
Situation pour PiaLab
Au moment de l’incendie
La situation est très sérieuse et elle met au jour que :
- si l’appréciation des risques liés à l’information a envisagé une panne temporaire de l’ensemble du fournisseur OVH, elle n’a pas envisagé la destruction complète et définitive d’un datacentre;
- des dispositions en place dans le PCA (Plan de Continuité de l’Activité) permettent aux processus critiques de redémarrer dans les meilleurs délais
Un aléa d’une telle ampleur n’a donc pas été envisagé, mais nous disposons du nécessaire « pour repartir » et continuer nos activités, même en mode dégradé.
Constitution d’une équipe de gestion de crise
Une équipe de réponse à la crise a été constituée, avec une attention particulière dans la distinction des rôles opérationnels et stratégiques d’une part, et dans la complémentarité technique / organisationnel de l’équipe.
Cinématique de la gestion de crise
L’activité courante de l’entreprise continue de manière dégradée sans conséquence pour les clients et la qualité de nos services à date, dès le matin du 10 mars 2021.
Les clients impactés par la perte de disponibilité de notre système d’information sont informés sans délai, à partir de mercredi 10 mars à 10h30, une fois les dégâts constatés.
Les services critiques sont rétablis le vendredi 12 mars à 8h, et les clients informés.
Le système d’information est rétabli progressivement dès le 10 mars pour un retour à la normal en date du dimanche 21 mars à 18h. Cette reconstruction a été l’occasion de rationaliser les outils internes à l’organisation, d’élever le niveau d’exigence du système d’information en matière de sécurité et de fonctionnalités et d’aiguiser notre gestion des risques.
Des pertes définitives sont cependant à regretter : pour certains processus, du fait de leur défaut de classification, la politique de sauvegarde de leurs informations s’est avérée insuffisante. En effet, des sauvegardes sont déportées hors des composants de production, mais malheureusement sans considérer la nécessité de les transférer en dehors de la zone géographique de stockage initial (ici les équipements OVH de Strasbourg). Ainsi, c’est en particulier le processus de suivi de projet qui a été impacté, épargnant cependant les personnes physique de tout impact sur la protection de leurs données, ce risque ayant été couvert par la PSSI (Politique de Sécurité du Système d’Information) et le PRA (Plan de Reprise d’Activité) de PiaLab, sur la base de la politique de classification de l’information.
La présente communication est publiée environ 15 jours après l’incendie.
MISE À JOUR: Début avril 2021, nous récupérons les sauvegardes de nos processus moins critiques, en particulier la gestion de projet. Cela nous permet alors de rétablir des informations perdues dans les systèmes redéployés de zéro, et en particulier le suivi de temps (information stratégique pour organiser la société).
Analyse de la situation
Les processus critiques
Les services en ligne fournis à nos clients (ex: la tenue des registres des traitements et des DPIA) n’a pas souffert de la moindre perte d’information. Les bases de données étant répliquées en dehors de Strasbourg, pas un ajout, une modification ou une suppression n’a été perdue, jusqu’à la dernière seconde. Le retour à la normal du service aurait pu avoir lieu en moins de 18h, mais une mission particulièrement exigeante en cours a ralenti les opérations et les services ont été rétablis le vendredi 12 mars 2021 vers 8h, soit au bout de 30h environ. Quelques réglages du nouveau déploiement ont néanmoins pu perturber marginalement le service jusqu’au vendredi 19 mars 2021 17h.
Durant les opérations de maintenance, la chaîne de sécurité n’a jamais été rompue et nous avons profité de l’incident pour prendre de nouvelles mesures en matière de confidentialité et de capacités à reprendre l’activité après incident, de manière à être mieux préparés pour le prochain incident.
Une classification des actifs informationnels appropriée
Les processus classifiés « critiques » et leurs actifs supports font l’objet de mesures suffisantes et performantes.
Une approche différenciée des risques de perte de Disponibilité, Intégrité et Confidentialité serait un atout… car comme bien souvent notre attention s’est plus portée sur le risque de perte de confidentialité que sur celui de perte de disponibilité comme nous en avons fait l’expérience ici.
Des défauts
La situation a révélé plusieurs défauts, certains majeurs :
Certains processus sont identifiés comme « non critiques » alors que leurs usages le sont devenus
La classification des processus a été revue il y a 10 mois, mais l’activité a évolué sur la période. Ainsi à date de l’incident, la classification n’était plus parfaitement alignée avec les réalités métiers, entraînant des impacts plus importants que ceux anticipés. Par exemple le processus « Suivre les projets » a pris en importance et l’actif support (le logiciel lié) a vu ses fonctionnalités s’étendre au point d’y intégrer l’intranet de l’entreprise. Sa classification C1 (de moindre criticité) n’était donc plus suffisante et cela a entraîné un manque de mesures de sécurité, comme des sauvegardes non seulement déportées (c’était déjà le cas) mais déportées en dehors de son propre datacentre. Elle aurait dû ainsi être classifiée C2 ou C3, ce qui aurait entraîné une délocalisation nécessaire des informations en dehors d’un seul et même datacentre (ici Strasbourg).
Appréciation du risque d’incendie d’un datacentre complet
Le risque de destruction d’un datacentre complet n’avait pas été envisagé.
Cela combiné à une classification des processus partiellement obsolète, la situation n’est pas satisfaisante.
Des forces et des opportunités
La continuité de l’activité sur les processus critiques correctement classifiés a été possible et efficace. PiaLab dispose donc du savoir-faire nécessaire et sa politique de sécurité des systèmes d’information dispose déjà des mesures nécessaires pour atteindre un objectif de continuité des activités, même pour ce type d’aléa majeur.
La destruction d’une partie du système d’information est l’occasion de rehausser le niveau général de sécurité des données, de l’information et des processus métier, à la fois en matière de confidentialité, d’intégrité, de disponibilité et de traçabilité. Cet incident est une occasion unique pour PiaLab de requestionner ses outils, son infrastructure, ses stratégies de sauvegarde, et la classification de ses actifs.
Des impacts
Les informations perdues à ce jour ne sont pas critiques, elles ne sont la source d’aucun risque pour les personnes concernées (protection des données, RGPD art.33 et 34), mais elles entraînent des coûts pour l’entreprise de l’ordre de 2% du chiffre d’affaires, ce qui n’est bien sûr pas négligeable.
Évaluation
Dans les détails
Si la classification effective des processus n’a pas été suffisamment tenue à jour, ce qui aurait permis un retour à la normale plus rapide et moins de pertes d’information, les règles en matière de classification et les mesures subséquentes ont révélé à la fois leur importance et leur pertinence. Une telle défaillance ne doit pas se reproduire. pour ce faire, un revue régulière de la classification des processus doit être prévue, en intégrant également les changements externes au système d’information, comme les évolutions des usages.
L’incident a également été l’occasion de reprendre l’infrastructure du système d’information dans sa conception, pour des usages optimisés et une sécurité renforcée.
Le programme d’audit interne ne prévoyait pas d’audit avant l’incident, mais cela aurait peut-être mis en lumière le décalage entre les usages et la classification des actifs. C’est un facteur d’atténuation des risques, qui a manqué ici.
Globalement
Si les impacts (financiers, protection des données, …) d’un tel incident restent globalement modestes, l’incident est majeur pour PiaLab dans ce qu’il révèle de faiblesses et de forces, dans ce qu’il coûte moralement et en terme d’énergies à déployer. PiaLab doit immédiatement prendre toutes les mesures permettant de remédier à de tels incidents, et ce dans les coûts les meilleurs, de manière à en assurer la durabilité.
Plan d’actions
| Qui | Quoi | Pour quand |
| PiaLab | Prendre des mesures pour éviter tout décrochage entre la classification formelle des actifs de l’entreprise et les réalités métiers sous-jacentes, y compris sous une périodicité inférieure à 1 an; | court terme |
| PiaLab | Revoir la classification des processus et des informations dans l’entreprise; | court terme |
| PiaLab | Procéder à un audit global de l’entreprise, sur le référentiel des exigences de nos politiques internes, d’ici fin 2021; | 6 à 9 mois |
| PiaLab | Consolider les mesures techniques correctives permanentes de manière continue, en s’assurant de leur efficacité. | 3 à 6 mois |
