La ciberseguridad tiene un problema peculiar.
Todo el mundo dice que quiere reducir el riesgo. Pero con demasiada frecuencia, la forma en que evaluamos los productos recompensa algo más limitado: la rapidez con la que un proveedor puede demostrar valor en una prueba de concepto (PoC).
¿Se puede implementar rápidamente? ¿Puede funcionar sin agentes? ¿Puede generar un informe claro? ¿Puede alinearse con OWASP, NIST, la Ley de IA de la UE o el marco más reciente? ¿Puede cumplir con suficientes requisitos en la RFP?
La trampa de las casillas de verificación
Los equipos de seguridad están abrumados. Cada año trae una nueva superficie de ataque, categoría, marco y requisito de cumplimiento.
Así que los compradores simplifican. Crean tablas. Comparan características. Piden una implementación rápida, valor inmediato y cobertura del marco.
Eso tiene sentido. Pero tiene una consecuencia no deseada.
La forma en que evaluamos los productos de seguridad moldea lo que las startups construyen. Si el mercado recompensa el valor rápido de la PoC, los paneles sin agentes, la amplia cobertura de requisitos y los informes pulidos más que la profundidad, la precisión y la operacionalización, las startups construirán para ese mercado.
El tiempo rápido de obtención de valor es importante. La implementación sin agentes es importante. La cobertura del marco es importante. Pero cuando esos se convierten en la única evaluación, creamos un mercado donde las startups optimizan para las dos primeras semanas de una PoC en lugar de los próximos cinco años de reducción de riesgos empresariales.
La IA va a empeorar esto
Un equipo pequeño ahora puede crear con una apariencia atractiva una interfaz de usuario limpia, algunos flujos de trabajo, un informe pulido y suficiente mapeo de marcos para parecer creíble. Eso no significa que pueda sobrevivir en una empresa.
Nunca reemplazaríamos Salesforce con un CRM creado con una apariencia atractiva después de ver tres pantallas bonitas. Preguntaríamos si escala, se integra con el negocio, soporta permisos y flujos de trabajo, produce evidencia de auditoría, capacita a los usuarios y sobrevive años de uso operativo.
La seguridad merece el mismo estándar.
Los marcos son útiles. Las casillas de verificación no son suficientes.
Marcos como OWASP, NIST, la Ley de IA de la UE, MITRE y CIS proporcionan a los equipos un lenguaje común. El error es tratar cada requisito como una pregunta de sí o no.
Tomemos BOLA, Autorización a Nivel de Objeto Roto, el riesgo número uno en el Top 10 de API de OWASP. En términos sencillos, BOLA significa que un usuario puede acceder a los datos de otra persona cambiando un identificador.
Imagina que abro mi aplicación bancaria y la aplicación llama:
GET /accounts/12345
La API devuelve mi nombre, correo electrónico, saldo, transacciones recientes y los últimos cuatro dígitos de mi cuenta bancaria. Si un atacante cambia el ID y obtiene los detalles de la cuenta de otro cliente, eso es BOLA.
En muchas evaluaciones, la prueba es obvia: un escáner envía 1.000 llamadas a la API en pocos segundos, cambiando rápidamente las ID. La mayoría de las herramientas pueden detectarlo. Es ruidoso, rápido y fácil de reconocer.
Los atacantes reales son más pacientes. Pueden enumerar lentamente durante horas o días, usar tokens válidos, cambiar un valor cada pocos minutos y moverse entre cuentas, puntos finales, sesiones, regiones o unidades de negocio. Cada solicitud puede parecer normal por sí sola.
Agentes de IA lo empeoran. Si los agentes están conectados a estas API, los atacantes pueden usarlos para explorar y explotar rutas de autorización débiles más rápidamente. La vulnerabilidad de la API ya era grave. El acceso agéntico la hace escalable.
En Salt, invertimos mucho en un motor de intención de big data para detectar este comportamiento lento y discreto: no solo si alguien cambió una ID, sino si su comportamiento muestra la intención de enumerar objetos a los que no debería acceder.
Los equipos que probaron esto entendieron la diferencia. Pero muchas evaluaciones no tenían una forma clara de puntuarlo. Si dos proveedores mostraban “BOLA detectado” en la prueba ruidosa, ambos obtenían la misma marca de verificación.
La profundidad desapareció en la hoja de cálculo.
La sala de exposición no es la carretera
Una PoC es la sala de exposición. La producción es la carretera.
En la sala de exposición, todo está controlado. El conjunto de datos es limitado. El proveedor está observando de cerca. El panel de control está limpio. El informe se ve bien.
Luego la solución se pone en marcha y los equipos reales la heredan.
AppSec clasifica los hallazgos. El SOC decide qué es importante. Ingeniería necesita tickets que pueda solucionar. Riesgos necesita pruebas. Las unidades de negocio necesitan apropiación. Las herramientas existentes necesitan integración.
A menudo, los evaluadores no son los usuarios diarios. Por eso la operacionalización es importante.
La verdadera prueba no es la claridad de la primera semana. Es si el producto sigue generando valor seis meses después, en todas las unidades de negocio, equipos distribuidos, datos ruidosos, excepciones, lagunas de propiedad y atacantes reales.
Lo mismo se aplica al proveedor: ¿ayudan a construir el programa, capacitan a los equipos e impulsan la adopción, o solo reaccionan después de que se firma el acuerdo?
Lo aprendimos por las malas
En Salt, lo aprendimos por las malas.
Empezamos con la tecnología. Nos centramos primero en los problemas más difíciles: análisis de comportamiento profundo, detección precisa, patrones de ataque complejos y una comprensión en tiempo de ejecución que los enfoques superficiales a menudo pasan por alto.
Algunos clientes entendieron de inmediato por qué esa profundidad era importante. Pero muchas evaluaciones no estaban diseñadas para medirla. Estaban diseñadas para comparar columnas: ¿se implementa rápidamente, es compatible con este marco, tiene este informe y muestra algo impresionante en la primera reunión?
Eso nos obligó a aprender una lección importante: la profundidad importa, pero también debe presentarse de una manera que el mercado pueda adoptar.
Así que construimos el camino: valor sin implementación, visibilidad y gobernanza sin agentes, y luego protección completa en tiempo de ejecución. Facilitar el inicio, sin renunciar a la profundidad necesaria para asegurar realmente una empresa.
Eso llevó más de ocho años. La verdadera profundidad de seguridad es difícil de construir. Si las evaluaciones no la miden, menos empresas invertirán en ella.
Evalúe el camino, no solo la sala de exposición
El ecosistema de startups responde a los incentivos.
Si los compradores recompensan los paneles de control del primer día, los mapeos amplios de marcos y la implementación sin fricciones por encima de todo lo demás, los proveedores optimizarán para eso.
Así que pregunte qué no puede ver la herramienta sin una integración más profunda o visibilidad en tiempo de ejecución. Pregunte qué tan profundamente cubre cada requisito y cómo se comporta cuando el entorno es caótico. Pregunte qué sucede seis meses después, cuando aparecen equipos reales, flujos de trabajo, atacantes y consecuencias.
El valor rápido importa. Pero tiene que convertirse en un valor más profundo.
Los POVs importan. Las RFPs importan. Los marcos importan.
Pero no son el objetivo.
El objetivo es hacer que la empresa sea más segura.
Si queremos que las startups construyan para eso, tenemos que evaluar para eso.
Los agentes de IA impulsan la innovación, pero también introducen riesgos imprevistos. La plataforma de seguridad Agentic Security Platform™ de Salt le brinda visibilidad y control completos, para que pueda reducir riesgos, cumplir con la normativa y mantenerse resiliente. Reserve una demostración para obtener más información.