Tres señales de que su proveedor de ciberseguridad podría estar jugando con el sistema
Para aquellos de ustedes que asistieron a la Conferencia RSA en abril, estoy seguro de que el bombardeo de correos electrónicos de proveedores, llamadas telefónicas y solicitudes de reuniones de LinkedIn está en marcha. Si bien apuesto a que muchos de los proveedores que piden reuniones ofrecen productos o servicios que no están en su radar para 2023-2024, probablemente haya algunos que le gustaría poner a prueba para ver si pueden ofrecer mejores resultados que lo que estás usando actualmente. Para esos proveedores, después de la reunión introductoria obligatoria, alguna discusión técnica o incluso una llamada de referencia del cliente, se le ofrecerá una Prueba de concepto (a veces también llamada Prueba de valor). Esta antigua tradición le permite “pruebe el producto usted mismo.”
Durante el PoC, el proveedor intenta mostrarle cómo su producto detiene más ataques, detecta más correos electrónicos de phishing, detecta más sitios web maliciosos y similares para validar sus afirmaciones de marketing. La intención detrás de ofrecer un PoC tiene mucho sentido y debería ayudar a los compradores a evitar comprar productos con capacidades de sobreventa. Pero, lamentablemente, con demasiada frecuencia, los productos que parecían funcionar bien durante una prueba de concepto no ofrecen resultados similares una vez que se implementan por completo en el entorno del comprador.
¿Cómo puede ser esto? Durante mis casi 20 años de construir, vender y comercializar los riesgos de seguridad cibernética productos, he visto casi todas las formas en que los proveedores intentan jugar con estos PoC. Aquí hay tres señales de que su PoC podría ser menos que aceptable.
"Proporcionamos todos los datos en nuestro entorno, para que no tenga que preocuparse por eso".
El hecho es que probando a fondo los riesgos de seguridad cibernética Los productos que se basan en algún tipo de amenaza externa o una gran cantidad de datos internos para entrenar modelos de aprendizaje automático pueden ser engorrosos. Dado que ningún profesional de la seguridad aceptaría, o debería, aceptar probar un producto desconocido en su entorno de producción, necesitará un entorno de prueba razonablemente sólido para poner a prueba este nuevo producto. Dado este requisito, será tentador aceptar la oferta de un proveedor para realizar la prueba utilizando sus datos en el entorno del proveedor. Si lo piensa por un minuto, es como pedirles a los estudiantes que escriban las preguntas para su examen final. ¿No cree que las pruebas en el entorno del proveedor con sus datos podrían sesgar los resultados a su favor? Por supuesto. Si bien nadie quiere que sus PoC tomen más tiempo que una temporada de hockey de la NHL, deberá proporcionar datos para examinar un producto correctamente. Algunos proveedores pueden ofrecer el uso de algunas herramientas que simulan ataques, lo cual es razonable, siempre que usted, como cliente potencial, tenga la opción de usarlas o no. La mejor manera de mitigar la duración de la PoC es seleccionar dos o tres casos de uso a los que se dirige, como máximo, y proporcionar los datos necesarios solo para esos casos de uso. Idealmente, los productos que pruebe facilitarán la integración de los productos que generan los datos en su entorno.
“¿Qué versión estamos probando? Es más o menos nuestro producto GA. No puedes notar la diferencia.
Cuando ingresé a la industria de la ciberseguridad y me preparé para una prueba de concepto, les pedimos a los clientes potenciales que crearan un servidor que cumpliera con nuestros requisitos mínimos. Luego, instalaba manualmente el producto en la máquina para que los participantes de PoC pudieran ver qué versión del producto íbamos a usar para la prueba.
En el mundo actual, donde SaaS es el estándar, conocer la versión del producto que está probando puede sentirse como un viaje por un agujero de gusano. Lamentablemente, escuché historias de horror de practicantes en las que estaban en un PoC con un proveedor y los resultados fueron sobresalientes, por lo que firmaron un contrato para comprar el producto. Avance rápido un mes o dos, y los profesionales y la gerencia están más que frustrados. El producto instalado en su entorno no se parece en nada a lo que probaron. Faltan características, las integraciones que usaron no se encuentran por ninguna parte y la historia del proveedor es: "Esa versión debería estar disponible pronto". En algunos casos, no veo ningún problema con el uso de una versión de producto inédita para una prueba de concepto siempre que el proveedor sea transparente con el posible cliente. Desafortunadamente, cuando un cliente siente que un proveedor está tratando de ocultarle algo, una relación cliente/proveedor que debería ser colaborativa puede volverse combativa instantáneamente.
“Nunca hemos pasado por alto una amenaza durante un PoC”.
En 1941, Ted Williams, también conocido como La astilla espléndida, tuvo una temporada mágica en el plato, terminando su temporada con los Medias Rojas de Boston con un asombroso promedio de bateo de .406 y un porcentaje de embase de .553. Muchos historiadores del béisbol argumentan que Ted Williams fue el bateador más puro que jamás haya jugado el juego. Hasta la fecha, ningún bateador en la Liga Americana o la Liga Nacional ha eclipsado el promedio de .400 del año. Entonces, ¿qué tiene que ver Ted Williams con un blog sobre PoC de ciberseguridad? El punto es que nada, ya sea un producto de ciberseguridad o el mejor bateador para jugar, es siempre perfecto. ¿Puede probar un producto contra un conjunto específico de vectores de amenazas y el producto los identifica a todos? Absolutamente. ¿Podría hacerlo consecutivamente con nuevas amenazas durante dos días, 5, 10 o incluso 100 días? Pero tan seguro como sé que durante esa temporada de 1941, Ted Williams se ponchó 27 veces, llegará un día en que su nuevo y brillante los riesgos de seguridad cibernética producto pierde una amenaza que pensó que detectaría.
Durante una prueba de concepto, si los resultados sin procesar de la prueba del producto no están disponibles de inmediato o si nota que personas del proveedor trabajan en el proyecto que nunca conoció, tenga cuidado. Está siendo testigo de un equipo de ventas que solicita ayuda de desarrolladores, investigadores de inteligencia de amenazas o ingenieros de software que trabajan en su implementación, tratando de averiguar por qué les faltan amenazas o si una función no funciona. De nuevo, ¿pueden surgir defectos de software durante una prueba de concepto? Absolutamente. Cuando lo hagan, ¿podría encontrar desarrolladores e ingenieros depurando código en vivo? Seguro. La clave aquí es la transparencia. Los proveedores éticos serán sinceros con usted siempre y cuando surja un defecto. También explicarán por qué se pasó por alto una amenaza, si la hubo, durante una prueba de concepto. Recuerde, al ejecutar una PoC de producto, debe comparar los resultados con lo que está usando actualmente y con otros productos que está probando, no con un sistema mítico que detecta continuamente el 100 % de las amenazas. Está buscando resultados significativamente mejores, no la perfección.
PoC para la gente
Con tantos productos en el mercado que afirman capacidades, beneficios y resultados similares, es casi imposible determinar qué funcionará mejor para usted sin ejecutar un PoC. Por lo tanto, soy un fanático del PoC ya que, cuando se ejecuta de manera justa, brinda a los productos de la competencia la oportunidad de competir cara a cara en el mundo real.
Que gane el mejor producto.
