Close

Interopérabilité et cybersécurité : quels enjeux ?

Interopérabilité[1] et cybersécurité sont intimement liées. Assurée par les célèbres interfaces de programmation applicatives, ou API, l’interopérabilité entre services et applications, clé de voute de l’économie numérique, soulève de nombreux problèmes de sécurité, tout comme la cybersécurité se heurte souvent à l’interopérabilité encore insuffisante des multiples solutions de cybersécurité disponibles sur le marché.

1er défi : sécuriser les API, clé de l’interopérabilité applicative

Quel est le point commun entre le « scandale Facebook » qui a vu 87 millions de compte exposés à la gourmandise de Cambridge Analytica[2] et la fuite de données dont a été victime Salesforce[3] la même année ? Dans les 2 cas, ce sont des API qui ont exposé et livré des milliers de données de clients de ces plateformes à des tiers. Ces API pourraient même devenir la première cause de fuite de données dans le monde compte tenu de leur généralisation et de l’attractivité de la couche applicative pour les attaquants. En cause, lorsqu’il ne s’agit pas d’une fuite intentionnelle vers une application tierce : une négligence, une erreur de configuration, un chiffrement faible ou inexistant ou bien encore des attaques de type « man in the middle ».

Chiffrer les flux et authentifier les requêtes

Pourtant, que l’on utilise des API basées sur le protocole SOAP (Simple Object Access Protocol), qui offre nativement plus de sécurité, ou sur une architecture REST (Representationnal State Transfer), les solutions existent. A partir d’une analyse de risque portant sur les usages de l’API et des données échangées, il s’agira notamment de chiffrer les flux et d’authentifier et autoriser les requêtes transitant par l’API. Dans le cas du protocole SOAP, il sera ainsi possible d’implémenter WS-Security (Web Services Security, protocole de communication qui assure la sécurité des services Web) qui propose nativement des mécanismes de chiffrement, de signature et d’authentification. Quant à la sécurité des API REST, qui utilisent le protocole http, elle reposera sur le chiffrement TLS (Transport Layer Security), qui permettra de s’assurer que les données transitant entre les deux systèmes ne sont pas modifiées. Par ailleurs, alors que le format de fichier JSON (JavaScript Object Notation) utilisé dans les API REST pour accélérer le transfert de données via les navigateurs web ne permettait pas de contrôle d’intégrité de bout en bout, il est désormais possible de lui adjoindre un mécanisme de signature (JSON Web Signature ou JWS).

Plateforme de gestion des API et Web Application Firewall

Même s’ils doivent être intégrés dans les API, ces mécanismes de sécurité ne suffisent pas. Encore faut-il gérer convenablement tout le cycle de vie de l’API (test de sécurité, mise en ligne, versionning, gestion des vulnérabilités, gestion des accès…) grâce à des passerelles API ou une plateforme de management dédiées. Une telle plateforme permettra de centraliser la gestion des mécanismes de sécurité liés aux API, qu’il s’agisse de la gestion des droits (généralement interfacée avec l’architecture de fédération d’identité de l’organisation), de l’authentification des utilisateurs, de la gestion, du chiffrement des flux ou bien encore de la détection des menaces déjà connues. La centralisation des flux autour d’une plateforme unique de gestion des API crée en effet un nouveau point de vulnérabilité. Il est donc fortement conseiller d’utiliser également un Web Application Firewall (WAF) ou pare-feu applicatif qui filtre les requêtes, bloque les attaques (déni de service applicatif, vol de session http, injection SQL…) en périphérie et permet d’optimiser les performances de l’application grâce au mode reverse proxy.

 

2ème défi : renforcer l’interopérabilité des solutions de cybersécurité

