Kaspersky Lab est-il en train de développer son propre Système d’Exploitation? Confirmation des rumeurs et fin des spéculations !

Bonjour à tous !

Aujourd’hui je veux vous parler du futur : un futur par très glamour avec des cyber-attaques massives visant des installations nucléaires, des centrales électriques, des centres de transport, des structures financières et de télécommunications, ou, ce que nous appelons globalement des installations critiques. Pour vous faire une idée, rappelez-vous du film Die Hard 4 : retour en enfer, où une attaque portée à des infrastructures plongeait le monde entier dans le chaos.

Mais cette fois-ci, John McClane n’est pas là pour résoudre le problème de vulnérabilité des systèmes industriels. Et même si c’était le cas, ses méthodes ne fonctionneraient pas. Cependant, nous sommes en train de travailler sur le développement technologique d’un système d’exploitation fiable qui a pour objectif de protéger ces systèmes IT si critiques, (des systèmes de contrôle industriel (ICS)). Il y a déjà eu quelques rumeurs à ce sujet sur Internet, je pense donc qu’il est temps de lever le rideau (un peu) sur notre projet secret et de partager avec vous ce que nousavons entre nos mains.

Mais, tout d’abord, je vais vous parler un peu des systèmes industriels vulnérables et du réel besoin qu’à le monde de posséder notre approche nouvelle et différente.

Les Systèmes Industriels en total manque de défense

Bien que les systèmes industriels informatiques –les typiques réseaux d’entreprises- peuvent sembler très similaires dans certains aspects; ce sont en réalité des bêtes bien différentes –spécialement en terme de priorités entre sécurité et usabilité. Dans la plupart des sociétés, la confidentialité des données est considérée comme le plus important. Par exemple, si le serveur de la société détecte un trojan, la chose la plus simple à faire est de déconnecter le système infecté du réseau et, commencer à résoudre le problème ultérieurement.

Dans les systèmes industriels on ne peut pas faire cela, car leur priorité est de maintenir les opérations contre vents et marées. Maintenir la production de manière ininterrompue revêt une importance vitale tout comme l’objectif industriel à l’échelle globale. Pour cette raison, la sécurité à toujours été reléguée au second plan.

Ceci veut dire que le logiciel d’une installation industrielle ou d’une infrastructure ne met à jour qu’après une vérification exhaustive de la tolérance des failles, en s’assurant de ne pas interrompre la chaîne de travail. Et étant donné que cette vérification requiert un effort considérable (sans assurer totalement qu’il n’y ait pas de failles), beaucoup de sociétés ne se soucient tout simplement pas d’actualiser les ICS (et les ont laissé dans cet état durant des décennies). J’ai récemment lu un bon article sur ce sujet, lequel montrait une liste de 11 règles de sécurité ICS. Règle nº 1 : « Ne jamais rien toucher ».  Que puis-je vous dire de plus ?
La mise à jour du logiciel peut être interdite, expressément, dans la politique de sécurité des organisations industrielles ou des infrastructures. Même s’il existait une possibilité de mettre à jour le logiciel et de colmater les « brèches », cela ne servirait à rien. Les fabricants de logiciel spécialisés ne sont pas intéressés par l’analyse permanente de codes source ni par le colmatage des brèches. Et comme l’expérience nous le montre, les coûts se réduisent dans ce genre d’activités, et on applique des correctifs seulement si des exploits sont découverts, et ils sont publiés sur Internet. De fait, cela n’arrive pas qu’avec les logiciels spécialisés, c’est plus bien courant que qu’il n’y paraît. Néanmoins, le sujet du jour est le logiciel spécialisé pour l’industrie.

