REFLEXIVO · LIDERAZGO · CIERRE DE SERIE
Esta semana analicé el riesgo de terceros desde el encuadre del lunes hasta el caso TechCorp Latam de ayer. El patrón que aparece en todos esos ángulos es el mismo que ha estado presente en todas las semanas anteriores: la organización puede tener toda la información técnica necesaria para entender el riesgo, y aun así no tomar decisiones sobre él porque el riesgo no ha llegado a quien tiene la autoridad para actuar.
Hoy quiero cerrar la semana con el ángulo que une todo lo anterior: cómo llevar el riesgo de terceros a la conversación ejecutiva, qué argumentos realmente funcionan, y por qué el argumento técnicamente correcto no siempre es el que produce decisiones.
EL ARGUMENTO QUE NO FUNCIONA
El argumento más natural para quien viene del mundo técnico es el argumento de mejores prácticas: el NIST CSF, la ISO 27001, los marcos de referencia de industria, todos ellos incluyen la gestión de riesgo de terceros como un componente necesario de un programa de seguridad maduro. Ese argumento es técnicamente correcto. Y en la mayoría de las reuniones ejecutivas donde lo he visto presentado, no produce decisiones.
La razón es estructural. El argumento de mejores prácticas compite con decenas de otras mejores prácticas que también están pendientes de implementación. Sin una razón específica para priorizar esta sobre las demás, la respuesta predecible es que se anota para el próximo ciclo de planificación. Que es exactamente lo que ocurrió con el acceso del integrador en TechCorp Latam, con las pruebas de continuidad que describí hace tres semanas, con la revisión de accesos internos de la semana pasada.
El problema no es que la gerencia no entienda que las mejores prácticas son importantes. Es que "es una buena práctica" no genera la urgencia necesaria para desplazar otras prioridades en una agenda ejecutiva ya cargada.
LAS TRES PALANCAS QUE SÍ FUNCIONAN
Lo que sí mueve la conversación ejecutiva sobre riesgo de terceros son tres tipos de argumento, todos ellos concretos, todos en el lenguaje en que la gerencia evalúa decisiones.
La primera palanca es el costo estimado de un incidente originado en un proveedor para esta organización específica. No el costo promedio de un incidente en la industria, que es un número abstracto. El costo calculado con los componentes que describí en la semana de vulnerabilidades: tiempo de inactividad directo, costo de recuperación técnica, investigación forense si hay datos comprometidos, remediación de infraestructura, impacto reputacional con los clientes relevantes para este negocio. Cuando ese número existe y se puede comparar con el costo de los controles básicos de esta semana, la conversación cambia de "es una buena práctica" a "es una decisión con retorno calculable."
La segunda palanca es la exposición regulatoria y de seguro activa hoy. Si la organización opera en un sector con regulación de seguridad de datos, como salud, finanzas o servicios al estado, la ausencia de controles sobre proveedores con acceso a datos puede ser un incumplimiento regulatorio vigente, no potencial. Si tiene una póliza de ciberseguridad, las condiciones de esa póliza pueden incluir requisitos sobre gestión de accesos de terceros que la organización no está cumpliendo, lo que puede afectar la cobertura en caso de incidente. Esos son costos concretos y presentes, no futuros.
La tercera palanca es el incidente reciente en un proveedor del mismo sector o en una organización comparable. Cuando otro actor del mismo mercado tiene un incidente originado en un tercero y esa información es pública, el riesgo abstracto de "puede pasarle a nuestra organización" se vuelve concreto de una forma que ningún argumento técnico puede replicar. El trabajo aquí es monitorear el sector, identificar esos incidentes cuando ocurren, y usarlos como punto de referencia en la conversación ejecutiva: "esto le pasó a una empresa de nuestro tamaño y sector por este vector, y nosotros tenemos la misma exposición."
¿CÓMO ESTRUCTURAR LA CONVERSACIÓN?
La conversación ejecutiva sobre riesgo de terceros no empieza con la solución. Empieza con el diagnóstico en términos que la gerencia puede evaluar.
El diagnóstico tiene tres elementos: cuántos proveedores tienen acceso a sistemas críticos (número concreto, no estimación), cuál es el nivel de control que la organización tiene sobre esos accesos (respuesta honesta a las preguntas del miércoles), y cuál es la exposición que eso representa en términos de costo potencial y de posición regulatoria.
Con ese diagnóstico sobre la mesa, la propuesta de acción tiene un punto de referencia concreto. No "necesitamos implementar un programa de gestión de riesgo de terceros", que suena a un proyecto largo y costoso. Sino "hay cuatro proveedores de soporte remoto con acceso permanente a sistemas críticos sin credenciales únicas ni logs de sesión; el costo de corregir eso esta semana es cero; el costo de no corregirlo lo estimamos en X si hay un incidente." Esa propuesta genera una decisión, no una postergación.
LO QUE ESTA SEMANA DEJA SOBRE LA MESA
Esta semana analicé el riesgo de terceros como la superficie de ataque que más crece y menos se gestiona. Lo que lo hace diferente del riesgo interno es una sola cosa: la organización no puede controlar la seguridad interna de sus proveedores. Pero sí puede gestionar la relación, definir qué condiciones exige, qué accesos otorga y en qué condiciones, qué monitorea, y qué pasa contractualmente si el proveedor tiene un incidente que la afecta.
El patrón que esta semana se suma a las anteriores es consistente. Cuatro semanas analizando dominios distintos, cuatro versiones del mismo problema central: la organización tiene la información para entender el riesgo, tiene los recursos para gestionar los controles básicos, y lo que falta es la cadena de decisión que convierte ese conocimiento en acción antes de que un incidente lo haga urgente.
Esa cadena no la construye la tecnología. La construye quien gestiona TI cuando traduce el riesgo técnico al lenguaje en que la gerencia toma decisiones, y cuando tiene el respaldo para actuar cuando la traducción funciona.
Si esta semana pudieras presentarle a la gerencia un número concreto: cuántos proveedores con acceso a sistemas críticos no tienen cláusula de seguridad en su contrato, ese número solo ya justifica una conversación que hoy probablemente no está ocurriendo. El riesgo de terceros no entra en la agenda ejecutiva porque alguien lo propone. Entra porque alguien lo hace visible con los datos correctos.
Artículo núcleo de la semana: El riesgo que viene de afuera: proveedores, terceros y la superficie de ataque que nadie mide.
#RiesgoTerceros #SupplyChainSecurity #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #TechCorpLatam #CyberLeadership #Liderazgo #Chile #GobernanzaTI #NISTCSF #ISO27001
Comentarios
Publicar un comentario