TÉCNICO-GERENCIAL · RIESGO DE TERCEROS · CATEGORÍAS DE PROVEEDOR
Ayer planteé que el primer paso para gestionar el riesgo de terceros es construir el listado completo de proveedores con acceso a sistemas, redes o datos. Hoy quiero ir un paso más adelante: no todos los proveedores de ese listado representan el mismo nivel de exposición, y entender en qué se diferencian es lo que permite priorizar dónde actuar primero.
La distinción más relevante no es el tamaño del proveedor ni el valor económico del contrato. Es el tipo de acceso que el proveedor tiene y cuánto control tiene la organización sobre ese acceso. Un proveedor pequeño de soporte técnico que se conecta remotamente a los servidores puede representar un riesgo mayor que una empresa grande de consultoría que solo recibe reportes en PDF.
CATEGORÍA 1: SOPORTE REMOTO Y SERVICIOS GESTIONADOS
Esta es la categoría de mayor riesgo, y también la más frecuente en organizaciones medianas de la región. El proveedor de soporte técnico o el MSP (Managed Service Provider) tiene acceso directo a la red interna, generalmente con privilegios elevados, para poder diagnosticar y resolver problemas. Ese acceso es necesario para que el servicio funcione. El problema no es el acceso en sí: es cómo se gestiona.
En la mayoría de los casos, el proveedor de soporte accede usando credenciales propias que la organización no controla, a través de herramientas de acceso remoto que no siempre registran las sesiones en los logs de la organización, en horarios y frecuencias que la organización no siempre monitorea. Si esas credenciales del proveedor son comprometidas en el entorno del propio proveedor, el atacante tiene acceso inmediato a la red de la organización como si fuera un técnico autorizado.
El vector de compromiso más frecuente en este tipo de relación no es un ataque dirigido a la organización: es un ataque al proveedor de soporte, que tiene acceso a múltiples organizaciones simultáneamente. Comprometer al proveedor equivale a comprometer a todos sus clientes al mismo tiempo. Es un multiplicador de impacto que hace que los proveedores de soporte sean objetivos atractivos para atacantes sofisticados.
CATEGORÍA 2: INTEGRADORES E IMPLEMENTADORES
El integrador que implementó la infraestructura Fortinet, que configuró el switching Cisco, que migró los servidores al nuevo data center, tiene algo que ningún otro proveedor tiene: conocimiento profundo de la arquitectura interna. Sabe cómo está segmentada la red, cuáles son los sistemas críticos, qué credenciales se usaron durante la implementación, dónde están las excepciones de configuración que se hicieron por limitaciones del proyecto.
Ese conocimiento es valioso durante el proyecto. Después del proyecto, si el integrador mantiene acceso activo, ese conocimiento en manos incorrectas es una amenaza significativa. No porque el integrador sea necesariamente una amenaza interna, sino porque sus sistemas también pueden ser comprometidos, y quien los comprometiera tendría acceso a toda esa información de arquitectura más las credenciales activas en los sistemas de la organización.
El problema específico con esta categoría es la naturaleza de la relación: el integrador suele terminar el proyecto principal y luego quedarse en una relación de soporte o garantía más difusa, donde no hay una fecha de cierre clara y el acceso permanece activo "por si hay que hacer ajustes." Ese estado indefinido es exactamente el contexto que produce accesos post-proyecto como el que documenté en el caso TechCorp Latam.
ERROR COMÚN
Clasificar el riesgo del proveedor según el tamaño o la reputación de la empresa. Un proveedor grande y reconocido puede tener procesos de seguridad maduros, o puede tener los mismos problemas que cualquier organización mediana: contraseñas compartidas, sistemas sin parchear, empleados con acceso excesivo. El tamaño no es un proxy de seguridad. Lo que importa es qué tipo de acceso tiene el proveedor, qué evidencia puede presentar de sus controles, y qué mecanismos tiene la organización para monitorear ese acceso.
CATEGORÍA 3: SAAS NO GESTIONADOS POR TI
La proliferación de herramientas SaaS adoptadas por áreas de negocio sin pasar por un proceso de evaluación de TI es una de las formas más silenciosas en que crece la superficie de ataque. El área de ventas adopta un CRM en la nube. El área de RRHH empieza a usar una plataforma de gestión de talento. El equipo de marketing conecta herramientas de automatización a los sistemas de correo corporativo. Cada una de esas decisiones, tomada con lógica operacional completamente razonable, introduce un proveedor nuevo que procesa datos de la organización sin que TI haya evaluado sus controles de seguridad.
El riesgo aquí no es de acceso a la infraestructura interna, sino de exposición de datos. Si ese SaaS tiene una brecha, los datos de clientes, de empleados o de operaciones que estaban en la plataforma pueden quedar expuestos. Y la organización tiene responsabilidad sobre esos datos aunque el incidente haya ocurrido en los sistemas del proveedor, no en los propios.
La característica que hace esta categoría difícil de gestionar es precisamente que TI frecuentemente no sabe qué herramientas están en uso. El inventario de SaaS activos en una organización mediana puede ser sorprendentemente extenso, y una parte significativa de él puede ser desconocida para quien gestiona la seguridad.
CATEGORÍAS 4 Y 5: OUTSOURCING Y PROVEEDORES DE INFRAESTRUCTURA
Las funciones externalizadas como mesa de ayuda, gestión de RRHH o contabilidad implican que personas fuera de la organización tienen acceso a datos internos y en algunos casos a sistemas con información sensible. El riesgo no es necesariamente de acceso técnico a la infraestructura, sino de exposición de información a través de personas cuya seguridad operacional no está bajo el control directo de la organización.
Los proveedores de infraestructura cloud y conectividad tienen un perfil de riesgo diferente: son generalmente organizaciones grandes con programas de seguridad maduros y certificaciones verificables. El riesgo principal aquí es de disponibilidad y de configuración: cómo la organización configura y gestiona los servicios del proveedor determina en gran medida su exposición. Una configuración incorrecta en un bucket de almacenamiento cloud es un riesgo que la organización crea, no el proveedor.
DECISIÓN QUE DEBE TOMAR EL CIO
Con el listado de proveedores construido, clasificarlos según estas cinco categorías y priorizar los controles de gestión empezando por los de mayor riesgo: soporte remoto e integradores primero. Para esas dos categorías, la pregunta inmediata es concreta: ¿qué tipo de acceso tienen exactamente, cómo se autentica ese acceso, dónde quedan registradas las sesiones, y quién en la organización puede ver en tiempo real cuándo y desde dónde se conectan?
¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?
La clasificación por categoría de riesgo no es un ejercicio académico. Es la base para priorizar dónde invertir el esfuerzo de gestión con los recursos disponibles. Una organización mediana no tiene capacidad para auditar en profundidad a todos sus proveedores simultáneamente. Pero sí puede identificar cuáles son sus dos o tres proveedores de soporte remoto con acceso directo a sistemas críticos, revisar cómo está gestionado ese acceso, y tomar acciones concretas en las próximas semanas.
Mañana voy a ver qué acciones concretas están disponibles para cada categoría de proveedor con los recursos reales de una organización mediana, sin requerir un programa formal de gestión de riesgo de terceros.
El proveedor de soporte que se conecta a tus servidores tres veces por semana tiene acceso equivalente al de tu administrador de sistemas más senior. ¿Sabes exactamente qué hace durante esas sesiones? ¿Queda registro de ello en tus logs? Si la respuesta es no, esa es la primera conversación de riesgo de terceros que hay que tener.
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 #pfSense #TechCorpLatam #CyberLeadership #Liderazgo #Chile #MSP #NISTCSF #ISO27001
Comentarios
Publicar un comentario