Assurance cybersécurité : les défis à surmonter et cinq astuces pour un futur connecté plus sûr

En 2015, une attaque réussie contre le réseau électrique Ukrainien a entraîné une panne générale, laissant environ 230 000 habitants sans électricité, plongés dans le noir et le froid au beau milieu de l’hiver. Cette attaque était l’aboutissement de longs mois de préparation, de planification et d’organisation. Bien que le courant ait été restauré dans les six heures, les centres de contrôle n’étaient toujours pas pleinement opérationnels après plus de deux mois.

Aujourd’hui, les menaces et attaques de cybersécurité les plus risquées ne viennent pas d’hackers génies de l’informatique qui œuvrent à petite échelle, depuis un garage. Il s’agit au contraire de grandes équipes d’experts bien informés, parfaitement organisés, bien établis, et parfois même d’organisations gouvernementales qui mettent au point des attaques très sophistiquées et très ciblées.

En parallèle, les infrastructures fondamentales telles que les réseaux électriques, les institutions financières et les réseaux gouvernementaux dépendent toutes de plus en plus des systèmes IT. Pour entrer dans la nouvelle ère de virtualisation et d’infrastructures cloud en toute confiance et pour maintenir le bon fonctionnement de nos industries et de nos pays, il nous faut des mesures de sécurité de pointe, qui soient au moins aussi avancées que les technologies qu’elles protègent. Pour cela, il nous faut définir les exigences des assurances cybersécurité.

Qu’est-ce qu’une assurance cybersécurité ?

L’assurance cybersécurité est un processus qui permet d’identifier de potentiels risques sous-jacents associés à certains produits, logiciels, ou services. Elle peut certifier que tel produit ou service répond à un certain degré de sécurité, selon les normes données ou selon les circonstances. Il existe de nombreux outils, techniques, et mesures de cybersécurité disponibles. L’un des plus communs est le Critère commun pour l’évaluation des outils des technologies de l’information, autrement appelé Common Criteria (CC). Le CC repose sur une échelle d’évaluation du degré d’assurance de plus en plus précise, et confronte le degré d’assurance et son coût et la praticabilité de son acquisition.

Aucun test de vulnérabilité ne peut prouver qu’un système est infaillible, mais peut seulement garantir qu’il est protégé (ou non) contre les attaques soumises lors du test. De la même manière, l’assurance cybersécurité ne peut pas garantir qu’un produit est entièrement exempts de risques ; mais, si elle est correctement mise en place, elle peut fournir un socle solide et fiable qui le protège jusqu’à un certain point.

Il faut prendre en compte deux aspects de l’assurance cybersécurité : le développement et l’évaluation. Le développeur doit concevoir son produit en songeant à sa sécurité, puis, l’évaluateur doit le tester. Nombreux pensent à tort qu’un évaluateur peut lui-même sécuriser un produit. Un sommelier ne rend pas le vin meilleur, il ne fait que le goûter. Il peut juger de sa qualité, mais ne peut pas changer la façon dont il a été produit. C’est là l’un des enjeux majeurs de l’assurance cybersécurité.

Un processus, deux mondes

La collaboration entre le développement et l’évaluation (deux sphères distinctes, qui, à l’heure où cet article est publié, ne communiquent pas comme elles le devraient) est la condition sine qua non d’une assurance cybersécurité efficace. De nombreux fournisseurs développent et assurent la maintenance de leurs produits de manière sécurisée, et font un excellent travail en matière de tests, d’analyse de la couverture des tests, et de respect des principes de sécurité. Mais ces efforts ne sont pas reconnus, et sont souvent déconsidérés par les personnes en charge de la vérification, soit parce que la conception n’est pas prise en compte dans les critères d’évaluation, soit parce qu’elle n’a pas été détaillée dans les documents servant à l’évaluation.

Penchons-nous par exemple sur les principes de la conception sécurisée. Elle requiert des privilèges, une isolation, une séparation, différents domaines de sécurité, un environnement d’exécution sécurisé, autant d’éléments qui contribuent fortement à son succès. Mais ces critères ne sont par exemple pris en compte qu’au niveau cinq de l’échelle d’évaluation du CC. Du niveau un au niveau quatre, la manière dont est conçu le produit importe peu. Pourtant, une fois que le produit est construit, il est bien plus difficile, si ce n’est impossible, de modifier la manière dont il a été conçu.

A l’inverse, lorsqu’un fournisseur demande l’évaluation d’un produit, il n’est pas rare d’entendre dire « Nous avons conçu notre produit conformément aux Common Criteria ». Toutefois le CC n’est pas une méthode de conception, mais de vérification. Ainsi, la notion d’assurance et la façon dont elle est comprise sont souvent distinctes, chacune dans leur monde.

