Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Comment Kroll Ontrack a récupéré des données sensibles de l’OTAN dans un abri antinucléaire

avril 2014 par Kroll Ontrack

Kroll Ontrack dévoile sur son blog une situation qui s’est produite il y a quelques années et dont l’entreprise peut désormais parler, d’autant que les leçons tirées à l’époque valent toujours aujourd’hui.

Situation

Kroll Ontrack a reçu un appel de l’agence OTAN d’information et de communication située près de La Haye, aux Pays-Bas. Suite à une panne d’un serveur Windows 2000, ils n’arrivaient pas à remettre en ligne le volume de données principal. Ce volume de données contenait l’unique exemplaire de documents logistiques importants qui étaient requis la semaine suivante pour un exercice majeur de l’OTAN. Le matériel serveur était une tour HP autonome équipée d’un boîtier de disque dur externe. Quatre disques durs SCSI avaient été configurés en RAID 5 à l’aide d’un contrôleur RAID monocanal Mylex. Le volume total des données ne dépassait probablement pas 98 Go. Le serveur avait été redémarré dans le cadre d’une mise à niveau de maintenance et deux des disques n’étaient pas repassés « en ligne ». Cette « remise en ligne » aurait pu être forcée, mais personne ne savait si les deux disques étaient tombés en panne en même temps. Il y avait une infime possibilité pour que le système RAID ait fonctionné en mode dégradé depuis un certain temps. Une autre possibilité était de forcer la mise en ligne d’un seul des disques, mais s’il s’agissait de celui qui était tombé en panne le premier, les anciennes données entraîneraient une altération, d’autant plus que l’exécution de FDisk risquait de provoquer encore plus de dégâts (FDisk était configuré pour s’exécuter automatiquement au démarrage du serveur).

Un autre aspect inhabituel de la situation est qu’il n’y avait pas de sauvegarde. En effet, en raison de la facilité à transporter une bande de sauvegarde, il avait été décidé que cela présentait un risque trop grand pour la sécurité, si bien qu’aucune sauvegarde n’était faite. Il avait également été décidé que la redondance du RAID 5 offrirait une protection suffisante des données.

Étant donné le niveau de sécurité des données, il était interdit de faire sortir le boîtier de disque dur du site et donc impossible de l’envoyer à l’un de nos laboratoires de récupération de données. Toute tentative de récupération de données devait donc être faite sur place dans l’enceinte protégée, sous bonne garde. L’endroit s’avéra être un abri antinucléaire souterrain, ce qui présentait quelques complications inattendues.

Pour empêcher que la sécurité de notre propre logiciel de récupération ne soit compromise, il faut un code de sécurité. Celui-ci est normalement obtenu via un appel téléphonique rapide passé au siège. Or, comme il s’agissait d’un lieu sécurisé, tous les téléphones mobiles avaient été confisqués avant l’entrée et tous les appels par téléphone fixe devaient être vérifiés et autorisés avant de pouvoir être passés. Chaque appel autorisé nécessitait la saisie d’un code à 12 chiffres, suivi du numéro de téléphone autorisé. La complication suivante était qu’à tout moment soit nous étions enfermés dans une zone sécurisée derrière une énorme porte blindée, soit nous devions être escortés en permanence, y compris aux sanitaires.

Récupération

Les données hexadécimales brutes ont été examinées sur chaque disque pour déterminer l’ordre des disques et le type de parité des données avant de créer un système RAID virtuel et de valider l’intégrité des données. Il s’est avéré qu’un des disques était tombé en panne à une date antérieure, de sorte que sa mise en ligne forcée aurait entraîné une altération généralisée. Le système RAID a été recréé à l’aide des trois autres disques et les fichiers récupérés ont été copiés sur un autre volume de données.

Leçons à retenir

Les responsables informatiques ont pris la décision consciente de ne pas réaliser de sauvegarde, du fait que l’évaluation du risque pour la sécurité dépassait de loin le risque de perte de données. Cette décision est valide tant que le niveau de risque est compris et accepté. Il est également possible qu’ils aient inclus une option de récupération de données dans leurs calculs.

Toutefois, lorsqu’une perte de données s’est bel et bien produite, il s’est avéré que le risque était inacceptable. Le temps nécessaire pour recréer les données était beaucoup plus long que le temps disponible pour respecter leurs délais. Il leur aurait certainement été possible de recréer les données dans le délai disponible, mais pour un coût supplémentaire considérable, alors que le coût de notre récupération était comparativement nettement inférieur. Sans doute que la réputation de quelqu’un était également en jeu.

D’après notre expérience à Kroll Ontrack, il est très rare que deux disques tombent simultanément en panne, mais cela se produit plus fréquemment après un redémarrage. Les contrôleurs RAID effectuent un autotest de mise sous tension (POST) et une partie du test consiste à vérifier que les disques sont lus correctement. Si le débit des données est inférieur aux spécifications, le POST peut échouer et il revient alors à l’utilisateur de décider s’il faut forcer la mise en ligne.


Voir les articles précédents

    

Voir les articles suivants