Trois signes que votre fournisseur de cybersécurité pourrait jouer avec le système
Pour ceux d'entre vous qui ont assisté à la RSA Conference en avril, je suis sûr que le bombardement d'e-mails, d'appels téléphoniques et de demandes de réunion LinkedIn est en cours. Bien que je parie que de nombreux fournisseurs qui demandent des réunions proposent des produits ou des services qui ne sont pas sur votre radar pour 2023-2024, il y en a probablement une poignée que vous aimeriez mettre à l'épreuve pour voir s'ils peuvent fournir de meilleurs résultats que ce que vous utilisez actuellement. Pour ces fournisseurs, après la réunion d'introduction obligatoire, une discussion technique ou même un appel de référence client, une preuve de concept (parfois également appelée preuve de valeur) vous sera proposée. Cette tradition séculaire vous permet de "testez le produit par vous-même."
Pendant le PoC, le fournisseur tente de vous montrer comment son produit arrête plus d'attaques, détecte plus d'e-mails de phishing, repère plus de sites Web malveillants, etc., pour valider ses allégations marketing. L'intention derrière l'offre d'un PoC est parfaitement logique et devrait aider les acheteurs à éviter d'acheter des produits avec des capacités de survente. Mais malheureusement, trop souvent, les produits qui semblaient bien fonctionner lors d'un PoC ne donnent pas les mêmes résultats une fois entièrement déployés dans l'environnement de l'acheteur.
Comment se peut-il? Au cours de mes presque 20 années de construction, de vente et de marketing les services de cybersécurité produits, j'ai vu à peu près toutes les façons dont les fournisseurs essaient de jouer à ces PoC. Voici trois signes que votre PoC pourrait être inférieur à ce qui précède.
"Nous fournissons toutes les données de notre environnement, vous n'avez donc pas à vous en soucier."
Le fait est que des tests approfondis les services de cybersécurité les produits qui s'appuient sur une sorte de menace externe ou sur une grande quantité de données internes pour former des modèles d'apprentissage automatique peuvent être fastidieux. Étant donné qu'aucun professionnel de la sécurité n'accepterait ou ne devrait accepter de tester un produit inconnu dans son environnement de production, il aura besoin d'un environnement de test raisonnablement robuste pour mettre ce nouveau produit à l'épreuve. Compte tenu de cette exigence, il sera tentant d'accepter l'offre d'un fournisseur d'effectuer le test en utilisant ses données dans l'environnement du fournisseur. Si vous y réfléchissez une minute, cela revient à demander aux étudiants de rédiger les questions de leur examen final. Ne pensez-vous pas que tester dans l'environnement du fournisseur avec ses données pourrait fausser les résultats en sa faveur ? Bien sûr. Bien que personne ne souhaite que ses PoC prennent plus de temps qu'une saison de hockey dans la LNH, vous devrez fournir des données pour vérifier correctement un produit. Certains fournisseurs peuvent proposer d'utiliser des outils qui simulent des attaques, ce qui est raisonnable, tant que vous, en tant que client potentiel, avez le choix de les utiliser ou non. La meilleure façon d'atténuer la durée du PoC est de sélectionner deux ou trois cas d'utilisation que vous ciblez, au maximum, et de fournir les données nécessaires pour ces seuls cas d'utilisation. Idéalement, les produits que vous testez faciliteront l'intégration des produits qui génèrent les données dans votre environnement.
« Quelle version testons-nous ? C'est à peu près notre produit GA. Vous ne pouvez pas faire la différence.
Lorsque je suis entré dans l'industrie de la cybersécurité et que je me suis préparé pour un PoC, nous avons demandé à des clients potentiels de mettre en place un serveur répondant à nos exigences minimales. Ensuite, j'installerais manuellement le produit sur la machine afin que les participants au PoC puissent voir quelle version du produit nous allions utiliser pour les tests.
Dans le monde d'aujourd'hui, où le SaaS est la norme, connaître la version du produit que vous testez peut ressembler à un voyage dans un trou de ver. Malheureusement, j'ai entendu des histoires d'horreur de pratiquants où ils étaient dans un PoC avec un vendeur, et les résultats étaient exceptionnels, alors ils ont conclu un contrat pour acheter le produit. Avance rapide d'un mois ou deux, et les praticiens et la direction sont plus que frustrés. Le produit installé dans leur environnement ne ressemble en rien à ce qu'ils ont testé. Les fonctionnalités manquent, les intégrations qu'ils ont utilisées sont introuvables et l'histoire du fournisseur est la suivante : "Cette version devrait sortir bientôt". Dans certains cas, je ne vois aucun problème à utiliser une version de produit non publiée pour un PoC tant que le fournisseur est transparent avec le client potentiel. Malheureusement, lorsqu'un client a l'impression qu'un fournisseur essaie de lui cacher quelque chose, une relation client/fournisseur qui devrait être collaborative peut instantanément devenir combative.
"Nous n'avons jamais manqué une menace lors d'un PoC."
En 1941, Ted Williams, également connu sous le nom de Le splendide éclat, a connu une saison magique au marbre, terminant sa saison avec les Red Sox de Boston avec une moyenne au bâton stupéfiante de 406 et un pourcentage de base de 553. De nombreux historiens du baseball affirment que Ted Williams était le frappeur le plus pur à avoir jamais joué à ce jeu. À ce jour, aucun frappeur de l'AL ou de la NL n'a éclipsé la moyenne de .400 pour l'année. Alors, qu'est-ce que Ted Williams a à voir avec un blog sur les PoC de cybersécurité ? Le fait est que rien, qu'il s'agisse d'un produit de cybersécurité ou du meilleur frappeur à avoir jamais joué au jeu, n'est toujours parfait. Pouvez-vous tester un produit par rapport à un ensemble spécifique de vecteurs de menace et le produit les identifie-t-il tous ? Absolument. Pourrait-il le faire consécutivement avec de nouvelles menaces pendant deux jours, 5, 10 ou même 100 jours ? Mais aussi sûr que je sache qu'au cours de cette saison 1941, Ted Williams a frappé 27 fois, il viendra un jour où votre nouveau les services de cybersécurité le produit passe à côté d'une menace que vous pensiez qu'il détecterait.
Lors d'un PoC, si les résultats bruts du test du produit ne sont pas disponibles immédiatement ou si vous remarquez des personnes du fournisseur travaillant sur le projet que vous n'avez jamais rencontrées, soyez averti. Vous êtes témoin d'une équipe de vente qui appelle à l'aide de développeurs, de chercheurs sur les menaces ou d'ingénieurs logiciels travaillant sur votre déploiement, essayant de comprendre pourquoi ils manquent des menaces ou pourquoi une fonctionnalité ne fonctionne pas. Encore une fois, des défauts logiciels peuvent-ils apparaître lors d'un PoC ? Absolument. Quand ils le feront, pourriez-vous trouver des développeurs et des ingénieurs déboguant du code en direct - c'est sûr. La clé ici est la transparence. Les fournisseurs éthiques seront francs avec vous si et quand un défaut apparaît. Ils expliqueront également pourquoi une menace, le cas échéant, a été manquée lors d'une PoC. N'oubliez pas que lors de l'exécution d'un PoC de produit, vous devez comparer les résultats à ce que vous utilisez actuellement et aux autres produits que vous testez, et non à un système mythique qui détecte en permanence 100 % des menaces. Vous recherchez des résultats nettement meilleurs, pas la perfection.
PoC pour le peuple
Avec autant de produits sur le marché revendiquant des capacités, des avantages et des résultats similaires, il est presque impossible de déterminer ce qui fonctionnera le mieux pour vous sans exécuter un PoC. Par conséquent, je suis un fan du PoC car, lorsqu'il est exécuté équitablement, il donne aux produits concurrents une chance de s'affronter dans le monde réel.
Laissez le meilleur produit gagner.
