TÉCNICO-GERENCIAL · RIESGO DE TERCEROS · CONTROLES BÁSICOS
Cuando se plantea la gestión de riesgo de terceros en una organización mediana, la respuesta más frecuente es que es un proceso complejo que requiere un programa formal, herramientas especializadas de evaluación de proveedores y recursos dedicados que la organización no tiene. Eso es cierto para un programa maduro y completo. Pero hay una distancia considerable entre no tener nada y tener un programa de nivel enterprise, y en esa distancia hay controles básicos que reducen la exposición de forma significativa sin requerir ni el tiempo ni el presupuesto de un programa formal.
Hoy quiero ver exactamente eso: qué puede hacer una organización mediana con los recursos disponibles, comenzando por los proveedores de mayor riesgo que identifiqué ayer.
CONTROL 1: CREDENCIALES ÚNICAS Y NOMINALES PARA CADA PROVEEDOR
El control más básico para el acceso remoto de proveedores es asegurarse de que cada proveedor tenga sus propias credenciales nominales, distintas de las credenciales internas del equipo de TI y distintas entre proveedores. Esto parece evidente pero en la práctica muchas organizaciones comparten credenciales de administrador con sus proveedores de soporte, o crean una cuenta genérica de "proveedor" que usan múltiples terceros.
Las credenciales únicas por proveedor permiten revocar el acceso de un proveedor específico sin afectar a los demás, identificar en los logs qué proveedor realizó una acción específica, y tener trazabilidad sobre el uso de cada acceso. En entornos con Fortinet, el FortiManager permite crear perfiles de acceso específicos con alcance limitado por proveedor. Lo mismo aplica para los accesos VPN con soluciones como FortiClient o pfSense con configuración de usuarios nominales.
CONTROL 2: ACCESO JUST-IN-TIME EN LUGAR DE ACCESO PERMANENTE
El acceso permanente es la forma más común de gestionar el acceso de proveedores porque es la más cómoda: el proveedor puede conectarse cuando lo necesita sin tener que coordinar con la organización. Es también la forma de mayor riesgo, porque las credenciales están activas las 24 horas aunque el proveedor solo las use algunas horas por mes.
El acceso just-in-time invierte esa lógica: el acceso está inactivo por defecto y se habilita solo cuando hay una necesidad específica, por un período acotado. El proveedor notifica que necesita acceso, alguien en la organización habilita la cuenta por las horas necesarias, y el acceso se desactiva automáticamente cuando vence la ventana. Esto reduce drásticamente la ventana de exposición: en lugar de credenciales activas las 8.760 horas del año, son credenciales activas solo las horas en que hay trabajo real.
La implementación más básica de esto no requiere herramientas sofisticadas: puede ser tan simple como tener las cuentas de proveedor deshabilitadas en Active Directory y habilitarlas manualmente cuando se coordina una sesión, deshabilitándolas al finalizar. Es un proceso manual que requiere disciplina, pero es infinitamente mejor que el acceso permanente.
ERROR COMÚN
Asumir que el proveedor de soporte necesita acceso permanente para responder a emergencias con rapidez. En la mayoría de los casos, el tiempo de activar el acceso just-in-time es de minutos, no de horas. Si el SLA del proveedor requiere respuesta en 15 minutos, la activación del acceso puede estar incluida en ese tiempo sin impactar el acuerdo. La comodidad del acceso permanente para el proveedor no justifica la exposición permanente para la organización.
CONTROL 3: CLÁUSULAS MÍNIMAS DE SEGURIDAD EN LOS CONTRATOS
Los contratos con proveedores que tienen acceso a sistemas o datos de la organización deberían incluir al menos tres cláusulas de seguridad básicas: obligación de notificación de incidentes de seguridad dentro de un plazo definido (24 o 48 horas es razonable), obligación de revocar los accesos otorgados al cierre del contrato, y derecho de la organización a solicitar evidencia de los controles de seguridad del proveedor.
Estas cláusulas no garantizan que el proveedor tenga una postura de seguridad adecuada. Pero crean un marco contractual que hace que la conversación sobre seguridad sea posible sin que parezca una desconfianza personal, y que establece consecuencias si el proveedor no cumple con obligaciones básicas.
La fricción de negociar estas cláusulas es real pero normalmente manejable. La mayoría de los proveedores medianos de la región están acostumbrados a que sus clientes corporativos más grandes les exijan estas condiciones. Si el proveedor se resiste a incluirlas, esa resistencia es en sí misma una señal que vale la pena considerar en la evaluación del riesgo de la relación.
CONTROLES 4, 5 Y 6: INVENTARIO, REVISIÓN Y VISIBILIDAD
El inventario de SaaS activos es el diagnóstico previo a cualquier gestión de esa categoría de riesgo. El proceso más simple es pedirle a cada área que liste las herramientas externas que usa, qué datos procesa cada una y quién aprobó su adopción. Ese inventario, aunque incompleto la primera vez, ya muestra las herramientas de mayor riesgo que TI desconocía.
La revisión semestral de accesos de terceros sigue exactamente la misma lógica que la revisión de accesos internos que describí la semana pasada: cruzar el listado de accesos activos con el listado de contratos vigentes. La diferencia es que aquí el insumo de RRHH se reemplaza por el listado de contratos activos del área de compras o administración. El cruce identifica los accesos post-contrato, exactamente como el de TechCorp Latam.
La visibilidad de sesión es el control que permite detectar uso anómalo de los accesos de proveedores. No requiere herramientas SIEM sofisticadas: requiere que las sesiones de acceso remoto queden registradas en los logs del sistema, con retención mínima de 90 días, y que alguien revise esos logs periódicamente o tenga alertas configuradas para accesos en horarios fuera de lo habitual.
DECISIÓN QUE DEBE TOMAR EL CIO
Identificar los dos o tres proveedores de soporte remoto con acceso a sistemas críticos y verificar, esta semana, si tienen credenciales únicas y nominales, si el acceso está permanentemente activo o puede acotarse a ventanas definidas, y si las sesiones quedan registradas en logs propios. Esas tres preguntas sobre los proveedores de mayor riesgo son el punto de partida más concreto y no requieren más de un día de trabajo para responderse.
La gestión de riesgo de terceros no empieza con un programa formal. Empieza con una pregunta concreta sobre el proveedor que tiene más acceso a los sistemas críticos: ¿qué puede hacer con ese acceso, y quién lo sabría si lo usara de forma no autorizada?
Artículo núcleo de la semana: El riesgo que viene de afuera: proveedores, terceros y la superficie de ataque que nadie mide. Mañana: el caso TechCorp Latam.
#RiesgoTerceros #SupplyChainSecurity #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #pfSense #TechCorpLatam #CyberLeadership #Liderazgo #Chile #MSP #NISTCSF #ISO27001
Comentarios
Publicar un comentario