Si elle constitue un défi de sécurité de tous les instants, l’interopérabilité applicative est également une condition sine qua non pour disposer d’une chaine de cyberdéfense cohérente et efficace, éviter les silos opérationnels et exploiter au mieux les données collectées. La complexification et la diversification des menaces exigent en effet le recours à de multiples solutions. Il n’est ainsi pas rare de voir des organisations recourir à plus d’une vingtaine de solutions différentes pour couvrir leurs différents besoins. Une tendance encore renforcée par l’éclatement du marché de la cybersécurité en France.

Un enjeu opérationnel

L’interopérabilité des solutions de sécurité (SIEM, firewall, IDS, antivirus…) constitue d’abord un enjeu de performance opérationnelle. Elle permettra en effet de superviser tout ou partie des équipements via une console unique et rendra possible l’orchestration, voire l’automatisation, d’un certain nombre de processus de détection et de réaction afin de concentrer les opérateurs sur les incidents les plus critiques. Autant de critères essentiels dans un contexte de compression des coûts et de rareté des compétences. Autres défis opérationnels : l’interopérabilité des solutions de chiffrement qui permet de proposer du chiffrement de bout en bout, facilitant la circulation des données entre des environnements de même niveau de sécurité, qu’ils soient internes ou externes à l’organisation, et celle des solutions de cyber threat intelligence (IoC). Le partage d’information et la contextualisation des Indicateurs de Compromission (IoC) sont en effet indispensables pour accélérer le cycle de cyberdéfense et tenter ainsi de compenser l’asymétrie entre l’attaquant et le défenseur. En termes d’architecture, il s’agira enfin de s’assurer de la scalabilité de toutes ces solutions et in fine de la résilience de l’ensemble, c’est-à-dire de la capacité à pouvoir changer rapidement et facilement une « boîte », par exemple en cas de défaillance d’un fournisseur.

Un enjeu commercial

Au-delà des enjeux opérationnels, l’interopérabilité représente également un avantage compétitif clé pour les fournisseurs de solutions. Faute de pouvoir maitriser de bout-en-bout l’ensemble de la chaine, ceux-ci doivent nouer des partenariats avec des solutions complémentaires et s’intégrer à des écosystèmes pour augmenter progressivement leur couverture fonctionnelle et proposer aux clients, à défaut d’une solution intégrée, une solution interopérable. Le premier moyen consistera à permettre à sa solution de dialoguer, via des API, avec d’autres systèmes déjà existants sur le marché pour bénéficier de l’effet de réseau, ou, pour le premier entrant, en donnant toutes les informations nécessaires sur ses propres interfaces pour structurer autour de soi un écosystème et ainsi influencer le marché. Autre possibilité : la participation à des travaux de normalisation pour définir conjointement des protocoles (pour les interfaces logicielles) et formats (pour les interfaces entre programme et données) ouverts et normalisés, « voie royale vers l’interopérabilité »[4].

Un enjeu de souveraineté

L’interopérabilité en matière de cybersécurité recèle ainsi des enjeux de souveraineté forts. Dans une économie basée sur les réseaux, elle est même devenue, avec les standards et normes qui en sont les principaux outils, un véritable enjeu de puissance et de domination du marché. Elle doit donc être exploitée de façon stratégique pour défendre et valoriser ses positions et contribuer à la structuration et au renforcement de notre base industrielle et technologique de cybersécurité.

[1] L’interopérabilité peut être définie comme « la capacité que possède un produit ou un système, dont les interfaces sont intégralement connues, à fonctionner avec d’autres produits ou systèmes existants ou futurs et ce sans restriction d’accès ou de mise en œuvre ». Elle suppose une possibilité d’échange, non pas avec une mais avec plusieurs solutions, et ne doit donc pas être confondue avec la simple compatibilité (source : https://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9).

[2] https://www.nextinpact.com/news/106349-retour-sur-scandale-cambridge-analytica-et-molle-reponse-facebook.htm

[3] https://www.zdnet.com/article/salesforce-warns-customers-of-data-leak-caused-by-api-error/

[4] Source : https://journals.openedition.org/cdst/231#tocto2n4