Test de conformité vs analyse de sécurité

Il existe un second clivage qu’il nous faut dépasser, entre les deux approches de l’assurance sécurité : l’analyse de sécurité et les tests de conformité. Aux États-Unis, les fournisseurs accordent beaucoup d’importance aux tests de conformité, ainsi, des normes telles que FIPS 140 (utilisée pour les modules crypto) se focalisent dessus. Bien sûr, des évaluations de vulnérabilité peuvent être effectuées en parallèle, mais elles sont souvent très limitées. Les tests de conformité sont souvent plus objectifs et donnent des résultats très détaillés, mais sont cependant moins flexibles vis-à-vis des types de produits et de leurs fonctionnalités.

Les normes telles que le CC garantissent, elles, des analyses de sécurité plus ouvertes. Elles permettent de vérifier l’absence de vulnérabilités exploitables grâce à une recherche active de vulnérabilité, et permettent d’analyser, le cas échéant, les vulnérabilités identifiées. Cette approche permet plus de flexibilité, mais requiert plus d’informations de la part du fournisseur, et plus de compétences pour l’évaluateur. La norme CC en elle-même ne donne pas les exigences spécifiques à l’évaluation, elle doit toujours être complétée par des Profils de protection et des Cibles de sécurité. Toutes les évaluations CC menées aux États-Unis reposent sur des Profils de protection certifiés NIAP, qui ne prennent en compte que les tests de conformité.

Avec les exigences gouvernementales en termes de conformité, les personnes qui mettent en place ces normes ont souvent une expérience de développement datée. Il se peut qu’elles ne sachent pas ce qui est possible et ce qui est en vigueur à l’heure actuelle, ainsi, les normes risquent-elles d’être limitées et de borner l’innovation. D’autre part, une approche flexible et ouverte rend difficile pour un fournisseur de trouver de bons développeurs, qui comprennent suffisamment la sécurité, et requiert un personnel très entraîné pour que l’évaluation soit mise en œuvre.

Il n’existe pas de solution simple. Comme le dit H.L Mencken, auteur et journaliste « À chaque problème complexe, il y a une solution simple. Et c’est toujours une mauvaise solution. »

Comment faire, dès lors, pour améliorer l’assurance cybersécurité et préparer nos systèmes aux menaces futures ?

Conseil 1 : Adopter une approche équilibrée/Trouver le juste équilibre

Comme nous l’avons montré, un développement sécurisé associé à la maintenance des produits donne aux organisations de vrais outils pour garantir la sécurité du produit. Cette combinaison devrait être prise en compte lors de l’évaluation, et offrirait une approche davantage intégrée et holistique. Les mesures d’assurance tout au long du cycle de développement devraient être plus reconnues, et les évaluations devraient prôner l’assurance de ce développement.

Dans le domaine des réseaux mobiles, les exigences règlementaires en matière d’assurance cybersécurité pour la 5G ont entraîné une normalisation des spécifications. Le Projet d’assurance cybersécurité des équipements de réseau (NESAS) est une structure d’assurance cybersécurité à l’échelle du secteur développée par 3GPP et GSMA. Il définit les exigences en termes de cybersécurité et offre un cadre d’évaluation pour un développement sécurisé de produits et des processus liés au cycle de vie des produits sécurisés et qui aussi repose sur des tests de sécurité précis pour mesurer la sécurité des équipements, qui, lui-même repose sur des tests de sécurité précis pour mesurer la sécurité des équipements.

Ce cadre pourrait se poser comme référence pour l’assurance cybersécurité en général, dans la mesure où il prend non seulement en compte le produit fini, mais aussi la conception de ce dernier dans ses critères. Il nous faut alors trouver une solution pour optimiser et trouver un équilibre entre le degré d’assurance et l’efficacité dans le développement et l’évaluation des produits, en identifiant quels sont les degrés requis, et en prenant en compte les niveaux de risques impliqués dans les systèmes ou infrastructures auxquels se prédispose le produit.

Le Projet d’assurance cybersécurité des équipements de réseau (NESAS) est un programme bénévole destiné aux équipements de réseau conçus pour prendre en charge des mesures 3GPP prédéfinies.

Conseil 2 : Collaborer et communiquer en toute transparence

Afin d’adopter une approche équilibrée telle que nous l’avons précédemment décrite, il faut former les développeurs et évaluateurs et les pousser à communiquer davantage, de sorte qu’ils se comprennent mieux et travaillent main dans la main à l’optimisation du procédé. Les ingénieurs logiciels conçoivent souvent des logiciels multi couches très complexes, par conséquent, les évaluateurs ayant peu ou pas d’expérience de développement partent avec un handicap pour évaluer la valeur des contributions des développeurs. Cependant, il est important de garder à l’esprit que les exigences comme l’expertise du développement ajoutent un coût supplémentaire à l’évaluation de l’assurance.

