Quand un investisseur regarde sous le capot d’une plateforme en croissance, les questions portent sur les identifiants, les données et la réalité des corrections. Ce que nous avons appris en menant une due diligence technique de la première revue jusqu’à la remédiation vérifiée.
Plus tôt cette année, nous avons mené une due diligence technique sur une plateforme grand public en forte croissance, pour le compte d’investisseurs potentiels. Le produit fonctionnait, et certaines parties de sa conception étaient remarquablement pensées. La question que pose un investisseur diffère de celle que pose un utilisateur : l’ingénierie sous-jacente peut-elle porter la croissance que l’investissement doit financer ?
La première revue a mis au jour des constats sérieux. Quelques mois plus tard, les constats critiques avaient été clos et vérifiés en production. Le chemin entre ces deux positions mérite d’être décrit, car la plupart des plateformes à forte croissance doivent le parcourir un jour ou l’autre.
Nous avons d’abord examiné la data room, puis le code source, les bases de données, les comptes cloud, les services tiers et l’application mobile. Les constats étaient nombreux, et ils se regroupaient en quelques endroits que l’on s’attend à trouver sur presque toute plateforme construite rapidement par une petite équipe.
Des identifiants dans le gestionnaire de versions. Des clés de plusieurs services tiers y avaient été enregistrées au fil des années. Une fois que cela s’est produit, l’hypothèse prudente consiste à les considérer comme compromises tant qu’elles n’ont pas été renouvelées.
Des données réelles dans un environnement de test. Un environnement hors production contenait des données personnelles réelles, dont certaines particulièrement sensibles. Les environnements de test sont conçus pour la commodité et sont rarement protégés comme la production.
Un chiffrement correct en apparence. Les contenus étaient chiffrés avec un algorithme solide, utilisé d’une manière qui annulait sa protection. L’erreur est facile à commettre, et coûteuse à laisser en place.
Aucune visibilité sur la production. Sans supervision applicative ni alertes utiles, l’équipe ne pouvait pas mesurer un incident, et encore moins démontrer un niveau de service à un client.
L’équipe avait consacré son énergie au produit, ce qui est généralement le bon choix, jusqu’au jour où arrive l’argent de quelqu’un d’autre.
La remédiation était une condition de la transaction, et ce sont les ingénieurs de la plateforme qui ont fait le travail. Notre rôle était de le vérifier.
Chaque identifiant a été déplacé dans un coffre-fort de secrets géré puis renouvelé, et un balayage ciblé de tous les dépôts n’en a trouvé aucun oublié. Le chiffrement a été remplacé par un mode authentifié, avec une valeur nouvelle pour chaque fichier, et nous l’avons testé à nouveau sur des artefacts de production en plus du code. Les données sensibles stockées sur l’appareil ont été transférées dans le magasin de clés matériel de la plateforme. Le premier tour n’avait porté que sur les environnements de test ; nous avons donc ensuite examiné directement les consoles de production, avec un accès en lecture seule.
Nous avons volontairement repoussé les tests d’intrusion jusqu’à ce que les fondamentaux soient corrigés. Tant qu’une revue statique et de configuration produit encore des constats critiques, un test mené du point de vue d’un attaquant apporte peu et coûte plus cher. L’ordre raisonnable consiste à corriger ce qui est visible et à le vérifier avant de payer un test de ce qui ne l’est pas.
Une plateforme capable de répondre clairement à ces quatre questions aborde la négociation en bien meilleure position. Notre pôle cybersécurité réalise ce travail avant que la question ne soit posée.
Fait partie de la série Retours de nos projets. Recevez les nouvelles analyses par e-mail ou suivez le flux RSS.
Des normes appliquées de la même façon sur chaque mission, c’est ce qui permet à une petite équipe de développement de garder son rythme au-delà du premier mois. Voici ce que cela donne en pratique.
Les données non structurées sont la moitié la plus difficile du retrait d’une ancienne plateforme. Quand les documents sont au cœur du travail quotidien, l’objectif est une migration que les utilisateurs ne remarquent jamais, et le risque se loge ailleurs que dans le code.
L’essentiel de notre travail consiste à construire des logiciels qui appartiennent à un client. UMOYA Zone est différent. C’est une coentreprise, et être copropriétaire d’un produit nous a appris des choses que le travail pour des clients n’enseigne pas.
