Inglorious Astar

De la sécurité contractuelle

Traité sur les exigences contractuelles de cybersécurité à inclure dans les cahiers des charges et appels d'offres (même quand on est une petite entreprise)

Public cible :
RSSI
-
Temps de lecture :
45
min

Cet article s’adresse aux entreprises qui veulent savoir quelles clauses de sécurité inclure dans leurs contrats / cahiers des charges / appels d’offres avec leurs prestataires et fournisseurs.
Pour aller droit à l'essentiel, sans mes interminables digressions, rendez-vous directement au chapitre : Les exigences contractuelles en cybersécurité

Notre histoire commence en l’an de grâce deux mille quinze lors d’un audit dans un hôpital de la France méridionale. Un petit scan de reconnaissance du réseau montrait une machine intéressante : un Windows XP (c’était déjà obsolète à l’époque) !
En ce temps-là, un petit exploit automatique, au doux nom de MS08-067, faisait la joie des pentesters depuis 2008.
Quelques secondes plus tard, notre gai auditeur jouait donc avec un terminal administrateur sur cette machine vétuste et essayait d’en comprendre l’usage, d’après sa liste des processus en cours.
Il s’enquit auprès du DSI de l’hôpital : “Cher Pierre, je suis circonspect, quel est ce XP ?”

- Euuuuuuuh on dirait l’IP de l’automate d’analyse du biomédical
- Est-ce vital ?
- Pour sûr oui, foi d’animal
- Il nous faut quérir le fournisseur, qu’il mette à jour cette horreur !
- Sur l’heure !

Effectivement, cet appareil sert aux analyses des biopsies, des prélèvements sanguins, etc. S’il ne peut fonctionner, on prend du retard dans les diagnostics (donc pertes de chances pour les patients).

La réponse du fournisseur arriva quelques jours plus tard et fut pour le moins décevante :

- Il n’y a pas de mise à jour à faire, l’automate fonctionne sous XP
- Mais enfin ce n’est pas sécurisé du tout ! Et puis pourquoi c’est en écoute sur le réseau en plus ? Il n’y a pas besoin !
- …
- …
- Voilà voilà voilà, on vous fait signe si on met à jour vers Windows 7

Quelle ne fut pas l’amertume de notre auditeur. Comment pouvait-on être aussi laxiste alors qu’il y avait des vies humaines en jeu ?
Ses futures années d’audit lui apprendraient que c’était loin d’être un cas isolé : ça ne concernait pas que cet automate-là, ça ne concernait pas que ce fournisseur-là, ça ne concernait pas que ce domaine-là (les logiciels qui tournent sous PHP 4, .NET 2,  JAVA 1 !!!  toi-même tu sais).

En discutant avec plusieurs RSSI du domaine de la santé, au fil des années, il comprit davantage les rapports de force à l’origine de cet état de fait :

  • Une situation quasi-monopolistique de certains fournisseurs
  • Leur facilité à renoncer aux clients qui exigeraient des engagements en sécurité, le cheptel des clients qui n’en ont pas étant bien assez vaste
  • La capacité naturelle du cerveau humain à nous empêcher de nous voir comme le méchant de l’histoire (vous savez le fameux “oui c’est égoïste et immoral, mais ma bonne dame LE MONDE est égoïste et immoral”)

Et ce n’est pas comme si les cas où l’on se faisait pirater via un fournisseur/prestataire, négligent en cybersécurité, étaient d’une rareté anecdotique : 63 % des piratages disait une étude de 2016.

Il faut déjà être une structure un tant soit peu conséquente pour pouvoir commencer à négocier des conditions particulières, en dehors des CGV du fournisseur. Mais, en sus, si vous mettez des exigences de cybersécurité dans votre cahier des charges, c’est souvent moins cher pour le fournisseur de renoncer à votre potentiel contrat que d’investir pour être au niveau.

On peut faire mieux que ça

Je dis souvent que la cybersécurité n'est pas un domaine mature et que ça se voit notamment au fait que sécuriser un site Web coûte à peu près autant que de le développer ET que ce n'est pas obligatoire. 
Que diriez-vous si au moment d'acheter une voiture on vous informait que "par contre les airbags et les ceintures de sécurité ne sont pas de série et l'option double le prix de la voiture"
Voilà … ben la cybersécurité en est un peu à ce stade si vous voulez.

Depuis que le volet Cybersécurité du plan de relance a été lancé (Astar a participé à plusieurs de ces parcours en tant que prestataire terrain), je crois voir transparaître une volonté de l’ANSSI de saisir par les cornes le problème des fournisseurs.