Qu’importe l’approche adoptée, il est tout de même nécessaire que les développeurs soient transparents et communiquent lors de l’évaluation : il faut dire à l’évaluateur ce qui a été réalisé et comment. Il ne s’agit pas de créer une réalité alternative pour l’évaluation, car si les évaluateurs proposent des solutions d’amélioration, ils veulent améliorer les vrais produits, et non les produits imaginaires qui ont été créés spécialement pour l’audit.

Si l’assurance cybersécurité adopte une approche plus holistique, il faut alors trouver un compromis qui satisfasse les besoins des développeurs et des évaluateurs, mais qui reste rentable et efficace. Il nous faut pour cela clarifier les rôles et responsabilités au sein de ce processus. En effet, pour l’instant, une confusion demeure quant à la répartition des tests et des analyses de vulnérabilité. Mais ces derniers doivent tous deux être inclus dans le procédé général, même s’ils y jouent des rôles différents.

Conseil 3 : Se préparer à la complexité et à la diversité des couches sécurité

Les cybers terroristes de pointe auxquels nous sommes confrontés de nos jours tentent en permanence d’introduire des vulnérabilités ou des malwares au sein des supply chains. Malheureusement, de nombreuses entreprises ne mettent pas suffisamment l’accent sur la sécurité des supply chains. S’il n’est pas rentable pour elles de monter leur propre supply chain pour les systèmes complexes, la confier à des composants ou logiciels tiers se pose comme une solution intéressante dans la mesure où la diversité peut être un gage de sécurité. Il n’est guère conseillé de confier l’ensemble de ses données à un seul service ou composant, mais plutôt de les dispatcher en combinant différentes couches de sécurités émanant de différents fournisseurs ou pays (un aux Etats-Unis, un en Chine par exemple) afin de jouir d’une sécurité plus élevée.  Pour que votre système soit piraté, il faut d’abord que ceux-ci communiquent, ce qui est peu probable.

Il en va de même pour le cryptage, pour lesquels des produits commerciaux peuvent même être utilisés dans les systèmes classifiés en combinant les différentes couches, par exemple en associant une couche SSH et une couche TLS. Il existe aujourd’hui une monoculture SSL ouverte, une monoculture Windows, et les navigateurs eux-mêmes disposent plus ou moins du même moteur central. C’est-à-dire qu’ils partagent les mêmes vulnérabilités : si l’un d’eux est hacké, ils le sont tous, et le problème change d’échelle. La conception de systèmes avec des couches combinées se pose comme une alternative intéressante. Le système peut être fiable jusqu’à un certain point, mais il faut ensuite le doter d’un service supplémentaire qui ajoute de nouvelles fonctionnalités complexes. Cela allège le travail de l’assurance, d’une part, et, d’autre part, les solutions sont plus facilement et plus rapidement disponibles, dans la mesure où il s’agit de produits commerciaux.

Avec les technologies émergentes, telles que le cloud et la virtualisation (qui risquent de se généraliser sous l’influence de la 5G), les applications peuvent désormais fonctionner dans un cloud, en périphérie, depuis le centre de données principal, ou peuvent fonctionner sur tous ces supports à la fois. Le contrôle n’en sera plus que dilué, aura un effet sur la sécurité à l’échelle du secteur de la télécommunication, et ajoutera une strate supplémentaire de complexité à un problème déjà complexe.

Pour surmonter ce défi, il faut s’attaquer aux interactions entre les différentes couches des produits : matériel, logiciel, et virtualisation. Il faut assurer leur fiabilité différemment, sans entraîner d’effets secondaires critiques. Avec cette nouvelle infrastructure, les développeurs de matériel ne savent pas toujours ce qui y sera implanté. Ils essaient donc de les optimiser, et, par conséquent, finissent avec des optimisations qui pourraient être exploitées par un attaqueur. Bien sûr, il est possible de résoudre ce problème, mais seulement sur le logiciel, et non sur le matériel. Lorsque l’on conçoit une application à un niveau donné, on ne peut que s’imaginer ce qui y sera implanté, et ces hypothèses peuvent s’avérer partiellement valides, car il est impossible de prédire l’évolution du système.

Nous avons précédemment évoqué le cryptage multi couches et les services de sécurité. Il nous faut les appliquer à la situation que nous venons de décrire. Il s’agit d’implanter une couche capable de vérifier sa propre intégrité et, de surcroît, de s’auto protéger, mais il nous faut au préalable avoir une idée claire de ce sur quoi on l’implante. Si tel est le cas, il est possible de l’implanter en toute sécurité. Mais si cela est fait dans la précipitation et sans considération pour l’impact et les effets secondaires que cette modification du système peut entraîner, c’est un vrai problème.