Le problème est le suivant : les points vulnérables du logiciel de contrôle, des contrôleurs programmés et des réseaux de communication industriels incluent le fait que les opérateurs de systèmes industriels et d’infrastructures ne peuvent recevoir une information fiable de toutes les opérations du système. Théoriquement, voilà ce qui pourrait arriver : si un système de distribution électrique était attaqué, une autre installation pourrait s’arrêter à l’autre bout du monde. En revanche, le centre de contrôle n’en aurait pas connaissance : les attaqueurs ont envoyé de fausses données à leurs ordinateurs.

Exemples

il n’est pas nécessaire de chercher bien loin pour trouver des exemples, car cela a déjà lieu dans la vie réelle. La première méthode utilisée –un exemple de cyber-sabotage et des dangers potentiels- fut une attaque des systèmes SCADA en 2000, en Australie. L’employer d’un sous-traitant qui travaillait sur le système de contrôle du comté de Maroochy a réussi, en 46 attaques (!!) à faire que les bombes à eau arrêtent de fonctionner ou ne fonctionnent pas correctement. Personne ne comprenait ce qu’il se passait –il y avait une faille dans les communications du système. C’est seulement plusieurs mois après que les sociétés et les autorités réussirent à savoir ce qu’il s’était passé : l’employer en question voulait travailler dans l’entreprise de traitement des eaux et, ne l’ayant pas réussi, il décida d’inonder le système de bouches d’égout de toute la région du Queensland.

Il existe une multitude d’exemples, mais les médias ne les diffusent tout simplement pas. Après tout, les compagnies victimes de ces attaques ne veulent pas que tout le monde sache que leurs systèmes sont vulnérables (je garde le sujet des intérêts publics pour un autre article, un autre jour…). Dans de nombreux cas, les victimes ne savent même pas qu’elles ont été attaquées. Récemment, les routeurs industriels de Ruggedcom ont connu unefaille qui permettait à l’utilisateur lambda d’augmenter son accès jusqu’au statut d’administrateur et de prendre le contrôle du dispositif. De plus, nous ne pouvons pas être sûrs de qui, quand, comment et où la faille a été exploitée. Et il existe d’autres failles similaires qui sont en train d’être exploitées… c’est juste une supposition.

Pour en connaître davantage sur ce sujet, je vous recommande de lire les attaques dans les ICS qui ont atteint leur objectif (à lire ici).
Qui mis à part les maîtres chanteurs ou les candidats en colère peut accéder au code source du logiciel ICS, aux contrôleurs, aux systèmes d’exploitation et autres dispositifs similaires ? Les autorités officielles, évidemment. Concrètement celles du département chargé de certifier le logiciel pour les systèmes hautement importants, mais aussi d’autres départements –celui (ces dernières années) qui développe des armes cybernétiques contre les systèmes des attaqueurs (qui sont, normalement, d’autres pays).

Exactement ! Je fais référence à des choses telles que Stuxnet et autres Duqu, Flame et Gauss –un logiciel malveillant si complexe qu’il est évident qu’il a été développé par une nation. Nous ne sommes pas vraiment intéressés par leur objectif : ce qui nous intéresse c’est de savoir si ces armes cybernétiques ont été complètement développées et utilisées. Une fois que la Boîte de Pandore a été ouverte, il est impossible de la refermer. La création d’armements pour les attaques visant des systèmes industriels et des infrastructures provenant d’ennemis, nous affectera tôt ou tard. C’est pourquoi, aujourd’hui, la plus grande menace pour la planète ne vient pas des « racailles » banales et courantes, ni même des cybercriminels organisés, sinon des créateurs d’armes cybernétiques qui ont l’appui de l’Etat.

La Protection actuelle n’est pas efficace

Au même moment que les armes sont fournies, les compagnies d’infrastructures tout comme les autorités n’oublient pas de se protéger. De fait, elles ont commencé par se protéger il y a bien longtemps. Mais, comment font-elles ?