Il y a un fort accent qui est mis sur la formation des services achats pour qu’ils intègrent des exigences de cybersécurité dans leurs appels d’offres, cahiers des charges, etc. 
Notamment via les mesures 76 à 80, 205, 210 et 211 du questionnaire d’état des lieux organisationnel (en TLP Amber donc malheureusement pas accessible à tout le monde) de ces parcours de cybersécurité : Des clauses de sécurité (e.g. cloisonnement des données, communication des incidents de sécurité, confidentialité des données,…) sont-elles intégrées dans les contrats ? et via un module de sensibilisation entièrement dédié aux achats.
Avoir animé ce module m’a convaincu que c’était une idée fort à propos : les interactions entre les achats et les RSSI sont bien faibles à l’état sauvage. Les premiers méconnaissent les enjeux et le pouvoir qu’ils peuvent avoir dans la balance. Les seconds n’ont pas comme réflexe de s’appuyer sur des populations non techniques.
Bref, je me suis senti utile (ce n’est pas si courant que vous pourriez le penser).

Comme ce plan de relance concerne de nombreuses structures d’un seul coup, ça peut effectivement changer les choses via une sorte “d’effet syndicat”. 

Si toutes les métropoles et les hôpitaux se mettent à avoir des exigences en cybersécurité en même temps, le rapport de force avec les vils fournisseurs (il n’y aura pas de nuance dans cet article) pourrait basculer.
Si l’on n’achète plus leurs produits/services sans garanties de sécurité, peut-être vont-ils se mettre à lire l’OWASP.

La confiance n’exclut pas le contrôle

Un des points sur lequel je ne suis néanmoins pas emballé par l'approche de l'ANSSI, ce sont certaines pistes de réponse au risque de défaillance d'un fournisseur. 

L'ANSSI vous demande, dans le questionnaire organisationnel : "Une stratégie de sauvegarde est-elle définie pour les données/workload dans le Cloud ?", "Des capacités de redondance sont-elles mises en place sur des services Cloud pour éviter les cas d'interruption de service ?". Même pour le SaaS !
Ça me semble être du bon sens pour un Opérateur d’Importance Vitale ou de Service Essentiel (OIV/OSE), ce qui est la priorité de l'ANSSI. Mais bon, pour le commun des mortels, vous m’accorderez que si on recourt à du SaaS ou à de l’IaaS, ce n’est pas pour se farcir soi-même la sauvegarde et la redondance. 
Tout l'intérêt du cloud, c'est de se sortir de ces processus bas niveau chiants, complexes et chronophages.

Quand j'achète du SaaS, j'achète de la tranquillité : le service sera toujours disponible, les données seront toujours là, ça se met à jour tout seul, etc. C'est la promesse en filigrane, mais ce n'est pas forcément écrit noir sur blanc dans les conditions générales de vente.
Or, que faire si un jour cette promesse n'est pas tenue ? Genre si un gros hébergeur perdait vos données dans un incendie (c’est possible, c’est possible). Si votre ERP en SaaS était soudain tout vide ? Alors oui vous seriez en droit, au moins moral, de vous indigner "ça n'aurait pas dû arriver !" mais ça ne règlerait pas votre problème. Comme dit mon père, à propos de la sécurité routière : "être dans son droit ça sert à rien si on est mort".

Donc oui, il y a du sens à se prémunir techniquement d'une défaillance d'un fournisseur. 
Mais dans le monde, tel que moi je le rêverais, tout cela devrait passer par de la sécurité contractuelle : j'utilise un ERP en SaaS, le fournisseur s'engage à ce que mes données soient disponibles, si un jour elles ne sont plus là, il m'indemnise au moins à hauteur de mon préjudice et je dors bien la nuit.