Conseil 4 : Choisir un degré d’assurance qui vous convient et convient à votre produit

Tout cela peut paraître déconcertant, ainsi, il est important de garder à l’esprit qu’une organisation ne doit pas toujours (et souvent, ne devrait pas) souscrire au plus haut degré d’assurance possible dès le début. Le degré d’assurance dépend du client et du domaine dans lequel est développé le produit. S’il s’agit d’une infrastructure fondamentale, notamment d’un équipement de réseau ou bien d’une capacité de détection ou de contrôle, il vous faudra, certes, souscrire au plus haut degré d’assurance. Dans tous les cas, il vous faudra vous assurer que le produit n’a pas d’effets négatifs sur la sécurité de votre infrastructure critique.

Le degré d’assurance doit également être adapté et pertinent pour le client. Il ne faut pas investir dans un équipement destiné à être très sécurisé et souscrire à une assurance faible, car de potentielles vulnérabilités (ou pire, des vulnérabilités exploitées) peuvent nuire à votre image. Bien sûr, une entreprise peut choisir une assurance élevée pour un produit haut de gamme afin d’impressionner ses clients ou d’optimiser son marketing pour gagner leur confiance. Mais en général, la meilleure approche est celle de l’apprentissage par la pratique : il s’agit de commencer par le bas de l’échelle, et d’augmenter ses exigences au fur et à mesure.

Une entreprise souhaitant assurer des infrastructures non fondamentales peut par exemple commencer avec une assurance de niveau quatre, ce qui implique de vérifier le source code. Un évaluateur, lui, pourrait lui conseiller de commencer au niveau deux, compte tenu de l’effort et des coûts investis. Les niveaux plus élevés peuvent être adoptés plus tard. De cette manière, l’entreprise se préparera non seulement à son développement futur, mais sera également mieux à même de se soumettre à une évaluation supplémentaire et d’augmenter son degré d’assurance si nécessaire.

Conseil 5 : Optimiser les technologies

Lorsqu’il s’agit d’une assurance cybersécurité, il faut toujours faire des compromis, et l’un des plus importants est financier : une inspection de sécurité détaillée de n’importe quel appareil ou logiciel est très onéreuse, tout particulièrement aux degrés d’assurance les plus élevés. Les outils à disposition le sont également, du fait du manque d’automatisation, et, avec la virtualisation, toute automatisation devient encore plus complexe.

Néanmoins, la recherche au sujet de la vulnérabilité informatique a suscité beaucoup d’intérêt au cours des dernières années. Des techniques de plus en plus performantes sont produites pour gérer et sécuriser les vulnérabilités au sein des micrologiciels, des logiciels, etc. Cette recherche doit continuer à se développer, car les résultats nous permettront d’automatiser de nombreux éléments et d’optimiser l’IA. Ces technologies seront déterminantes pour gérer les vulnérabilités dans des systèmes de plus en plus complexes, et permettront aux processus d’assurance cybersécurité d’être plus rentables, plus efficaces et plus flexibles.

Il faut agir, maintenant

Alors que nous nous dirigeons têtes baissées vers cette nouvelle limite de l’assurance cybersécurité, il nous faut plus que jamais penser à ce que nous faisons, et à pourquoi nous le faisons. Il ne s’agit en rien de prendre une norme, de la copier ou de cocher les critères qu’elle établit. Il faut avancer au rythme des dernières recherches en date, apprendre du passé afin de construire quelque chose qui représente une contribution importante. Les initiatives du secteur dans le domaine de l’assurance cybersécurité ont ralenti depuis la fin des années 1980, les opérateurs de services ne mettant plus autant l’accent sur l’assurance cybersécurité. Mais, après le type de cyberattaques sur des infrastructures dont nous avons déjà été témoins, il ne fait aucun doute qu’une attaque importante aura lieu. Et quand cela arrivera, les régulateurs et les agences gouvernementales insisteront très lourdement sur l’assurance cybersécurité.

Cependant, les agences gouvernementales ne sont pas les mieux placées pour gérer cela. Déjà, dans de nombreux cas, le secteur de l’informatique n’a lui-même pas joué le jeu, et s’est retrouvé face à des exigences impossibles à respecter. Il nous faut donc être actifs et nous préparer à cette situation. Le secteur de l’informatique doit prendre les devants et participer à la définition des exigences. Grâce à cette participation et aux initiatives collaboratives, nous pourrons obtenir des retours immédiats sur la nature des exigences et la manière dont elles peuvent être mises en place. Nous pourrons ensuite construire des processus d’assurance cybersécurité qui garantissent que nos systèmes soient sécurisés dans leur conception même, mais également bien évalués et capable de faire face aux défis qui les attendent, quels qu’ils soient.