La pensée  Cyber d’aujourd’hui est au sujet de la sécurité des fournisseurs, et plus particulièrement le cahier des charges sécurité et les exigences qu’il contient.

Une pratique très courante consiste à intégrer des référentiels génériques dans le cahier des charges. On trouve par exemple des normes type annexe A de l’iso ou PCI DSS, ou des réglementations tel que NIS ou la LPM et des guides de bonne pratique.

Les textes de ces référentiels sont repris dans le cahier des charges telle quelle, de manière brute et sans aucune contextualisation.

Cette approche pose problème car :

1. elle ne permet pas, en phase de sélection, de distinguer les fournisseurs qui répondent au vrai besoin de sécurité du client
2. elle ne permet pas d’avoir un vrai engagement du fournisseur à respecter ces exigences

Je m’explique :

Premièrement, une exigence générique dans un référentiel n’est généralement pas assez directive, elle n’est pas précise et elle est sujette à interprétation. Et dans ce cas, il est très rare qu’un fournisseur vous dise qu’il n’est pas conforme.

Prenons par exemple un référentiel qui contient une exigence générique de segmentation du réseau. Si vous demandez à un fournisseur s’il est conforme, il vous dira toujours oui, que son réseau est segmenté, même si cette segmentation est faible, et ne répond pas au besoin du client.

Deuxièmement, quand le fournisseur signe le cahier des charges, ce ne serait pas clair sur quoi il s’est engagé, et celà mène généralement à des conflits plus tard dans le projet, et ce ce ne sera pas forcément de sa faute.

Avec l’exemple de tout à l’heure, le fournisseur s’engage à segmenter le réseau. Mais que veut dire segmenter le réseau, de combien de segment parle-t-on, que contient chaque segment,  tout cela n’est pas clair dans cet engagement.

A cause de cela, on risque"Possibilité qu’un événement redouté survienne et que ses effets impactent les missions de l’objet de l’étude." - Guide officiel de la méthode EBIOS Risk Manager - More d’avoir des conflits dans le projet quand la segmentation proposée par le fournisseur s’avère faible par rapport aux attentes du client.

Pour éviter cette situation :

Il faut premièrement décliner les exigences en mesures opérationnelles, claires, précises et adaptées au contexte du projet.

Pour l’exemple de tout à l’heure, au lieu de mettre segmenter le réseau, il faut préciser les segments ou segments type qu’il faut avoir, les composants à isoler et les interconnexions autorisées.

Vous pouvez me dire “mais on ne connaît pas forcément l’architecture du système à l’avance”.

De mon expérience, il est généralement possible et je conseille de le faire,  de définir une architecture type en avant projet, et par rapport à laquel il faut contextualiser.

Ensuite, en phase de sélection, le fournisseur devra  expliquer comment il implémente ces mesures du cahier des charges dans la solution qu’il propose.

De cette manière, il est plus facile de distinguer les solution qui répondent au besoin de sécurité et l’engagement du fournisseur est plus clair lors de la signature, ce qui est plus sain pour le projet.