Ça ne change effectivement rien au fait que je ne retrouverai pas mes données, mais ce que ça représente de les avoir perdues, comme impact pour moi, est compensé.
Et ne me dites pas que l'argent ne peut pas couvrir tous les impacts. En dernière approximation, c'est toujours plus ou moins faisable. Même un impact en réputation peut être approximé (c'est un manque à gagner de X clients potentiels perdus, qui auraient consommé en moyenne Y euros chez moi pendant Z années, bon ben remboursez-moi X x Y x Z).

La cybersécurité contractuelle c’est donc : s’assurer qu’un fournisseur s’engage bien à protéger mes données/services et s’assurer de la manière dont il s’y engage.

Bref, gardez en tête que les vraies bonnes pratiques consistent à se protéger contractuellement ET techniquement. Mais ici nous traiterons seulement de la partie contractuelle, car, à ma propre surprise, je n’ai pas trouvé les ressources auxquelles je m’attendais sur les internets. Pour vous dire qu’il faut mettre des exigences de sécurité dans les contrats, là y a du monde, mais pour donner un exemple réaliste, il n’y a plus personne.
Et chez Astar, on ne publie pas souvent des articles, mais on essaye qu’à chaque fois ils comblent un manque.

En écrivant ces lignes, j'ai les scénarios suivants en tête, que je voudrais voir disparaître et dont on va essayer de se prémunir :

  • Quelqu'un a piraté le compte d'un comptable sur l'ERP en SaaS, et a altéré toutes les données (factures, devis, bilans, etc. apparemment on doit 200 roupies au pape pour une prestation de 3000 call girls … les pirates ont de l’humour). Je contacte l'éditeur qui me dit qu'il assure uniquement la disponibilité des données, et que leur contenu ne le regarde pas. Les données sont bien là, si elles ne me plaisent pas, ce n’est pas leur problème. Donc il n'y a pas de possibilité de les restaurer à un état antérieur.
  • Un éditeur nous a vendu sa super solution GED en SaaS. Manque de pot, il développe comme un chèvre, il vient de se faire pirater et le service est down jusqu’à nouvel ordre. Je lui explique que mes équipes ont besoin de cette ressource pour travailler car toutes les procédures sont dessus, que tout est bloqué chez nous sans ça. Il me dit gentiment qu’on aura une ristourne sur la facture de 20€ par jour d’indisponibilité
  • Un fournisseur nous déploie sa super solution BI dans notre réseau. C’est une boîte noire dont on ignore tout le fonctionnement et qui nécessite de pouvoir dialoguer avec Internet. Dans les faits c’est un Windows XP Embedded, hors d’âge avec 40 ports ouverts sur le réseau, qui remonte des données au fournisseur, qui a un service TeamViewer et qui sera la première à se faire poutrer par un malware dans le réseau.
  • Je constate une faille de sécurité sur un logiciel on premise, lors d'un audit interne, je contacte l'éditeur pour qu'il le corrige, je le vois se figer, regarder son collègue et lui dire "ne bouge pas, sa vision est basée sur le mouvement"

Le dilemme Engagement de moyens Versus Engagement de résultat 

Dans les clauses que nous allons devoir définir, il va falloir faire des choix concernant un concept fondamental : demande-t-on un engagement de résultat ou un engagement de moyens ?

L’obligation de résultat porte sur un objectif que le fournisseur doit explicitement atteindre (par exemple un taux de disponibilité annuelle de 99,99%). S’il ne remplit pas cet objectif, il est généralement facile de le constater (puisque ça concernera souvent un service directement consommé par le client) et la charge de la preuve incombe au fournisseur (prouver qu’il n’est éventuellement pas responsable de ce défaut).
L’obligation de moyens porte sur un effort que l’on attend du fournisseur. Effort que l’on aura jugé bien dimensionné par rapport aux risques encourus. S’il y a malgré tout un sinistre, il faut alors déterminer si c’est dû au risque résiduel assumé (la “fatalité”) ou à une négligence du fournisseur (qui n’aurait pas mis en œuvre les moyens sur lesquels il s’était engagé). Il n’y a “faute” que dans ce seconde cas. Or la charge de la preuve incombe ici au client. C’est lui qui devra prouver que le fournisseur n’a pas respecté son engagement de moyen. C’est rarement aisé puisque le client ne dispose pas d’un accès au système d’information du fournisseur.
Tout engagement qui n’est pas explicitement un engagement de résultat est considéré comme un engagement de moyens.
Plus on met d’engagement de résultats, plus on est protégé mais plus le fournisseur va être réticent à signer.

Il y a quelque chose qui est déjà facile à trancher : on ne peut pas décemment exiger un engagement de résultat sur le fait de ne pas se faire pirater. Il suffit de quelques failles 0 days et on peut se retrouver complètement troué, alors qu’on a fait le boulot.
Peu sont assez fou pour prendre un engagement de résultat sur la confidentialité car la perte de confidentialité n’est pas un événement réversible : un fois qu’un adversaire a eu accès à une information confidentielle, on ne peut pas la lui faire oublier.
Une perte d’intégrité, comme des données erronées par exemple, est très difficile à corriger. On ne peut pas automatiquement “corriger” des données fausses. Donc personne ne s’engagera facilement à ce que les données soient intègres (il suffirait d’une erreur matérielle d’écriture pour que ce soit raté par exemple). MAIS, revenir à un état antérieur (où les données étaient encore fiables) est une solution largement acceptée par toutes les parties.
La disponibilité est un critère sur lequel il est plus facile de s’engager en résultat, notamment car il est facilement quantifiable. Je peux vous dire combien de temps mon service a été indisponible sur une période donnée. Par exemple, quand on parle d’un engagement de disponibilité “Triple Nine”, c’est que le fournisseur s’engage à ce que le service soit disponible 99,999% du temps sur un an (soit un maximum de 6 minutes d’indisponibilité sur toute l’année!). C’est le cas du numéro du SAMU par exemple.

Donc notre approche sera d’exiger un engagement de résultats sur les domaines où il est courant de le faire (la disponibilité et l’intégrité via le retour à un état antérieur par exemple) et un engagement de moyens ailleurs.
Le fait que la majorité des exigences seront des engagements de moyens devrait éviter de faire peur au fournisseur, tout en favorisant des pratiques vertueuses : lui faire découvrir les standards de sécurité, lui faire auditer son SI, …

Les exigences contractuelles en cybersécurité

Un point transverse à aborder est qu’il est bien plus simple d’introduire vos exigences si vous passez par un appel d’offre (ou marché public) que par un achat sur étagère (ou les CGV sont plus ou moins imposées).
Il faudra donc parfois inculquer cette “culture” chez ceux qui dépensent les budgets et ceux qui gèrent les achats chez vous. Mais il faudra compter que c’est aussi, évidemment, plus de travail pour eux.

Pour les grosses structures

Si vous êtes une structure qui pèse assez pour avoir des moyens de négociation (Airbus, le Ministère de l’Intérieur, Air Liquide, Carrefour, Astar, … ok pas Astar), il existe des exemples “““relativement””” faciles à copier.

Tout d’abord, il y a le Cahier des Clauses Simplifiées de Cybersécurité (CCSC) de 2018. Il a été créé pour le secteur public mais peut s’appliquer à tout le monde. 
Il s’agit d’un encadrement global qui fixe des principes généraux sans aller trop loin dans le détail. Mais il y a tout de même des mentions précises salutaires :

5.1. Les politiques de sécurité convergent pour exiger les mises à jour des composants logiciels vers des versions supportées par l’éditeur ou la communauté Open Source qui les produisent. [...].

5.2. La responsabilité du maintien en condition de sécurité d’un titulaire comprend les composants et services développés en propre mais aussi ses composants et dépendances amont (librairies, cadriciels, environnement d’exploitation, API tierces) ou sous-traités.

5.3. Un candidat ou titulaire ne peut conditionner ses garanties de bon fonctionnement de fournitures ou prestations qu’il fournit à l’emploi de composants dans une version non supportée, [...].

5.4. Dans tous les cas, les unités d’œuvre portant le maintien en condition opérationnelle (labellisée MCO mais aussi tierce maintenance applicative (TMA) ou simplement hébergement) incluent le maintien en condition de sécurité et donc la mise en œuvre des correctifs de failles de sécurité

L’idée de ce document est de figurer dans les conditions générales. Puis que vous définissiez des clauses plus précises dans les conditions particulières.

Le référentiel le plus largement plébiscité, pour une approche exhaustive, est le Guide des clauses de sécurité des systèmes d’information types à intégrer dans les marchés publics de l’ANSSI. Il comprend, dans ses sections 2 et 3, les clauses administratives et techniques dans une longue liste à la Prévert de 34 pages. Et vous pouvez aussi trouver un exemple, tout fait, d’un cahier des charges qui applique ce guide : https://www.ssi.gouv.fr/uploads/IMG/pdf/2010-12-03_Guide_externalisation.pdf
Ce référentiel vous propose notamment de laisser les candidats se prononcer sur les moyens par lesquels ils se conforment à ces exigences, via un Plan d’Assurance Sécurité (PAS) qui sera inclus dans leur réponse. 
Le modèle de l’ANSSI insiste notamment sur l’explicitation de deux points cruciaux : Quelles sont les procédures à suivre en cas de non-respect du PAS ? Quelles sont les pénalités encourues ?
Car s'il n'y a aucune pénalité financière de prévue en cas de manquement, tous les engagements du prestataire restent des vœux pieux. 

Ils pensent notamment à mentionner que “une clause doit préciser que le prestataire s’engage à exécuter ses obligations selon un Plan d’Assurance Sécurité (PAS), défini en accord avec le donneur d’ordres. Le cas échéant, cette clause doit annuler et remplacer la clause de sécurité générique proposée par le prestataire dans son contrat type”.
Traduisez : balec de vos conditions générales de vente, vous devez vous plier à nos exigences.

Le seul reproche que je ferais à ce modèle concerne les exigences sur le développement applicatif. 
L’ANSSI propose une liste non exhaustive qui termine par : “Pour la mise en œuvre de technologies web, les développements pourront s’appuyer sur les recommandations de l’OWASP (Open Web Application Security Project)”.
En fait, il y avait mieux à faire car l’OWASP, en plus de ses recommandations, a aussi produit un référentiel (exhaustif lui) des exigences de développement sécurisé (applicables pour le Web mais aussi pour tout logiciel en général) : le OWASP Secure Coding Practices. Et c’est de la bombe.
En citant cette référence comme une exigence, il n’y aura plus aucune zone de flou derrière laquelle le prestataire pourrait se cacher.

Pour nous les gueux

Tout ça c’est bien pour les entreprises qui sont assez grosses. Mais pour la petite PME du coin, inclure 34 pages d’exigences types, c’est probablement un peu optimiste. L’éditeur peut juste répondre :

Dans cette section (qui est l’objectif initial de cet article), nous avons voulu fournir un modèle de cahier des charges cybersecu en mode “best effort” pour les sociétés qui n’ont pas beaucoup de marges de négociation ni de poids dans le rapport de force, mais qui ne veulent pas être complètement à poil non plus.

Voici ce que l’on s’est fixé comme objectifs :

  • Ça doit tenir sur une page environ pour ne pas trop alourdir les documents auxquels il pourrait être annexé, ni trop faire peur à un éditeur (s’il voit 20 pages d’exigences en sécurité, il risque de partir en courant sans même les lire).
  • Ça doit être le plus transversal possible (SaaS, logiciel on premise, prestation, hébergement, fournisseur) pour que ce soit le plus simple possible à utiliser par le service achat (ils n’ont pas les connaissances techniques pour accommoder facilement au cas par cas).

Du coup on ne va pas s’appuyer sur le CCSC (sauf si vous êtes un organisme public obligé de l’inclure) car il prend beaucoup de place sans pour autant aborder tous les points que l’on voudrait.

On a vu, dans la section précédente, que pour tout ce qui est exigences sur les logiciels, on peut remplacer mille pages par une seule phrase, faisant directement référence à l’OWASP Secure Coding Practices.

Pour les exigences concernant la sécurité que le fournisseur applique à son SI, on aimerait aussi pouvoir remplacer les 34 pages de l’ANSSI par une référence unique. On peut bien sûr faire une référence à ce document, mais il n’est pas conçu pour être cité tel quel (il y a notamment des parties à trou).
Y a t’il un endroit qui centralise et explicite précisément le fameux état de l’art de l’exploitation informatique sécurisée ?

Le CCSC, que nous avons vu plus haut, renvoie la définition de l’état de l’art aux ressources disponibles à cette adresse : https://www.economie.gouv.fr/hfds/cybersecurite-et-politique-ministerielle-ssi et en fait un résumé dans son Article 11. C’est pas horrible (notamment sur la sauvegarde par exemple), mais il manque vraiment beaucoup de choses.

Historiquement, la ressource la plus transversalement acceptée est l’Annexe A du Cybersecurity Framework du NIST états-unien (elle est téléchargeable en français aussi). Elle liste tous les sujets dont une entité “critique” devrait s’occuper, sans se prononcer sur les moyens techniques d’y parvenir. Peu d’entreprises peuvent se dire complètement conformes, mais les exigences sont vraiment pertinentes.

En 2018, la directive européenne NIS a été transposée en droit français et fournit aussi des exigences techniques et organisationnelles assez précises dans son Annexe 1 : https://www.legifrance.gouv.fr/loda/id/JORFTEXT000037444012/

Ça peut être sympa d’avoir une référence européenne plutôt qu’américaine, sauf que …
La directive a été pensée pour les opérateurs de services essentiels (OSE). Ça parle tout le long de SIE (système d’information essentiel) et d’homologation. Donc si vous donnez ça directement à un fournisseur, il risque de répondre “non mais calmos je suis pas un OSE moi” ou tout simplement de se dire “bah très bien je suis conforme de fait puisque ça s’applique seulement aux SIE et que je n’ai pas de SIE chez moi, allez hop emballé c’est pesé”. Donc si on propose ce référentiel plutôt que celui du NIST, il faudrait reformuler intelligemment.
Pour ces raisons, je suggère d’utiliser l’annexe A du NIST par défaut (il a l’avantage d’être traduit dans plusieurs langues). Si le fournisseur est vraiment un tout petit acteur, on peut envisager d’y substituer une référence à l’article 11 du CCSC.

Voici donc ce que je vous propose (les parties personnalisables sont entre chevrons) :

  1. Clause de respect réglementaire. Le fournisseur s’engage à respecter les prescriptions de la PSSI de <VOTRE NOM>, telle qu’elle existe en date du présent contrat, pour toutes les opérations de déploiement, d’installation, de maintenance, de dépannage, de décommisionnement et de communication d’information, impliquées par le présent contrat. Le fournisseur s'engage à assurer la sécurité des données personnelles de <VOTRE NOM>, qu'il pourrait être amené à traiter, conformément aux exigences du Règlement Européen sur la Protection des Données :
    https://www.cnil.fr/fr/reglement-europeen-protection-donnees;
  2. Clause de développement sécurisé. Le fournisseur s'engage à développer ses <produits informatiques (logiciels, matériels, systèmes, applications, sites Web, équipements, etc.)>, mobilisés dans le présent contrat, dans le respect des règles de développement sécurisé, d'après le standard international OWASP Secure Coding Practices :
    https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf. Le fournisseur s’engage à recourir à des dépendances logicielles réputées sûres, à contrôler la publication de vulnérabilités les concernant et à appliquer les corrections idoines le cas échéant;
  3. Clause de déploiement sécurisé. Le fournisseur s'engage à déployer et héberger ses <produits informatiques (logiciels, serveurs, applications, sites Web, équipements, etc.) et services>, mobilisés dans le présent contrat, sur des environnements de production conformes à l'état de l'art de la cybersécurité, tel que défini dans les règles de l’annexe A du référentiel de cybersécurité du NIST :
    https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018fr.pdf;
  4. Clause de disponibilité. Le fournisseur s’engage à assurer la disponibilité de ses <produits (logiciels, serveurs, applications, sites Web, équipements, etc.) et services>, mobilisés dans le présent contrat, et des données qu’ils contiennent, notamment par une durée maximale d'interruption admissible (DMIA) de <24 heures>, par un taux annuel de disponibilité de <99,X%> et par une perte de données maximale admissible (PDMA) de <24 heures>;
  5. Clause d’intégrité. Le fournisseur s’engage à assurer l’intégrité de ses <produits (logiciels, serveurs, applications, sites Web, équipements, etc.) et services>, mobilisés dans le présent contrat, et des données qu’ils contiennent, notamment par une capacité de réversibilité à un état antérieur de <1 jour, 2 jours, 3 jours, 1 semaine, 2 semaines, 3 semaines, 1 mois, 2 mois, 3 mois>;
  6. Clause de confidentialité. Le fournisseur s’engage à assurer la confidentialité de ses <produits (logiciels, serveurs, applications, sites Web, équipements, etc.) et services>, mobilisés dans le présent contrat, et des données qu’ils contiennent, notamment par une traçabilité et auditabilité des accès;
  7. Clause de mesure du niveau de sécurité. Le fournisseur s’engage à mettre à disposition un point de contact univoque pour la remontée des problèmes de sécurité, notamment via la présence d’un fichier security.txt à la racine de son site Web (conformément au standard https://securitytxt.org). Le fournisseur s'engage à faire auditer annuellement la cybersécurité de ses <produits et de ses environnements de production>, mobilisés dans le présent contrat, par un prestataire indépendant et qualifié en la matière;
  8. Clause de contrôle du niveau de sécurité. Le fournisseur s'engage à fournir, sur demande de <VOTRE NOM>, la synthèse du dernier audit de cybersécurité (partie managériale synthétisant le niveau de sécurité globale, sans révéler les détails techniques des vulnérabilités) mené sur ses <produits et ses environnements de production>, mobilisés dans le présent contrat, dans un délai de <30 jours ouvrés>. Le fournisseur s’engage à notifier, dans un délai de 7 jours calendaires, <VOTRE NOM> de toute violation avérée de disponibilité, d’intégrité ou de confidentialité sur les produits et environnements de production qui hébergent des données de <VOTRE NOM>;
  9. Clause d’auditabilité. Le fournisseur autorise <VOTRE NOM> à tester (directement ou via un tiers expert) la sécurité des produits et services mobilisés dans le présent contrat, sans frais supplémentaires. 
  10. Clause de maintien en conditions de sécurité. Le fournisseur s’engage à corriger les défauts de sécurité, qu’il constate ou qui lui sont notifiés, sur ses produits et environnements de production, sans frais supplémentaires et dans des délais cohérents avec leur sévérité : 30 jours ouvrés, après notification, pour une vulnérabilité dont le score CVSS (dans sa version la plus récente) est supérieur ou égal à 7.0 et 90 jours ouvrés en deçà de 7.0;

Le truc “malin” de cette approche c’est de pouvoir se permettre une inexhaustivité des points à aborder car la clause 7 déporte cette tâche sur le prestataire d’audit. C’est lui qui pensera à tout à votre place et vous pourrez accéder à ses résultats via la clause 9.

La clause 1 est là pour limiter le cas des fournisseurs qui s’installent un TeamViewer sauvage sans rien demander à personne et qui prennent la main quand ils veulent dans votre SI.

Pour la clause numéro 3, il y a des cas où le fournisseur installe son logiciel sur un système que vous avez installé et paramétré. Il se peut alors qu’il faille un peu adapter cette clause, car il ne sera pas responsable du maintien en conditions opérationnelles et de sécurité (MCO/MCS) de cette machine.

Pour la partie “taux annuel de disponibilité”. Vous pouvez choisir 99,0 % (environ 90 heures d’indisponibilité admise sur une année), 99,9 % (environ 9 heures), 99,99 % (environ 1 heure).

Par ailleurs, je n’ai pas inclus la clause de réversibilité/transférabilité parce qu’elle relève en partie des exigences fonctionnelles types. Et il s’agit notamment d’une clause incluse de fait dans le RGPD, au moins pour ce qui concerne les données personnelles. Si elle ne figure nulle part dans votre cahier des charges, il faut la mentionner explicitement ici :

  1. Clause de réversibilité. Dans le cas où le présent contrat se termine, le fournisseur s’engage à restituer tous les éléments nécessaires à la reprise d’exploitation par <VOTRE NOM> ou par un autre prestataire, dans un délai de X jours. Ces éléments doivent être transmis de manière sécurisée (garantissant la confidentialité et l’intégrité). 

Ensuite rappelons que les clauses ne valent que par les pénalités encourues. 
Normalement, ces clauses ne seront qu’une page dans un document plus large où une section dédiée traite des pénalités.
La valeur par défaut des marchés publics, par exemple, est une pénalité d’1/3000ème du montant du marché, par jour de non-respect constaté d’une clause.
Plusieurs référentiels mettent en garde contre cette valeur qui convient mal aux produits et services informatiques (où les préjudices par jour dépassent très souvent cette valeur d’un ou plusieurs ordres de grandeur). Ils recommandent alors d’appliquer une formule personnalisée plus en adéquation : (V x R)/F où V est la valeur du contrat, R le nombre de jours de retard et F un facteur à ajuster au besoin.

Par exemple pour un ERP en SaaS qui coûterait 20 000 € annuellement (licence + maintenance) et qui vous planterait inopinément pendant 5 jours, ça donnerait :

  • Avec un facteur F= 1000 : (5 x 20 000)/1000 = 100 € de pénalité
  • Avec un facteur F= 100 : (5 x 20 000)/100 = 1000 € de pénalité
  • Avec un facteur F= 20 : (5 x 20 000)/20 = 5 000 € de pénalité
  • Avec un facteur F= 10 : (5 x 20 000)/10 = 10 000 € de pénalité

Je trouve que 5 000 € dans ce cas, c’est un bon équilibre entre le préjudice subi et l’aspect dissuasif de la pénalité. Mais ça sera souvent au cas par cas.

Une autre difficulté provient de l’impossibilité, parfois, de réfléchir en termes de “jours de non-respect constatés”. 
Si le service est indisponible 5 jours, puis qu’il est remis, là c’est facile. Mais quand OVH a vu les données de ses clients détruites dans l’incendie, ce n’est pas qu’ils ont mis longtemps à les récupérer, c’est qu’elles sont définitivement perdues (donc la variable R vaut l’infini, ce qui est un peu problématique).
Et inversement, définir des pénalités forfaitaires n’est probablement pas dans votre intérêt. Si un fournisseur peut payer une fois 5000 € parce que sa solution tourne sur Windows XP et que vous vous en êtes rendu compte. Bon ben vous avez gagné 5000€ mais vous avez toujours le risque que cette machine se fasse poutrer par le premier malware venu. 
On pourrait dire que, du coup, vous avez 5000€ de budget à dépenser dans des mesures palliatives (isolation de la machine, hardening, …), mais ce n’est pas génial quand même.

Dans le cas où les clauses que je vous ai présentées ne sont pas incluses dans un document plus large qui traite des pénalités, il faut alors ajouter une clause spécifique pour cela. Nous vous en proposons une ici, mais gardez à l’esprit que nous ne sommes pas experts dans ce domaine :

  1. Pénalités. En cas de non-respect temporaire d’une des clauses précédentes, le fournisseur s’engage à indemniser <VOTRE NOM> d’une pénalité P définie par la formule (V x R)/F où V représente le prix du présent contrat et R le nombre de jours constatés de non-respect d’une clause. En cas de non-respect définitif d’une des clauses précédentes, le fournisseur s’engage à indemniser <VOTRE NOM> d’une pénalité P forfaitaire d’un montant de X % du prix du présent contrat. <VOTRE NOM> pourra unilatéralement annuler le présent contrat, auquel cas le fournisseur s’engage à prendre à sa charge toutes les opérations techniques de migration vers une solution concurrente (exportation et importation des données, mise en forme des données, frais de configuration initiale, etc.).

L’actualité brulante

En écrivant cet article, j’ai été rattrapé par l’actualité. L’Union Européenne a publié, en Septembre 2022, son ébauche du CyberResilience Act.

Il s’agit d’obliger les fournisseurs à sécuriser leurs produits. Notamment d’éviter qu’ils sortent avec des vulnérabilités publiques connues (c’est triste d’en arriver à demander ça mais c’est effectivement le cas) et assurer au moins 5 ans de mises à jour de sécurité.

Je vous renvoie vers un article du Monde pas trop mal sur le sujet : https://www.lemonde.fr/pixels/article/2022/09/15/cyber-resilience-act-l-union-europeenne-veut-serrer-la-vis-sur-la-cybersecurite_6141754_4408996.html

Il est notamment question d’une catégorie qui distingue les produits les plus critiques, comme les antivirus, les VPN, les pare-feux, etc. 
Et, franchement, ce n’est pas du luxe. J’étais là Gandalf, en 2020 quand une vulnérabilité F5 est sortie, tellement simple qu’elle excluait que le développeur ait été sensibilisé à la cybersécurité et que le produit ait été audité. J’étais là Gandalf, pendant le confinement, quand tous les VPN du marché se faisaient trouer.
Or ces éditeurs basent leur marketing sur le fait de vendre des produits “de sécurité”. Faire développer des produits de sécurité par des dev qui n’y connaissent rien et ne pas faire auditer le produit fini … c’est se foutre de la gueule des clients.

Nous parlions justement de tous ces sujets dans notre article sur le Pearl Harbor numérique. Et nous appelions de nos vœux une législation de ce type. Dans le chapitre “Face à cela que faire ?”, nous disions mot pour mot :

“Arrêter l’hémorragie en limitant la commercialisation d’outils informatiques dont la sécurité n’a pas été auditée, tout comme on ne commercialise pas de voiture qui n’a pas passé les contrôles de sécurité.
Au moins pour les produits et logiciels payants, ce devrait être incontournable. Aujourd’hui, on paye parfois des fortunes pour des outils qui, indirectement, nous font perdre d’autres fortunes, car ils sont truffés de vulnérabilités.
Sans parler des cordonniers mal chaussés que sont les produits de sécurité (antivirus et autres) : quand ils sont eux-mêmes des sources de vulnérabilités alors qu’ils sont censés nous en prémunir…”

Côté sanction on parle d’ordres de grandeur à 15 millions, donc il y a de la dissuasion.

Bref, nous ne pouvons que nous réjouir d’une telle démarche (même si elle semble exclure les produits médicaux). Il ne s’agit encore que d’une ébauche, mais il y a le potentiel d’influencer le marché comme le RGPD l’a fait (même si toujours personne n’est conforme au RGPD, au moins on s’intéresse au sujet).

Donc peut être que cet article sera obsolète d’ici quelques années car les exigences de sécurité seront dans la loi et non plus dans les cahiers des charges. On se le souhaite.

David SORIA
-
2022-10-18

Nos autres articles