Pourquoi Sécurité exige de la transparence

Chaque fournisseur affirme que son produit est « sécurisé » jusqu’à un certain point, mais le terme a perdu son sens. Sécurité est devenu un argument marketing plutôt qu’une propriété mesurable. Dans les systèmes de sauvegarde et de stockage, où les enjeux sont les plus élevés, la transparence est le seul moyen de transformer la sécurité d’un slogan en quelque chose que les organisations peuvent évaluer.  

Les administrateurs doivent comprendre non seulement ce qu’un fournisseur affirme, mais aussi sur quelles hypothèses reposent ces affirmations, à quoi l’architecture est censée résister et comment ces objectifs ont été validés. 

Pour évaluer les architectures Zero Trust et Résilience des données Zero Trust, les fournisseurs doivent expliciter ce qu’ils supposent qu’il se produira lors d’une attaque, ce qu’ils supposent qu’il ne se produira pas, et comment leur système se comporte lorsque ces hypothèses sont mises à l’épreuve. Sans cette clarté, les organisations se retrouvent à interpréter des assurances vagues plutôt que des preuves concrètes. 

Quand les fournisseurs ne sont pas transparents, les clients sont contraints de distinguer la réalité du bruit. La transparence est ce qui leur permet de comprendre ce qui est réellement vrai. 

Zero Trust commence par partir du principe qu’une compromission se produira.

Zero Trust est souvent réduit à un ensemble de fonctionnalités de durcissement telles que la MFA, TLS, le contrôle d’accès basé sur les rôles ; toutefois, le principe global le plus important est un état d’esprit « Assume Breach ». Cela signifie supposer une compromission non seulement de l’environnement réseau, mais aussi du produit du fournisseur lui‑même. Si un attaquant obtient un accès administratif, vole des identifiants ou usurpe l’identité d’un opérateur, le système de stockage doit malgré tout protéger les données de sauvegarde. Une conception Zero Trust ne peut pas réussir si toutes les parties n’adhèrent pas à l’état d’esprit « Assume Breach ».  

Si vous acceptez que ce n’est pas une question de savoir si, mais quand, alors vous devez être prêt à vous rétablir après une attaque dans un scénario du pire cas — pas seulement celui attendu. 

C’est pourquoi les choix d’architecture comptent davantage que les listes de contrôle de durcissement. Le principe du moindre privilège doit être appliqué afin qu’aucun individu ne puisse, à lui seul, détruire les données de sauvegarde d’une entreprise. La segmentation des fonctions garantit que le logiciel de sauvegarde et le stockage de sauvegarde ne relèvent pas du même domaine de confiance.  

La segmentation des domaines d’authentification empêche qu’une compromission dans un plan d’identité ne se propage en cascade vers un autre. Et la segmentation réseau réduit les chemins qu’un attaquant peut emprunter pour atteindre les systèmes critiques. 

Les fonctionnalités de durcissement ne répondent pas à la question centrale : Que se passe‑t‑il lorsque l’attaquant a déjà les clés ?  

C’est pourquoi Object First est particulièrement engagé sur Zero Trust et le démontre par des tests indépendants attestant que le système se comporte comme prévu, même lorsque tous les secrets sont connus. 

Pourquoi la transparence a historiquement été découragée 

Des tests de sécurité pertinents exigent indépendance, transparence et reproductibilité. Les tests internes du fournisseur, à eux seuls, sont insuffisants, car ils ne peuvent pas être dissociés des pressions et des incitations internes.  

Les tests indépendants réalisés par des tiers fournissent une évaluation externe de la conformité du comportement du système aux affirmations du fournisseur, en particulier dans des conditions adverses. Ces rapports doivent être publiés intégralement, et non pas cités de manière sélective pour créer une façade positive artificielle et trompeuse. 

Les organisations devraient également avoir la possibilité de tester elles‑mêmes le système ou de mandater un tiers pour le faire. Beaucoup d’organisations n’auront ni le temps ni les ressources pour réaliser de tels tests, mais la possibilité de le faire est essentielle. Si le contrat de licence d’un fournisseur interdit les tests, cette restriction doit être considérée comme un signal d’alerte. Un système qui ne peut pas être testé ne peut pas être digne de confiance. 

La plupart des organisations n’ont ni le temps ni l’expertise pour valider chaque affirmation de sécurité. C’est pourquoi les fournisseurs doivent apporter des preuves et mériter la confiance, pas la présumer. 

Object First met ses paroles en actes 

Les tests indépendants sont aussi le seul moyen fiable de valider les affirmations relatives à l’immutabilité, au Zero Access et à la segmentation. Ce ne sont pas des caractéristiques que l’on peut évaluer uniquement à partir de la documentation ; elles doivent être démontrées via des tests d’intrusion externes qui simulent les conditions rencontrées lors d’une attaque active par rançongiciel. C’est particulièrement important pour Absolute Immuabilité, qui part du principe que l’attaquant sait tout ce que sait l’administrateur et ne peut malgré tout ni modifier ni supprimer les données de sauvegarde. 

Le stockage Sauvegarde doit servir de dernière ligne de défense lorsque tous les autres contrôles échouent, et de première ligne de reprise lorsque l’organisation doit récupérer ses données. 

Documentation ouverte et définition de la surface d’attaque 

Un fournisseur doit également être en mesure de définir clairement sa surface d’attaque. Sans cette définition, ni les tests internes ni les tests externes ne peuvent être pertinents. Un système de stockage de sauvegarde bien conçu présente une surface d’attaque réduite, strictement délimitée, avec des frontières, des protocoles et des comportements clairement documentés. 

Un fournisseur qui ne documente pas ces composants demande aux organisations de faire confiance à une boîte noire. Sans documentation, les organisations ne peuvent pas comprendre comment le système fonctionne, ce qu’il expose, ni comment il doit être évalué. Lorsque les fournisseurs évitent la documentation, ils maintiennent de fait les organisations « dans l’ignorance » quant à la conception du système et à son comportement. 

Une documentation cachée ou incomplète crée un risque simple mais grave : les organisations ne savent pas sur quoi elles s’appuient. Elles ne peuvent pas tester ce qu’elles ne voient pas, et elles ne peuvent pas évaluer ce qu’elles ne peuvent pas définir. La transparence n’exige pas de submerger les équipes IT et sécurité de détails inutiles ; elle exige de documenter la véritable surface d’attaque et de maintenir cette documentation alignée sur des schémas de déploiement crédibles et des modèles de menace réalistes. 

Comment les acheteurs devraient évaluer les affirmations de sécurité des fournisseurs 

Chaque fournisseur demande, au final, aux clients de lui faire confiance. La question est de savoir si cette confiance est méritée. Les équipes IT et sécurité devraient rechercher des explications claires de l’architecture de sécurité du fournisseur, y compris ce que le fournisseur suppose qu’il se produira et ne se produira pas lors d’une attaque. Elles devraient exiger une définition de la surface d’attaque, une documentation reflétant l’usage en conditions réelles, et des termes de licence permettant des tests indépendants. 

Surtout, les clients devraient exiger des tests indépendants réalisés par des tiers qui valident l’immutabilité du système, les contrôles Zero Access et la segmentation en conditions adverses. Ils devraient également rechercher l’engagement d’un fournisseur envers le CISA Conçu pour la sécurité pledge, qui signale une volonté d’aborder ouvertement les défis de sécurité. 

Les affirmations d’un fournisseur doivent être étayées par des actes, pas par des mots. La transparence est ce qui rend ces affirmations vérifiables.