Três sinais de que seu fornecedor de segurança cibernética pode estar manipulando o sistema
Para você que participou do RSA Conference em abril, tenho certeza de que o bombardeio de e-mails de fornecedores, telefonemas e solicitações de reuniões do LinkedIn está em andamento. Embora eu aposte que muitos dos fornecedores que imploram por reuniões oferecem produtos ou serviços que não estão no seu radar para 2023-2024, provavelmente há alguns que você gostaria de testar para ver se eles podem oferecer resultados melhores do que o que você está usando atualmente. Para esses fornecedores, após a reunião introdutória obrigatória, alguma discussão técnica ou mesmo uma chamada de referência do cliente, será oferecida uma Prova de Conceito (às vezes também chamada de Prova de Valor). Esta tradição consagrada pelo tempo permite que você “teste o produto por si mesmo.”
Durante a PoC, o fornecedor tenta mostrar a você como seu produto interrompe mais ataques, detecta mais e-mails de phishing, localiza mais sites maliciosos e afins para validar suas reivindicações de marketing. A intenção por trás da oferta de uma PoC faz todo o sentido e deve ajudar os compradores a evitar a compra de produtos com recursos de venda excessiva. Mas, infelizmente, com muita frequência, os produtos que pareciam ter um bom desempenho durante uma PoC não fornecem resultados semelhantes depois de implantados inteiramente no ambiente do comprador.
Como isso pode ser? Ao longo dos meus quase 20 anos de construção, venda e marketing cíber segurança produtos, já vi quase todas as maneiras pelas quais os fornecedores tentam manipular esses PoCs. Aqui estão três sinais de que seu PoC pode estar abaixo do normal.
“Fornecemos todos os dados em nosso ambiente, para que você não precise se preocupar com isso.”
O fato é que testar minuciosamente cíber segurança produtos que dependem de algum tipo de ameaça externa ou uma grande quantidade de dados internos para treinar modelos de aprendizado de máquina podem ser complicados. Como nenhum profissional de segurança concordaria ou deveria concordar em testar um produto desconhecido em seu ambiente de produção, eles precisariam de um ambiente de teste razoavelmente robusto para testar esse novo produto. Dado esse requisito, será tentador aceitar a oferta de um fornecedor para realizar o teste usando seus dados no ambiente do fornecedor. Se você pensar por um minuto, é como pedir aos alunos que escrevam as perguntas para o exame final. Você não acha que testar no ambiente do fornecedor com seus dados pode distorcer os resultados a seu favor? Claro. Embora ninguém queira que seus PoCs demorem mais do que uma temporada de hóquei da NHL, você precisará fornecer dados para examinar um produto adequadamente. Alguns fornecedores podem oferecer o uso de algumas ferramentas que simulam ataques, o que é razoável, desde que você, como cliente em potencial, tenha a opção de usá-las ou não. A melhor maneira de atenuar o comprimento do PoC é selecionar dois ou três casos de uso que você está direcionando, no máximo, e fornecer os dados necessários apenas para esses casos de uso. Idealmente, os produtos que você testar facilitarão a integração dos produtos que geram os dados em seu ambiente.
“Qual versão estamos testando? É basicamente o nosso produto GA. Você não pode dizer a diferença.
Quando entrei no setor de segurança cibernética e me preparei para um PoC, pedimos aos clientes em potencial que montassem um servidor que atendesse aos nossos requisitos mínimos. Em seguida, eu instalaria manualmente o produto na máquina para que os participantes do PoC pudessem ver qual versão do produto usaríamos para o teste.
No mundo de hoje, onde o SaaS é o padrão, conhecer a versão do produto que você está testando pode parecer uma viagem até um buraco de minhoca. Infelizmente, ouvi histórias de terror de praticantes em que estavam em um PoC com um fornecedor e os resultados foram excelentes, então eles firmaram um contrato para comprar o produto. Avanço rápido de um mês ou dois, e os profissionais e a administração estão mais do que frustrados. O produto instalado em seu ambiente não se parece em nada com o que eles testaram. Faltam recursos, as integrações que eles usaram não foram encontradas e a história do fornecedor é: “Essa versão deve ser lançada em breve”. Em alguns casos, não vejo problema em usar uma versão de produto não lançada para uma PoC, desde que o fornecedor seja transparente com o cliente em potencial. Infelizmente, quando um cliente sente que um fornecedor está tentando esconder algo dele, um relacionamento cliente/fornecedor que deveria ser colaborativo pode instantaneamente se tornar combativo.
“Nunca perdemos uma ameaça durante um PoC.”
Em 1941, Ted Williams, também conhecido como O esplêndido estilhaço, teve uma temporada mágica na base, terminando sua temporada com o Boston Red Sox com uma média de rebatidas impressionante de 406 e uma porcentagem de base de 553. Muitos historiadores do beisebol argumentam que Ted Williams foi o rebatedor mais puro de todos os tempos. Até o momento, nenhum rebatedor na AL ou NL superou a média de 400 do ano. Então, o que Ted Williams tem a ver com um blog sobre PoCs de segurança cibernética? A questão é que nada, seja um produto de segurança cibernética ou o melhor batedor de todos os tempos, é sempre perfeito. Você pode testar um produto contra um conjunto específico de vetores de ameaças e o produto identifica todos eles? Absolutamente. Poderia fazê-lo consecutivamente com novas ameaças por dois dias, 5, 10 ou até 100 dias? Mas tão certo quanto eu sei que durante a temporada de 1941, Ted Williams rebateu 27 vezes, chegará o dia em que seu novíssimo cíber segurança produto perde uma ameaça que você pensou que iria detectar.
Durante uma PoC, se os resultados brutos do teste do produto não estiverem disponíveis imediatamente ou você perceber pessoas do fornecedor trabalhando no projeto que você nunca conheceu, seja avisado. Você está testemunhando uma equipe de vendas pedindo ajuda de desenvolvedores, pesquisadores de inteligência de ameaças ou engenheiros de software trabalhando em sua implantação, tentando descobrir por que eles não têm ameaças ou um recurso não está funcionando. Novamente, os defeitos de software podem surgir durante uma PoC? Absolutamente. Quando o fizerem, você poderia encontrar desenvolvedores e engenheiros depurando código ao vivo - com certeza. A chave aqui é a transparência. Fornecedores éticos serão francos com você se e quando um defeito surgir. Eles também explicarão por que uma ameaça, se houver, foi perdida durante um PoC. Lembre-se, ao executar a PoC de um produto, você deve comparar os resultados com o que está usando atualmente e com outros produtos que está testando, não com um sistema mítico que detecta continuamente 100% das ameaças. Você está procurando resultados significativamente melhores, não a perfeição.
PoC para as pessoas
Com tantos produtos no mercado reivindicando recursos, benefícios e resultados semelhantes, é quase impossível determinar o que funcionará melhor para você sem executar um PoC. Portanto, sou um fã do PoC, pois, quando executado de maneira justa, ele dá aos produtos concorrentes a chance de enfrentar o mundo real.
Deixe o melhor produto vencer.