Il n’existe que deux méthodes. La première consiste à isoler les objectifs critiques importants : les déconnecter d’Internet ou les isoler physiquement du mode extérieur d’une manière ou d’une autre. Cependant, comme le temps nous le prouve, si un technicien, au cours de sa garde de nuit, veut regarder des films sur les ordinateurs de contrôle depuis une clé USB infectée –il est impossible d’arrêter le processus (il existe des méthodes pour les bloquer, mais nous ne parlerons pas de cela maintenant).

La seconde méthode : garder le secret. Les développeurs d’ICS gardent le code source secret. Les propriétaires d’usines et d’industries apposent le tampon « SECRET » sur les schémas des systèmes d’information et de contrôle, les logiciels utilisés sont maintenus secrets, etc. Néanmoins, au même moment, l’information concernant les points vulnérables de la plupart des systèmes SCADA est disponible sur Internet. Si nous creusons davantage, nous apprenons que durant de nombreuses années le moteur de recherche ouvert SHODAN a fonctionné –conçu, entre autre, pour chercher des systèmes industriels vulnérables (y compris SCADA) dont les propriétaires ont décidé de les connecter –ou ont oublié de les déconnecter- à Internet.

Parallèlement, les spécialistes en organisations industrielles et en infrastructure utilisent aussi les méthodes traditionnelles de protection de logiciels vulnérables et de systèmes d’exploitation à travers le contrôle de l’utilisation de programme et les actions des utilisateurs. Une protection à 100% ne peut être garantie, à cause des points vulnérables par défaut du logiciel quand un contrôle est réalisé. Ce dont nous avons le plus besoin, c’est de trouver une garantie pour les infrastructures critiques.

La Protection telle qu’elle devrait être

Tout le logiciel ICS devrait être réécrit, en incorporant les technologies de sécurité existantes et en tenant compte de l’état actuel des attaques cybernétiques. Malheureusement, ce grand effort, qui demanderait un investissement considérable pour être soutenu et adapté, ne serait pas une garantie suffisante pour le bon fonctionnement des systèmes.

En revanche, il existe une alternative à notre portée : un système d’exploitation fiable, qui peut s’installer dans les ICS et qui pourrait s’introduire dans l’infrastructure existante –en contrôlant les systèmes « sains » actuels, et en garantissant des rapports de données fiables dans les opérations des systèmes.

Avant tout, je vais répondre à la question la plus évidente : comment est-il possible que Kaspersky Lab puisse créer un système d’exploitation fiable quand ni Microsoft ou Apple n’en ont été capables ?
C’est vraiment très simple !
Premièrement : notre système est spécialement conçu et développé pour résoudre des tâches spécifiques et non pour jouer au jeu vidéo Half-Life, éditer des vidéos de vos vacances ou discuter sur les réseaux sociaux.

Deuxièmement : nous travaillons sur des méthodes d’écriture de logiciel, lesquelles, par conception, ne mènent pas à terme des actions secrètes. C’est la partie la plus importante : dans notre système d’exploitation il n’est pas possible d’exécuter un code source tiers, de faire irruption dans le système ou d’installer des applications non autorisées. Et cela peut être vérifié et démontré.

Si vous voulez en savoir plus sur le système, ses conditions, son background et son développement, vous pouvez trouver ces informations ici.

Pour conclure et anticiper la multitude de questions de mes collègues, de mes associés, des médias et des curieux : le développement est un environnement vraiment fiable. C’est un projet sophistiqué et quasi impossible à réaliser sans la collaboration d’opérateurs et fournisseurs ICS. Pour des raisons de confidentialité avec nos collaborateurs, actuellement nous ne pouvons pas vous révéler trop de détails sur le projet. De plus, je ne veux pas donner davantage de pistes à nos concurrents sur notre bon savoir-faire. Qui plus est, il y a des détails qui resteront toujours éloignés des yeux de certains clients afin d’éviter les abus des cyber-terroristes. Néanmoins, dès que j’en aurai la possibilité, je vous donnerez plus de détails.

A la prochaine !