Una empresa de investigación farmacéutica evaluó a dos proveedores para un contrato de gestión de datos de ensayos clínicos, ambos con historiales sin violaciones en los últimos tres años. La evaluación trató esos historiales limpios como indicadores positivos equivalentes. Después, las evaluaciones de seguridad divergieron de forma marcada. El proveedor A tenía un programa de prevención maduro: seguridad de correo electrónico que bloqueaba el noventa y cuatro por ciento de los intentos de phishing, una solución EDR que detectó y puso en cuarentena tres muestras de malware antes de su ejecución y un programa de gestión de vulnerabilidades que había aplicado el parche a una vulnerabilidad crítica en menos de cuarenta y ocho horas desde su publicación. Su equipo de operaciones de seguridad había documentado tres intentos de ataque significativos evitados en los dieciocho meses anteriores. Compartieron estos registros de cuasi incidentes como prueba de la eficacia de su programa de seguridad. El proveedor B tenía un historial igualmente limpio, logrado por otros medios: un enfoque más conservador con menor exposición a amenazas, menos sistemas expuestos al exterior y una superficie de ataque más pequeña que, sencillamente, había atraído menos la atención de los atacantes. Cuando la empresa farmacéutica indagó en los historiales de detección y prevención de ambos proveedores, la diferencia se hizo evidente: el proveedor A había sido atacado activamente y había evitado los ataques con éxito. El proveedor B había sufrido menos actividad de ataque y tenía menos datos con los que demostrar su capacidad de prevención. Los historiales sin violaciones eran idénticos. Los programas de seguridad que los respaldaban no lo eran.
¿Qué es realmente el problema del equilibrio entre detección y prevención?
El problema del equilibrio entre detección y prevención en la evaluación de la seguridad de proveedores es el desafío de entender si el historial sin violaciones de un proveedor refleja una capacidad de prevención eficaz o simplemente una baja exposición a ataques. Ambas producen el mismo historial. Solo la capacidad de prevención ofrece garantía de que el programa de seguridad del proveedor funcionará con eficacia cuando aumente la presión de los ataques, algo que ocurrirá si sus datos o su acceso a plataformas lo convierten con el tiempo en un objetivo de mayor valor.
La brecha de visibilidad de los cuasi incidentes es el problema estructural de medición. El éxito de la prevención se mide por hechos que no ocurrieron: correos de phishing bloqueados antes de llegar a los usuarios, malware puesto en cuarentena antes de ejecutarse, vulnerabilidades parcheadas antes de ser explotadas. Estos éxitos quedan registrados en los datos operativos del programa de seguridad (tasas de bloqueo de la seguridad de correo, registros de cuarentena de EDR, plazos de corrección de vulnerabilidades), pero no suelen divulgarse en las evaluaciones de violaciones de los proveedores porque no son violaciones. El historial de violaciones solo refleja los fallos del programa de prevención. El historial de cuasi incidentes refleja sus éxitos.
El problema de calibrar la presión de ataque es la dimensión de la cadena de suministro. Los proveedores que custodian datos valiosos (propiedad intelectual, datos financieros o de salud regulados, datos de investigación) atraen una presión de ataque mayor que los proveedores con activos menos valiosos. Un proveedor cuyo programa de seguridad se ha puesto a prueba bajo una presión de ataque significativa y ha evitado violaciones con éxito ofrece una garantía de calidad distinta a la de un proveedor que ha atraído una actividad de ataque mínima. El historial sin violaciones es idéntico. La calidad de la garantía es distinta.
- Historial sin violaciones que no distingue una prevención eficaz de una baja exposición a ataques
- Datos de cuasi incidentes no divulgados o no solicitados en las evaluaciones de proveedores
- Capacidad de prevención no demostrada sin historial de exposición a ataques
- Se presume equivalencia entre historiales sin violaciones de distinto origen
- Sin evaluación de la presión de ataque: no se evalúa el valor de los datos del proveedor ni su atractivo como objetivo
Por qué es importante
El equilibrio entre detección y prevención es importante para TPRM porque los objetivos de la cadena de suministro se eligen precisamente por su acceso a datos de alto valor, y los proveedores que custodian o procesan datos de alto valor se enfrentarán a una presión de ataque creciente a medida que los actores de amenazas conozcan el valor de esos datos. Un proveedor cuyo historial sin violaciones se basa en una baja exposición a ataques y no en una prevención eficaz puede no mantener ese historial cuando aumente la presión de ataque. Entender el origen del historial sin violaciones (capacidad de prevención o baja exposición) orienta la evaluación de riesgos prospectiva que requiere TPRM.
Dónde se equivocan la mayoría de los equipos
El error más habitual es tratar el historial de violaciones como principal indicador de la eficacia de la seguridad sin evaluar la actividad de prevención que lo sustenta. El programa de prevención es más informativo que su registro de fallos.
- Historial de violaciones tratado como principal indicador de eficacia
- No se solicita el historial de cuasi incidentes en las evaluaciones de seguridad
- Datos operativos del programa de prevención sin evaluar: tasas de bloqueo, tasas de cuarentena, plazos de parches
- Presión de ataque sin evaluar: valor de los datos del proveedor y su atractivo para los actores de amenazas
- Se presume equivalencia de historiales limpios con programas de seguridad de distinto origen
Cómo se ve una buena práctica
Los programas maduros de evaluación de detección y prevención solicitan datos operativos de cuasi incidentes junto con los historiales de violaciones (en concreto, tasas de bloqueo de la seguridad de correo, tasas de prevención de malware, plazos de corrección de vulnerabilidades y cualquier intento de ataque significativo evitado y documentado) para evaluar la capacidad de prevención y no solo el historial de prevención.
- Historial de cuasi incidentes solicitado: ataques significativos evitados en los últimos dos años
- Métricas del programa de prevención: tasas de bloqueo de correo, tasas de cuarentena de EDR, plazos de aplicación de parches
- Evaluación de la presión de ataque: valor de los datos del proveedor y ataques dirigidos en el pasado
- Capacidad de prevención frente a historial de prevención: distinguir la eficacia del programa del historial de exposición
- Evaluación prospectiva: si el programa mantendrá su historial ante una presión de ataque creciente
Herramientas
Seguridad de correo electrónico: Proofpoint, Mimecast con informes de tasas de bloqueo
Las plataformas de seguridad de correo electrónico ofrecen estadísticas de tasa de bloqueo que son un indicador directo de la eficacia del programa de prevención: la fracción de correos maliciosos detectados y bloqueados antes de llegar a los usuarios. Para los profesionales de TPRM, pedir a los proveedores su tasa de bloqueo de seguridad de correo y el volumen de intentos de phishing bloqueados en los últimos doce meses ofrece una métrica concreta de la eficacia del programa de prevención.
Desafíos de gobernanza
El desafío de gobernanza de la divulgación de cuasi incidentes es la sensibilidad de los proveedores. Los proveedores se resisten a revelar que fueron atacados, incluso cuando los ataques se evitaron con éxito, porque la divulgación da la impresión de que son un objetivo. La solución de gobernanza es plantear las solicitudes de cuasi incidentes como prueba de capacidad de prevención y no como prueba de vulnerabilidad, lo que exige explicar tanto al equipo de evaluación como al proveedor por qué los ataques evitados son indicadores positivos.
- Solicitar el historial de cuasi incidentes planteado como prueba de capacidad de prevención
- Solicitar métricas del programa de prevención: tasas de bloqueo, tasas de cuarentena, plazos de parches
- Evaluar la presión de ataque: valor de los datos del proveedor e historial de ataques dirigidos a su sector
- Distinguir el origen de los historiales limpios en la evaluación de riesgos
- Ponderar la capacidad de prevención junto con el historial de violaciones en la evaluación de la postura de seguridad
Si usted forma parte de un equipo pequeño
En cada evaluación de proveedores, haga dos preguntas además de la pregunta sobre el historial de violaciones. Primera: en los últimos dos años, ¿han tenido eventos de seguridad significativos que se detectaron y evitaron antes de convertirse en violaciones? Si es así, ¿de qué tipos de ataque se trató y cómo se detuvieron? Segunda: ¿cuál es su tasa de bloqueo de correos maliciosos y cuántas muestras de malware ha puesto en cuarentena su EDR antes de su ejecución en los últimos doce meses? Esas dos preguntas revelan si el historial sin violaciones se basa en la capacidad de prevención o en una baja exposición a ataques.
- Solicitar el historial de ataques significativos evitados junto con el historial de violaciones
- Solicitar la tasa de bloqueo de seguridad de correo y las estadísticas de cuarentena de EDR
- Evaluar la presión de ataque: valor de los datos del proveedor y ataques dirigidos a su sector
- Distinguir la capacidad de prevención del historial de prevención
Qué exigir
Pregunte directamente:
“Más allá del historial de violaciones, ¿puede compartir los cuasi incidentes en los que se detectaron y evitaron ataques significativos en los últimos dos años, junto con su tasa de bloqueo de seguridad de correo y sus estadísticas de cuarentena de EDR? Consideramos la prevención exitosa un indicador positivo de capacidad.”
Evidencia que debe esperar
- Historial de cuasi incidentes: ataques significativos evitados
- Tasa y volumen de bloqueo de la seguridad de correo electrónico
- Estadísticas de cuarentena de EDR
- Plazos de aplicación de parches para vulnerabilidades críticas
A un proveedor que confirma un historial sin violaciones se le deben pedir las métricas del programa de prevención que lo explican. El historial de violaciones muestra lo que no se detuvo. Las métricas de prevención muestran lo que sí se detuvo.
Cómo demostrarlo
- Registros de la evaluación del historial de cuasi incidentes
- Métricas del programa de prevención
- Evaluación de la presión de ataque
- Evaluación del equilibrio entre detección y prevención
Conclusión clave
Cero violaciones. Tres ataques evitados. Ciento cuarenta y siete mil correos de phishing bloqueados. Tres muestras de malware en cuarentena. Una vulnerabilidad crítica parcheada en cuarenta y ocho horas. Están presentes tanto el historial sin violaciones como un abundante historial de cuasi incidentes. La evaluación que solo pregunta por violaciones ve el registro de fallos, que está vacío, y pasa por alto la prueba de capacidad de prevención. El programa de prevención se demuestra por lo que detuvo. El historial de violaciones solo refleja lo que no detuvo. Pida el historial de cuasi incidentes. Pida las tasas de bloqueo. El historial sin violaciones es el resultado. El programa de prevención es la explicación.