Sécurité des Mainframes, mythe ou réalité ?

Imaginons… Avec l’hiver qui joue les prolongations vous décidez de prendre quelques jours de vacances au soleil. Pour cela vous commencez par chercher sur le site de Météo-France une destination idyllique où il fait toujours beau. Une fois trouvée, vous décidez de réserver un billet d’avion pour vous y rendre en prenant soin auparavant de faire un virement sur votre compte courant pour éviter tout risque de découvert…

Derrière ce petit scénario, 3 opérations différentes (météo, réservation, virement) qui utilisent très vraisemblablement une même famille d’équipements pour répondre à vos besoins : le mainframe.

Très peu connues du grand public, ces machines informatiques sont présentes dans de nombreuses organisations et continuent d’attirer de nouveaux clients [1]. De par leur fiabilité et leur longévité, ces machines hébergent des informations critiques dans les entreprises où elles sont implantées, que ce soit des données RH (ex : fiches de paye), des données clients (ex : comptes bancaires ou historiques de transactions), ou encore des modèles de prévision statistique.

Ces gros systèmes [2], bénéficient d’une très bonne réputation au niveau de la sécurité et cela pour plusieurs raisons :

  • Ce sont des équipements centralisés accédés d’un point de vue informatique qu’au travers de terminaux émulés (ex : Quick3270) et dont les accès physiques sont très rares impliquant donc un contrôle d’accès facilité.
  • Ces systèmes sont peu connus, ils étaient également jusqu’à très récemment peu exposés au monde extérieur. Ils bénéficient donc d’une relative immunité face aux attaques classiques.
  • De plus, il existe une véritable philosophie de sécurité sur ces systèmes [3] et plusieurs solutions de gestion des habilitations et de contrôle des accès sont disponibles.[4]

Il est certain que les mainframes ont évolué au fil des années, cependant nombre de protocoles vieillissants et non chiffrés sont encore utilisés, FTP, TelNet, HTTP…
En plus de cette problématique, la mise en place de surcouches venant des mondes Windows ou Unix, compromet complètement la sécurité de ces mondes fermés.

Afin de s’adapter au monde actuel, ces systèmes historiquement déconnectés du monde extérieur doivent évoluer et embarquer de plus en plus d’interfaces Web.
La solution Virtel [5] permet par exemple de traduire des données brutes mainframe en données Web accessibles à partir d’un ordinateur comme d’un téléphone portable.

En parallèle, depuis l’arrivée de z/OS toutes les applications Unix sont potentiellement installables sur les mainframes [6]. Cela inclut par exemple un serveur apache hébergeant un CMS avec toutes les failles connues que cela implique….

Le plus ennuyeux dans cette histoire, est qu’il n’y a aucune contrainte technique à ces ouvertures car ces gros systèmes peuvent assumer une très grosse charge de traitement, cependant ces nouvelles améliorations apportent avec elles une multitude de menaces auxquelles les mainframes et surtout les administrateurs associés ne sont pas préparés.

Par exemple certaines attaques sur gros systèmes ont coûté très cher aux entreprises visées :

  • TJX : 46 millions d’enregistrements de cartes de crédit volés [7]
  • DuPont Kevlar : 400 millions de dollars de données volées par un employé [8]
  • Monster.com : 1.6 millions de données clients volées [9]

Les administrateurs actuels habitués à un fonctionnement interne n’ont pas forcément les réflexes de sécurité élémentaire pour des systèmes connectés et potentiellement accessibles par tous.

De plus au vu de ma propre expérience, la population des administrateurs et gestionnaires centraux est vieillissante. Les langages de développement de la majorité des programmes [10] (COBOL, Pacbase, assembleur…) ne sont plus enseignés dans les formations type Bac+3, Bac+5 et très peu de jeunes diplômés ont déjà entendu parler des mainframes lors qu’ils entrent sur le marché du travail.

Bien que les technologies soient différentes entre les mainframes et les serveurs type Windows ou Unix, les stratégies de protection restent très similaires [11] :

  • Sensibilisation : Il n’est pas utile que chaque utilisateur ait des notions de sécurité avancée, mais une politique de sécurité incomprise perdra beaucoup en efficacité. Ne pas donner son identifiant à un collègue, ne pas laisser traîner son portable d’astreinte sur une terrasse de café ou éviter l’utilisation de mots de passe triviaux (ex : 123456, JANVIER13) différents de 123456 ou janvier sont autant de bonnes pratiques que l’on ne répètera jamais assez…
  • Chiffrement : Il est acquis que le chiffrement des informations capitales (mots de passe, données bancaires, numéros de sécurité sociale, adresses mail) n’empêchera jamais le vol de données. Cependant si elles étaient récupérées, ces données ne seraient pas exploitables en l’état.
  • Journalisation : De nombreux équipements de sécurité embarquent par défaut des outils de journalisation interne. Que ce soient les actes effectués, les tentatives d’attaques ou encore les documents critiques accédés, il est capital de pouvoir visualiser ces informations sur une durée définie par la politique de sécurité.
  • Audit : Une fois que l’on pense avoir assuré la sécurité sur son SI, il ne faut pas avoir peur de faire appel à des spécialistes assermentés, neutres et non soumis à une potentielle pression hiérarchique afin de contrôler et valider son installation. Il est également important de prévoir un calendrier régulier de correction des potentielles failles et des contre-audits…

Nous sommes loin d’un no man’s land de la sécurité sur ces gros systèmes. Il existe un potentiel peu ou pas assez exploité de mon point de vue mais qui me fait me poser une question : La plus grosse vulnérabilité sur les mainframes n’est-elle pas cette sensation d’invulnérabilité surfaite qui ne permet pas de placer correctement ces équipements vitaux dans les analyses de risques ?


[1] En particulier dans les pays émergeants http://www.channelnews.fr/actu-societes/65/13489-ibm-lance-un-nouveau-mainframe.html

[2] Contrairement à d’autres : Windows, Linux ou Unix…

[3] On ne peut malheureusement pas en dire autant des systèmes SCADA ayant défrayés la chronique