Análisis prácticos de ciberseguridad, redes y Zero Trust

¿Cómo construir un proceso básico de respuesta a incidentes con el equipo que ya tienes?

2026-07-22T18:58:18.465-04:00

TÉCNICO-GERENCIAL · RESPUESTA A INCIDENTES · PROCESO

Las cinco fases de respuesta. Cada una requiere roles definidos, criterios de decisión y tiempos objetivo. Sin esos tres elementos, el proceso existe en teoría pero no en la práctica.

Hay algo que me resulta llamativo cuando reviso cómo las organizaciones medianas documentan su respuesta a incidentes. La mayoría tiene algo escrito: un procedimiento de tres páginas, un diagrama de flujo en una presentación de PowerPoint, un párrafo en la política de seguridad que dice que en caso de incidente se debe notificar al área de TI. Y cuando ocurre un incidente real, ese documento no se usa. No porque el equipo sea negligente, sino porque la diferencia entre un proceso documentado y un proceso operacional es exactamente la diferencia que nadie trabajó.

Un proceso documentado dice qué debería ocurrir. Un proceso operacional dice quién hace qué, con qué herramienta, en qué tiempo, con qué criterio para tomar cada decisión, y a quién notifica antes de ejecutar. Esa diferencia es la que determina si una organización responde al incidente o reacciona al caos que el incidente produce.

¿POR QUÉ EL PROCESO FALLA ANTES DE EMPEZAR?: EL PROBLEMA DE LOS ROLES

El primer lugar donde el proceso de respuesta falla en organizaciones medianas no es en la fase de contención ni en el análisis forense. Falla en la fase cero: quién recibe la alerta y qué hace en los primeros 15 minutos. En equipos pequeños donde las personas tienen múltiples responsabilidades, la alerta de seguridad llega a la misma persona que está en una reunión, o resolviendo un problema de impresora, o de vacaciones. Si no hay claridad sobre quién es el primero en responder y quién es el segundo cuando el primero no está disponible, los primeros minutos del incidente se pierden en coordinar quién se encarga en lugar de empezar a contener.

La solución no es compleja pero requiere una decisión explícita: para cada tipo de alerta, hay un responsable primario y un sustituto. Esos nombres están en el runbook con su número de teléfono directo, no solo su correo corporativo que pueden no revisar fuera de horario. Y ambas personas saben que son el responsable primario y el sustituto respectivamente, porque lo discutieron y lo practicaron, no porque lo leyeron en un documento que alguien subió a la intranet.

FASE 1 Y 2: DETECCIÓN Y TRIAJE — LAS DECISIONES QUE NADIE DEFINIÓ

Cuando llega una alerta, la primera pregunta es si es real o un falso positivo. Esa pregunta parece simple pero en la práctica es la que consume más tiempo en equipos sin experiencia previa en respuesta a incidentes, porque no hay criterios definidos para responderla rápidamente. El técnico mira la alerta, no sabe con certeza si es una amenaza real o un comportamiento inusual pero legítimo, y empieza a investigar sin un marco que le diga qué buscar primero y cuánto tiempo dedicarle antes de escalar.

El runbook tiene que incluir criterios de triaje que respondan esa pregunta: qué combinación de indicadores confirma que una alerta merece respuesta inmediata versus investigación diferida versus cierre como falso positivo. Por ejemplo, una alerta de autenticaciones fallidas masivas que proviene de una IP externa desconocida y que coincide con un intento de autenticación exitoso posterior en la misma cuenta requiere respuesta inmediata. La misma alerta que proviene de una IP interna conocida durante una migración programada probablemente es un falso positivo que se cierra con nota.

El criterio de severidad también tiene que estar definido antes del incidente, no durante. Una escala simple de tres niveles: crítico (operación afectada o datos potencialmente comprometidos, respuesta en minutos), alto (comportamiento anómalo confirmado sin impacto visible aún, respuesta en horas), medio (anomalía que requiere investigación no urgente, respuesta en el día). Cada nivel tiene un protocolo de notificación distinto y tiempos objetivo distintos. Sin esa escala predefinida, cada incidente genera una discusión sobre qué tan grave es en lugar de ejecutar el protocolo que corresponde.

FASE 3: CONTENCIÓN — EL ERROR QUE DESTRUYE LA EVIDENCIA

La contención es la fase donde el instinto lleva a cometer el error más frecuente y más costoso en la respuesta a incidentes: apagar el equipo comprometido. El instinto es comprensible, la máquina está haciendo algo malo, la solución obvia es apagarla. El problema es que apagar el equipo destruye la memoria volátil donde puede estar la evidencia más valiosa para entender qué ocurrió: el proceso malicioso que estaba corriendo, las conexiones de red activas, las credenciales que el atacante estaba usando en ese momento.

La contención correcta aísla el equipo de la red, lo que detiene la propagación y la comunicación con el comando y control del atacante, sin apagarlo. En entornos con Fortinet, eso puede hacerse desde FortiManager bloqueando el segmento de red o la IP específica sin tocar físicamente el equipo. En entornos con segmentación por VLANs en switching Cisco, puede hacerse reasignando el puerto del equipo comprometido a una VLAN de cuarentena configurada previamente.

Esa capacidad de cuarentena técnica tiene que estar preparada antes del incidente. No es algo que se configura durante la crisis. El runbook incluye el procedimiento exacto para aislar un equipo en cada tipo de segmento de red de la organización, con los comandos o los pasos en la interfaz de gestión, para que quien ejecuta la contención no tenga que investigar cómo se hace mientras el atacante sigue activo.

La contención también requiere una decisión de autorización. ¿Puede el técnico de guardia aislar un servidor de producción por su cuenta o necesita autorización de su jefe? ¿Puede aislar una workstation de un área de negocio sin consultar al gerente del área? Esas decisiones tienen que estar tomadas de antemano porque durante el incidente no hay tiempo de buscar autorizaciones y el retraso tiene un costo directo en el alcance del daño.

ERROR COMÚN

Apagar el equipo comprometido como primera acción de contención. Es el error más frecuente y el más costoso para la investigación posterior. La memoria volátil del equipo contiene información que no existe en ningún otro lugar: el proceso malicioso activo, las conexiones de red en curso, las credenciales en uso. Apagar el equipo destruye esa evidencia de forma irreversible. La contención correcta aísla de la red sin apagar. Si no existe un procedimiento de cuarentena técnica preparado, el runbook tiene que incluir explícitamente "no apagar el equipo" como primera instrucción de la fase de contención.

FASE 4: ANÁLISIS — LO QUE LOS LOGS DICEN Y LO QUE NO

El análisis post-contención tiene el objetivo de entender el alcance real del incidente: cuándo entró el atacante, qué sistemas tocó, qué credenciales usó, qué datos pudo haber accedido o exfiltrado. Esa reconstrucción se hace sobre los logs disponibles, y la calidad del análisis depende directamente de la calidad y retención de esos logs.

Aquí aparece una limitación que muchas organizaciones descubren durante el incidente y no antes: la retención de logs es insuficiente para cubrir el período relevante. Si el atacante estuvo activo durante 15 días y los logs de autenticación se retienen solo 7, los primeros 8 días del compromiso son un punto ciego que no puede reconstruirse. TechCorp Latam tuvo exactamente ese problema: la retención de logs de VPN era de 30 días, insuficiente para el período de acceso del integrador que analizamos la semana pasada.

El análisis también requiere una metodología básica de reconstrucción cronológica. El objetivo es construir un timeline de los eventos: primera actividad anómala detectada en los logs, movimientos subsiguientes, sistemas afectados en orden cronológico, última actividad del atacante antes de la contención. Ese timeline es el insumo para determinar el alcance real del compromiso y es lo que permite responder la pregunta más urgente desde el punto de vista de datos: ¿qué información pudo haber sido accedida o exfiltrada?

FASE 5: CIERRE Y APRENDIZAJE — LA FASE QUE SIEMPRE SE OMITE

Una vez remediado el incidente, la presión organizacional es volver a la normalidad lo más rápido posible. Los sistemas están funcionando de nuevo, el equipo está agotado, hay trabajo acumulado. El post-mortem queda para después, y después frecuentemente nunca llega.

El cierre formal del incidente no es burocracia: es la única oportunidad de convertir el costo del incidente en valor para la organización. El post-mortem no busca culpables. Busca responder cuatro preguntas: ¿qué pasó exactamente y cuál fue el impacto real?, ¿qué funcionó bien en la respuesta?, ¿qué falló o tardó más de lo que debería?, ¿qué cambia en el proceso, en las herramientas o en la configuración para que el mismo vector no produzca el mismo resultado la próxima vez?

Esas respuestas se documentan en un informe breve que llega a la gerencia. No un informe técnico de 40 páginas, sino una síntesis ejecutiva de una o dos páginas que responde qué pasó, qué impacto tuvo, qué se hizo para resolverlo, y qué inversión o cambio de proceso se requiere para reducir la probabilidad de recurrencia. Ese informe es también el argumento más poderoso que TI puede tener para conseguir el presupuesto o el respaldo que el incidente demostró ser necesario.

DECISIÓN QUE DEBE TOMAR EL CIO

Revisar si el proceso de respuesta actual tiene estas cuatro condiciones: roles nombrados con sustitutos para cada fase, criterios predefinidos de severidad y triaje, procedimiento de cuarentena técnica preparado en FortiGate y switching Cisco antes del incidente, y retención de logs suficiente para cubrir el período de detección tardía probable. Si alguna de esas cuatro condiciones falta, el proceso existe en teoría pero no está listo para usarse cuando importa.

El proceso de respuesta que no se practica no existe. Existe el documento que lo describe. La diferencia entre los dos se hace evidente en los primeros quince minutos de un incidente real, cuando nadie sabe con certeza quién está a cargo, qué se hace primero, y si el paso siguiente requiere autorización o no. Mañana: el caso TechCorp Latam, cómo se respondió al ransomware y qué habrían necesitado tener listo antes para que esa respuesta fuera diferente.

#RespuestaIncidentes #IncidentResponse #DetecciónDeIncidentes #Fortinet #FortiAnalyzer #Cisco #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #TechCorpLatam #CyberLeadership #Liderazgo #Chile #NISTCSF #ISO27001

Capacidades mínimas de detección sin SOC dedicado: lo que la infraestructura que ya tienes puede hacer

2026-07-21T15:48:08.302-04:00

TÉCNICO-GERENCIAL · DETECCIÓN · CAPACIDADES MÍNIMAS

Las capacidades de detección mínima viable están en las herramientas que la mayoría de las organizaciones medianas ya tienen. La brecha no es tecnológica: es de configuración y proceso.

Ayer planteé que la diferencia entre tener logs y tener detección no es tecnológica sino de proceso. Hoy quiero ir al nivel concreto: qué capacidades de detección son alcanzables para una organización mediana que no tiene un SOC dedicado, con la infraestructura que probablemente ya tiene instalada y sin inversión adicional significativa.

La respuesta es más alentadora de lo que parece. Las herramientas nativas de Fortinet, Cisco y Azure tienen capacidades de detección y correlación que la mayoría de las organizaciones medianas de la región no están usando porque nunca las configuraron explícitamente.

LO QUE FORTINET PERMITE SIN INVERSIÓN ADICIONAL

FortiAnalyzer, que acompaña a la mayoría de las implementaciones de FortiGate en organizaciones medianas, es una herramienta de correlación y análisis de logs que en muchos casos está instalada pero subutilizada. Su función no es solo almacenar logs del firewall: puede correlacionar eventos de múltiples FortiGates, generar alertas basadas en umbrales configurables, y producir reportes de comportamiento de red que permiten identificar patrones anómalos.

Con una configuración básica orientada a seguridad, FortiAnalyzer puede alertar sobre picos de tráfico saliente inusuales, intentos de conexión a destinos categorizados como maliciosos por FortiGuard, intentos de autenticación fallidos repetidos, y cambios de configuración en los FortiGates gestionados. Ninguna de esas capacidades requiere licencias adicionales si ya se tiene FortiAnalyzer en la infraestructura: requieren configuración activa por parte del equipo.

El FortiGate también tiene capacidades de IPS y detección de anomalías que con frecuencia están habilitadas pero con políticas por defecto que no están optimizadas para el entorno específico de la organización. Revisar y ajustar esas políticas es trabajo de horas, no de semanas, y puede mejorar significativamente la capacidad de detección perimetral.

LO QUE CISCO PERMITE EN LA INFRAESTRUCTURA EXISTENTE

El switching Cisco, presente en el core y las sucursales de la mayoría de las organizaciones medianas de la región, tiene capacidades de visibilidad de red que pocas organizaciones usan activamente. Syslog envía eventos de los switches a un servidor central, incluyendo cambios de estado de puertos, intentos de acceso a la consola de gestión, y eventos de spanning tree que pueden indicar actividad anómala. NetFlow, disponible en switches y routers Cisco, genera información de flujo de tráfico que permite identificar anomalías de volumen y destino sin necesidad de inspeccionar el contenido del tráfico.

Configurar el envío de Syslog de la infraestructura Cisco hacia FortiAnalyzer, si este ya está en el entorno, permite centralizar la visibilidad de red en una sola herramienta. Esa integración no requiere licencias adicionales en la mayoría de los casos: requiere configuración de ambos lados.

LO QUE AZURE INCLUYE EN LA SUSCRIPCIÓN BASE

Para las organizaciones que tienen entorno Azure, como TechCorp Latam después del incidente, hay capacidades de detección incluidas en la suscripción base que con frecuencia no están activamente configuradas. El Activity Log de Azure registra todas las operaciones sobre los recursos del entorno: quién creó un recurso, quién cambió una configuración, quién eliminó algo. Las alertas de Activity Log permiten recibir notificación inmediata cuando ocurren eventos específicos, como la creación de una nueva cuenta con privilegios de administrador o la modificación de reglas de red.

Entra ID, el directorio de identidades de Azure, genera Sign-in Logs que muestran cada autenticación: desde qué ubicación, desde qué dispositivo, con qué resultado. Microsoft Defender for Cloud, en su nivel gratuito, genera recomendaciones de seguridad y algunas alertas básicas sobre configuraciones de riesgo. Ninguna de estas capacidades requiere licencias premium en su nivel básico: requieren que alguien las habilite y configure las alertas que importan.

ERROR COMÚN

Habilitar todas las alertas disponibles en las herramientas de detección con la lógica de "más es mejor." El resultado es exactamente el problema del que hablé ayer: fatiga de alertas que hace que todas se ignoren. El punto de partida correcto es configurar un conjunto pequeño de alertas de alta señal, las que corresponden a comportamientos que casi nunca son legítimos en el entorno específico, y asegurarse de que esas alertas tengan un proceso de respuesta claro antes de agregar más.

LAS 5 ALERTAS QUE TODA ORGANIZACIÓN DEBERÍA TENER ACTIVAS

Si el punto de partida es cero alertas activas, hay cinco que tienen alta señal sobre ruido y cubren los vectores de ataque más frecuentes en organizaciones medianas.

La primera es autenticaciones fallidas masivas en un período corto: cientos o miles de intentos en minutos desde una misma IP o hacia un mismo usuario. Es el indicador más claro de un ataque de fuerza bruta o de credential stuffing. FortiAnalyzer y Azure Entra ID tienen esta capacidad nativa.

La segunda es acceso administrativo a sistemas críticos fuera del horario laboral habitual. Un administrador de dominio que se autentica a las 3 de la mañana de un martes es una señal que merece verificación, sea legítima o no. El horario de referencia requiere definirse para el entorno específico.

La tercera es tráfico saliente inusual en volumen o hacia destinos no habituales. La exfiltración de datos suele generar picos de tráfico saliente que el comportamiento normal no explica. FortiGate con FortiAnalyzer y el Activity Log de Azure permiten detectar esta anomalía.

La cuarta es la creación o modificación de cuentas con privilegios elevados, especialmente fuera de los procesos normales de gestión de identidades. En entornos on-premise, un evento de creación de cuenta en el grupo Domain Admins que no fue solicitado por el proceso formal es una señal crítica. En Azure, la asignación del rol Owner a una cuenta nueva merece atención inmediata.

La quinta es el movimiento lateral entre segmentos de red que según la arquitectura no debería ocurrir. Si la red está segmentada entre el área administrativa y los servidores de producción, tráfico iniciado desde un equipo del área administrativa hacia un servidor de producción en puertos de administración es una señal de posible movimiento lateral.

DECISIÓN QUE DEBE TOMAR EL CIO

Verificar cuáles de estas cinco alertas están actualmente configuradas en el entorno. Para las que no están, asignar la tarea de configurarlas en FortiAnalyzer, en los sistemas Cisco y en Azure según corresponda. El trabajo de configuración de las cinco alertas básicas no debería tomar más de dos o tres días a alguien familiarizado con las herramientas. Lo que sí requiere definirse antes de configurar las alertas es quién recibe cada una y qué hace cuando llega.

La brecha de detección en organizaciones medianas no es principalmente una brecha de herramientas. Es una brecha de configuración y proceso sobre las herramientas que ya existen. Mañana voy a ver la segunda parte de esa ecuación: cómo construir el proceso de respuesta básico que hace que las alertas produzcan acción.

Artículo núcleo de la semana en el blog. Mañana: proceso básico de respuesta a incidentes con el equipo existente.

#DetecciónDeIncidentes #IncidentResponse #Fortinet #FortiAnalyzer #Cisco #Azure #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #TechCorpLatam #CyberLeadership #Liderazgo #Chile #SOC #NISTCSF #ISO27001

Detección y respuesta: la diferencia entre saber que algo pasó y poder hacer algo al respecto

2026-07-20T21:54:45.727-04:00

ESTRATEGIA · DETECCIÓN Y RESPUESTA · DECISIONES TI

El tiempo entre que un incidente ocurre y que la organización lo detecta es el espacio donde el atacante consolida su posición. Reducir ese tiempo es el objetivo central de la detección.

En TechCorp Latam, el ransomware llevaba operando dentro de la red varios días antes de que el equipo de TI lo detectara. No porque nadie estuviera prestando atención: porque no existía ningún proceso activo diseñado para detectar ese tipo de actividad. Los logs estaban, en algunos sistemas. Nadie los revisaba con criterio de seguridad. Las alertas no existían. El descubrimiento del incidente no fue el resultado de una detección: fue el resultado de que los sistemas ya no funcionaban.

Esa es la situación de una fracción significativa de las organizaciones medianas de la región: tienen infraestructura, tienen logs en alguna forma, y no tienen detección. La diferencia entre esas dos cosas es exactamente el tema de esta semana.

LA ILUSIÓN DE TENER LOGS

Casi toda organización con infraestructura de red genera logs. Los firewalls Fortinet, Cisco, WatchGuard generan registros de tráfico. Los sistemas operativos generan logs de eventos. Las aplicaciones generan logs de acceso. En entornos cloud como el que quedó en TechCorp Latam post-incidente, Azure genera logs de actividad sobre cada recurso.

Esa disponibilidad de logs crea la impresión de que la organización tiene visibilidad sobre lo que ocurre en su entorno. Y esa impresión es parcialmente correcta: los datos están. El problema es que datos sin análisis no son detección. Son un archivo. Un atacante que opera durante días o semanas en un entorno con logs pero sin análisis activo es un atacante que opera con plena impunidad técnica, sabiendo que nadie está mirando los datos que registran sus movimientos.

La detección requiere tres cosas que los logs solos no proveen: correlación (conectar eventos de distintas fuentes para identificar patrones), criterio (saber qué patrones son normales y cuáles son anómalos para este entorno específico), y proceso de respuesta (qué hace alguien cuando un patrón anómalo aparece).

EL PROBLEMA DEL TIEMPO

El tiempo entre que un incidente ocurre y que la organización lo detecta es la métrica que más directamente determina el impacto del incidente. Cada día que un atacante opera dentro de la red sin ser detectado es un día en que puede moverse lateralmente, escalar privilegios, exfiltrar datos, o preparar el despliegue del payload final. El daño de un ransomware que se detecta en 4 horas es cualitativamente distinto al daño de uno que se detecta en 21 días.

Los reportes de la industria muestran tiempos promedio de detección que en organizaciones sin programas de detección activa superan las dos o tres semanas. Para organizaciones medianas sin equipo de seguridad dedicado, ese número puede ser mayor. Y el descubrimiento frecuentemente no ocurre por detección interna: ocurre porque un tercero notifica, porque el impacto ya es visible para los usuarios, o porque el atacante decidió activar la fase final del ataque.

Ese tiempo de exposición no solo determina el alcance del daño técnico. Determina el alcance de la investigación forense posterior, que necesita cubrir todo el período en que el atacante estuvo presente. Determina la posible exposición de datos durante ese período. Y determina el costo de la remediación, que crece con cada día adicional de compromiso.

LA TRAMPA DE LA ALERTA SIN PROCESO

El otro extremo del espectro es igualmente problemático: organizaciones que implementan herramientas de detección sin el proceso de respuesta que hace que esas herramientas sean útiles. El FortiAnalyzer con cientos de alertas diarias sin nadie que las revise con criterio no es detección: es ruido. Un SIEM que genera 500 alertas por día y donde el equipo no tiene capacidad de triagear más de 20 no está produciendo detección: está produciendo fatiga de alertas.

La fatiga de alertas es tan peligrosa como la ausencia de alertas porque produce el mismo resultado práctico: las alertas se ignoran. La diferencia es que con la fatiga de alertas la organización cree que tiene detección porque tiene una herramienta que genera alertas. Esa creencia falsa puede ser más peligrosa que saber que no se tiene detección, porque reduce la urgencia de resolver el problema.

LO QUE ESTA SEMANA ANALIZO

El martes voy a ver qué capacidades mínimas de detección son alcanzables para una organización mediana sin un SOC dedicado: qué herramientas nativas de la infraestructura Fortinet, Cisco y de entornos Azure pueden usarse sin inversión adicional significativa. El miércoles, cómo construir un proceso de respuesta básico que funcione con el equipo que ya existe. El jueves, el caso TechCorp Latam: cuándo se detectó realmente el ransomware, qué lo habría detectado antes, y qué capacidades de detección se implementaron post-incidente. El viernes, cómo presentar la inversión en detección a una gerencia que lo percibe como gasto y no como reducción de riesgo medible.

DECISIÓN QUE DEBE TOMAR EL CIO

¿Cuánto tiempo tardaría la organización en detectar que hay un atacante activo en su red hoy? Si la respuesta honesta es "no lo sabemos" o "cuando algo dejara de funcionar", ese es el diagnóstico de partida. La semana comienza con esa pregunta porque su respuesta define si el programa de detección es una prioridad o una aspiración.

Tener logs no es tener detección. Tener alertas no es tener respuesta. La diferencia entre esas condiciones no es tecnológica: es de proceso y de decisión sobre qué se hace cuando el sistema genera una señal. Esta semana analizo cómo construir esa capacidad con lo que una organización mediana tiene disponible.

Esta semana en el blog: cinco días analizando detección y respuesta como decisión organizacional. Mañana: capacidades mínimas de detección sin SOC dedicado.

#DetecciónDeIncidentes #IncidentResponse #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #Azure #TechCorpLatam #CyberLeadership #Liderazgo #Chile #NISTCSF #ISO27001 #SOC

La seguridad es responsabilidad de todos: lo que eso significa cuando deja de ser un slogan

2026-07-20T13:29:42.761-04:00

REFLEXIVO · LIDERAZGO · CIERRE DE SERIE S1

La distancia entre el slogan y el proceso no se mide en presupuesto. Se mide en si alguien definió exactamente qué hace cada persona cuando algo no cuadra.

Esta semana analicé el factor humano en la seguridad desde cinco ángulos distintos. El lunes, por qué la narrativa del "eslabón más débil" es incorrecta y qué implica cambiarla. El martes, cómo se mide un programa de concientización que realmente cambia comportamiento. El miércoles, los vectores de ingeniería social que el entrenamiento de phishing por correo no cubre. El jueves, el caso TechCorp Latam y el correo que pasó todos los filtros. Hoy quiero cerrar con la pregunta que subyace a toda la semana: ¿qué significa concretamente que "la seguridad es responsabilidad de todos"?

Porque esa frase, que aparece en los valores de casi toda política de seguridad corporativa, puede ser el principio de una cultura real o el fin de una conversación que nadie quiere tener. Todo depende de lo que venga después de declararla.

EL PROBLEMA CON EL SLOGAN

Cuando "la seguridad es responsabilidad de todos" funciona solo como declaración, produce un resultado perverso: cuando ocurre un incidente, nadie es específicamente responsable porque todos lo eran en general. El usuario que abrió el adjunto malicioso es señalado porque su acción fue la última en la cadena, aunque la cadena tenía múltiples brechas previas que nadie había cerrado.

La responsabilidad distribuida sin proceso explícito es, en la práctica, responsabilidad de nadie. Cada persona asume que otro está cubriendo lo que falta. El resultado es exactamente el mismo que describí en la semana de identidad y acceso con el triángulo de TI, RRHH y jefaturas: cuando todos son responsables sin coordinación, nadie lo es.

¿QUÉ SIGNIFICA COMO PROCESO?

Convertir "la seguridad es responsabilidad de todos" en proceso requiere responder tres preguntas concretas para cada rol en la organización.

La primera: ¿qué situaciones específicas debe reconocer como potencialmente sospechosas alguien en este rol? No una lista genérica de señales de phishing. Una lista contextualizada al rol específico: qué tipo de correos recibe normalmente alguien en administración y finanzas, cuáles serían inusuales, qué llamadas telefónicas debería cuestionar alguien en RRHH, qué solicitudes de acceso deberían generar una pausa en alguien en TI.

La segunda: ¿qué hace exactamente cuando identifica algo sospechoso? No "reportar a TI." Eso no es un proceso: es una instrucción sin detalle. El proceso dice: a qué canal específico reporta, con qué información, en qué tiempo, y qué puede esperar como respuesta. Si el usuario no sabe exactamente qué hacer cuando algo no cuadra, la probabilidad de que lo haga correctamente bajo presión es baja.

La tercera: ¿qué pasa cuando reporta? Esta es la pregunta que determina si la cultura de reporte se sostiene en el tiempo. Si la respuesta a un reporte es silencio, o peor, consecuencias negativas para quien reportó, el canal se cierra de facto. La persona que reportó el correo sospechoso y no recibió ninguna respuesta durante tres días no va a reportar el siguiente. La cultura de reporte requiere que quien reporta reciba confirmación de que el reporte fue recibido, una respuesta en tiempo razonable, y, si el reporte era válido, algún tipo de reconocimiento que refuerce el comportamiento.

EL ROL DE LA GERENCIA EN ESTO

La cultura de seguridad que funciona tiene una característica que los programas de concientización solos no pueden producir: respaldo visible de la gerencia. No el respaldo declarativo del mensaje del CEO en el módulo de capacitación anual. El respaldo operacional que se ve en las decisiones cotidianas.

Cuando un gerente de área presiona a su equipo para omitir un paso de verificación porque hay urgencia operacional, está enviando una señal sobre la jerarquía real de prioridades. Cuando se sanciona a alguien por haber reportado un error propio, el canal de reporte se cierra para toda el área. Cuando la gerencia trata un incidente de seguridad como un problema exclusivo de TI, está comunicando que la responsabilidad distribuida que la política declara no es real en la práctica.

Inversamente, cuando la gerencia hace preguntas sobre seguridad en las reuniones de área, cuando reconoce públicamente los reportes que ayudaron a prevenir incidentes, cuando da tiempo real al equipo para completar los procesos de verificación sin presión de urgencia, está construyendo la cultura que ningún módulo de capacitación puede reemplazar.

LO QUE ESTA SEMANA DEJA SOBRE LA MESA

Esta semana el hilo conductor fue el mismo desde el lunes: la seguridad organizacional no falla principalmente porque los usuarios son descuidados. Falla porque las organizaciones no construyen las condiciones para que las personas puedan actuar de forma segura de manera consistente.

Esas condiciones son proceso claro, canal de reporte con respuesta garantizada, entrenamiento en los vectores reales y no solo en los obvios, métricas que miden comportamiento y no solo actividad, y respaldo de la gerencia que convierte la declaración en práctica operacional.

Nada de eso requiere un presupuesto extraordinario. Requiere que alguien tome la decisión de definir exactamente qué hace cada persona cuando algo no cuadra. Esa decisión es la que convierte "la seguridad es responsabilidad de todos" de un slogan en un proceso. Y esa diferencia es exactamente la que determina si la organización aprende sobre sus vulnerabilidades antes o después del incidente.

Si alguien en tu organización descubre hoy un correo sospechoso, ¿sabe exactamente qué hacer? ¿A qué canal reporta? ¿Qué información incluye? ¿Qué puede esperar como respuesta y en cuánto tiempo? Si esas preguntas no tienen respuesta clara, la cultura de seguridad existe como declaración. Todavía no existe como proceso.

Artículo núcleo de la semana: Dejemos de llamar al usuario "el eslabón más débil".

#CulturaDeSeguridad #SecurityAwareness #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #FactorHumano #Liderazgo #GobernanzaTI #TechCorpLatam #CyberLeadership #Chile #NISTCSF #ISO27001

TechCorp Latam: el correo disfrazado de factura que nadie debería haber abierto

2026-07-19T19:28:18.252-04:00

CASO DE ESTUDIO · TECHCORP LATAM · INGENIERÍA SOCIAL

TechCorp Latam es un caso compuesto que ilustra situaciones reales documentadas en organizaciones de la región.

Esta semana estuve analizando el factor humano en la seguridad: por qué llamar al usuario "el eslabón más débil" es la narrativa incorrecta, cómo se mide un programa de concientización que realmente cambia comportamiento, y los vectores de ingeniería social que el entrenamiento de phishing por correo no cubre. Hoy quiero bajar todo eso al caso concreto: lo que ocurrió en TechCorp Latam con el correo que fue el punto de entrada del ransomware.

EL CORREO QUE NADIE MARCÓ COMO SOSPECHOSO

El correo llegó a la bandeja de entrada del área administrativa de TechCorp Latam un martes a las 10:47 de la mañana. No llegó en horario inusual. No tenía errores ortográficos llamativos. No pedía información urgente ni amenazaba con consecuencias. Era un correo que parecía exactamente lo que decía ser: una factura de un proveedor con el que la empresa tenía relación comercial.

El dominio del remitente era proveedor-techcorp.com, no el dominio real del proveedor que era proveedortechcorp.com. La diferencia, un guión en un dominio que de otra forma era idéntico, no era visible de forma inmediata en el cliente de correo que mostraba solo el nombre del remitente en la bandeja de entrada. El asunto era "Factura #2847 — Pago pendiente." El cuerpo era profesional, breve y en el tono exacto de una comunicación de cobranza normal. El adjunto se llamaba Factura_2847.pdf.

El correo pasó los filtros de spam porque el dominio era nuevo, sin historial negativo previo, y el contenido no coincidía con firmas de correo malicioso conocidas. Llegó a la bandeja de entrada como cualquier otro correo comercial.

¿POR QUÉ EL USUARIO ABRIÓ EL ADJUNTO?

La persona que abrió el adjunto trabajaba en el área de administración y finanzas. Recibir facturas de proveedores era parte de su trabajo. Revisar y confirmar recepción también lo era. El correo era coherente con su rol diario, llegó en horario laboral normal, y no tenía ninguna señal obvia de alarma.

El adjunto era un PDF. Los PDFs de facturas son exactamente el tipo de documento que esa persona abría varias veces al día. La diferencia que no podía ver desde la bandeja de entrada es que ese PDF específico contenía una macro que se ejecutó al abrir el archivo, aprovechando una configuración de Adobe Acrobat Reader que permitía la ejecución de scripts en ese equipo.

Culpar a la persona que abrió el adjunto es tan útil como culpar al navegador de un barco que chocó porque no vio el iceberg. La pregunta relevante no es por qué abrió el PDF. Es por qué la organización no tenía procesos ni herramientas que hubieran interrumpido esa cadena antes de que el adjunto se ejecutara.

LO QUE HABRÍA NECESITADO EXISTIR

El ataque fue exitoso porque varias capas de defensa estaban ausentes simultáneamente. Eso no es mala suerte: es el resultado predecible de una postura de seguridad que había crecido en complejidad operacional sin que la cultura de seguridad creciera al mismo ritmo.

La verificación de dominios en el cliente de correo podría haber resaltado la diferencia entre proveedor-techcorp.com y proveedortechcorp.com. Una configuración de seguridad de Adobe Reader que deshabilite la ejecución de scripts habría neutralizado la macro. Un proceso de verificación para facturas que superen un umbral de monto, llamar al proveedor para confirmar antes de procesar, habría detectado que esa factura no existía. Una política de restricción de ejecución de macros en documentos recibidos por correo habría hecho irrelevante el PDF malicioso.

Ninguna de esas capas estaba activa. No porque alguien las hubiera desactivado deliberadamente, sino porque nunca habían sido parte formal de la postura de seguridad de TechCorp Latam. Eran brechas de proceso y configuración que existían en silencio, invisibles hasta que un atacante las usó.

ERROR COMÚN

Diseñar el programa de concientización alrededor del correo de phishing obvio: el que tiene errores ortográficos, el que pide credenciales directamente, el que amenaza con consecuencias inmediatas. Los ataques reales que tienen impacto significativo no son los obvios. Son los coherentes con el rol del destinatario, con dominio similar al real, con adjunto de tipo habitual, sin señales de alarma visibles. Si los simulacros son fácilmente identificables, el programa mide qué tan bien los usuarios reconocen los correos que diseñó TI, no los que diseñan los atacantes.

LO QUE CAMBIÓ DESPUÉS

Post-incidente, TechCorp Latam implementó los controles que faltaban. La nueva infraestructura Fortinet incluyó filtrado de correo con verificación de dominios similares y análisis de adjuntos en sandbox. Se estableció una política de restricción de macros en documentos recibidos por correo externo. Se definió un proceso de verificación para facturas que superan un umbral de monto.

Pero el cambio más importante no fue técnico. Fue la conversación que el incidente forzó sobre qué significa concretamente que cada área tiene responsabilidades específicas en la cadena de seguridad, con pasos definidos para cuando algo no cuadra y un canal claro para reportar.

TÉCNICO-GERENCIAL · INGENIERÍA SOCIAL · CULTURA DE SEGURIDAD

Seis vectores de ingeniería social. El entrenamiento de phishing por correo cubre solo uno.

La mayoría de los programas de concientización de seguridad tienen un componente de simulacros de phishing por correo electrónico. Eso es útil. Y es insuficiente. Porque la ingeniería social no ocurre solo por correo, y los atacantes lo saben mejor que los equipos de TI que diseñan los entrenamientos.

Cuando toda la energía del programa de concientización se concentra en enseñar a los usuarios a identificar correos maliciosos, se está preparando a la organización para un vector mientras se dejan sin cubrir varios más que los atacantes usan con igual o mayor efectividad, precisamente porque saben que nadie los entrenó para ellos.

VISHING: LA LLAMADA QUE EL USUARIO NO SOSPECHA

El vishing, voice phishing, es una llamada telefónica donde el atacante se hace pasar por alguien de confianza: soporte técnico, un colega de otra área, el banco, un proveedor. La efectividad del vishing se basa en algo que el correo no tiene: la presión en tiempo real de una conversación. No hay tiempo de reenviar el correo a TI para que lo revise. No hay un enlace que copiar y verificar. Hay una persona al teléfono que está esperando respuesta.

En entornos corporativos, el pretexto más frecuente es el soporte técnico: "Llamamos del departamento de TI. Detectamos actividad sospechosa en su cuenta y necesitamos verificar sus credenciales para protegerla." La combinación de autoridad percibida, urgencia y el instinto de colaborar con quien ofrece ayuda hace que ese vector funcione con una tasa de éxito que los simulacros de phishing por correo no reflejan.

PRETEXTING: LA IDENTIDAD QUE NADIE VERIFICÓ

El pretexting consiste en construir una identidad o situación ficticia que justifique el acceso a información o sistemas. El auditor externo que necesita acceso urgente a los sistemas financieros. El nuevo proveedor que dice que el equipo de compras ya lo autorizó. El técnico de mantenimiento que viene a revisar el servidor en el cuarto de comunicaciones.

Lo que hace efectivo al pretexting no es la sofisticación del engaño sino la tendencia natural de las personas a no verificar lo que parece razonable en contexto. Un técnico con ropa de trabajo, herramientas y un número de orden de servicio parece legítimo. Verificar si realmente fue solicitado requiere un esfuerzo activo que va contra el flujo natural de cooperar con alguien que parece tener una razón válida para estar ahí.

SMISHING Y EL CONTEXTO PERSONAL QUE BORRA LA GUARDIA

El smishing, phishing por SMS o aplicaciones de mensajería como WhatsApp, llega en un canal que los usuarios no asocian con ataques corporativos. El correo corporativo tiene filtros, tiene el contexto de "aquí pueden llegar cosas maliciosas." El teléfono personal es percibido como un espacio más seguro o más personal, donde la guardia baja naturalmente.

Con el trabajo híbrido y la proliferación de aplicaciones corporativas en dispositivos personales, el smishing tiene acceso a usuarios en contextos donde son más vulnerables: fuera del horario laboral, sin el contexto de "estoy en modo trabajo y debo ser cuidadoso", con mensajes diseñados para generar urgencia inmediata.

SPEAR SOCIAL: EL ATAQUE QUE SE CONSTRUYE DURANTE SEMANAS

El spear phishing en redes sociales, especialmente en LinkedIn, es el vector de mayor sofisticación y mayor impacto en entornos corporativos. Un atacante crea un perfil falso creíble, ya sea haciéndose pasar por un reclutador, un colega de otra empresa, un académico o un potencial cliente, y construye una relación genuina con el objetivo durante semanas o meses antes de intentar el ataque.

Para cuando el atacante hace la solicitud, ya existe una relación de confianza establecida. La solicitud de información, el enlace a un documento, la invitación a un evento donde se pide registración, todo llega en el contexto de una relación que el usuario percibe como legítima porque tiene historia.

ERROR COMÚN

Creer que el entrenamiento de phishing por correo cubre "la ingeniería social." El phishing por correo es un vector de ingeniería social, no el único. Un usuario que identifica perfectamente los indicadores de un correo de phishing puede igualmente entregar sus credenciales a un atacante por teléfono, abrir la puerta a alguien que dice ser del mantenimiento, o hacer clic en un enlace enviado por un "colega de LinkedIn" con quien lleva tres meses intercambiando mensajes.

LO QUE TIENEN EN COMÚN TODOS ESTOS VECTORES

Todos los vectores de ingeniería social, independientemente del canal, explotan el mismo conjunto de características humanas: la tendencia a confiar en quien parece tener autoridad, el instinto de cooperar con quien pide ayuda, la dificultad de cuestionar a alguien que parece legítimo en contexto, y la vulnerabilidad ante la urgencia que reduce el tiempo disponible para evaluar.

La ingeniería social no es un problema de tecnología que la tecnología pueda resolver completamente. Es un problema de criterio bajo presión. Y el criterio bajo presión se desarrolla con práctica y con un marco claro de cuándo verificar y cómo hacerlo, independientemente del canal por el que llegue la solicitud.

DECISIÓN QUE DEBE TOMAR EL CIO

Revisar si el programa de concientización actual cubre solo phishing por correo o incluye escenarios de vishing, pretexting y acceso físico. Si solo cubre correo, los usuarios tienen un punto ciego sobre los vectores que los atacantes sofisticados prefieren precisamente porque saben que el entrenamiento corporativo no los cubre. Ampliar el alcance no requiere un presupuesto mayor: requiere ampliar los escenarios de práctica.

El atacante que llama por teléfono haciéndose pasar por soporte técnico no necesita superar ningún filtro tecnológico. Necesita que el usuario no tenga el criterio de verificar antes de colaborar. Ese criterio no se desarrolla con un módulo de phishing por correo. Se desarrolla con práctica en los vectores que realmente se usan.

Artículo núcleo de la semana: Dejemos de llamar al usuario "el eslabón más débil". Mañana: TechCorp Latam y el correo que nadie debería haber abierto.

#IngenieriaSocial #SocialEngineering #Phishing #Vishing #CulturaDeSeguridad #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #TechCorpLatam #CyberLeadership #Liderazgo #Chile #NISTCSF #ISO27001

El programa de concientización que sí cambia comportamiento: métricas reales para gerencia

2026-07-14T12:37:33.861-04:00

TÉCNICO-GERENCIAL · CULTURA DE SEGURIDAD · CONCIENTIZACIÓN

La diferencia entre medir actividad y medir cambio de comportamiento no es semántica. Define si el programa de concientización puede demostrar valor o solo puede demostrar que existió.

Ayer planteé que llamar al usuario "el eslabón más débil" es una narrativa que libera a la organización de responsabilidad. Hoy quiero ir al paso siguiente: si aceptamos que la cultura de seguridad es una responsabilidad organizacional, no un defecto individual, ¿qué significa tener un programa de concientización que realmente cambie comportamiento? ¿Y cómo se demuestra que está funcionando?

Porque hay una brecha significativa entre tener un programa de concientización y tener un programa que cambia comportamiento. Esa brecha empieza por cómo se mide el programa.

EL PROBLEMA DE MEDIR ACTIVIDAD EN LUGAR DE COMPORTAMIENTO

La mayoría de los programas de concientización de seguridad que he visto reportan las mismas métricas: porcentaje de empleados que completaron el módulo de capacitación anual, tasa de clics en el simulacro de phishing del trimestre, nota promedio en la evaluación del curso. Esos números son fáciles de obtener, fáciles de presentar en un dashboard, y fundamentalmente insuficientes para demostrar que algo cambió.

Un empleado puede completar el curso, sacar 90 en la evaluación, y al día siguiente hacer clic en un enlace malicioso porque el contexto real del ataque no se parece al escenario del módulo de capacitación. La tasa de clics en simulacros de phishing mide qué tan bien los usuarios reconocen los correos de phishing que el equipo de TI diseñó, no qué tan bien reconocen los que diseñaron atacantes reales con recursos y contexto específico de la organización.

Esas métricas miden que el programa ocurrió. No miden que el programa funcionó. Y la diferencia importa porque es la que determina si el programa puede justificar su presupuesto y obtener el respaldo para evolucionar.

LAS MÉTRICAS QUE SÍ MIDEN CAMBIO

Un programa de concientización que cambia comportamiento tiene indicadores distintos, más difíciles de obtener y más significativos.

La tasa de reporte de incidentes por parte de usuarios es quizás la más valiosa. Cuando los usuarios reportan activamente correos sospechosos, situaciones anómalas o errores que cometieron, es señal de que la cultura de seguridad está funcionando. No porque los usuarios sean perfectos, sino porque entienden que reportar es parte de su rol. Un programa que aumenta la tasa de reporte está produciendo el comportamiento más valioso para la seguridad organizacional: visibilidad temprana sobre amenazas y errores antes de que escalen.

El tiempo entre incidente y reporte es la métrica complementaria. Si los usuarios reportan más pero lo hacen días después del evento, el valor para la respuesta a incidentes es limitado. Si reportan en minutos u horas, la organización puede actuar antes de que el daño se extienda. Esa velocidad de reporte es un indicador directo de si los usuarios perciben la seguridad como urgente y como parte de su responsabilidad.

La tendencia de reincidencia por área es otro indicador concreto. Si determinadas áreas o perfiles de usuario tienen una incidencia repetida de comportamientos de riesgo, ya sea caer en simulacros de phishing, usar contraseñas débiles, o compartir credenciales, eso indica que el programa general no está llegando a esos segmentos con la efectividad necesaria. La reincidencia es el diagnóstico que permite personalizar la intervención.

La reducción de incidentes atribuibles a error humano es la métrica de resultado final. Es más difícil de aislar porque los incidentes dependen de múltiples factores, pero en organizaciones con registros históricos se puede estimar si la proporción de incidentes relacionados con comportamiento humano está disminuyendo. Esa tendencia, aunque imperfecta, es el argumento más directo para demostrar valor.

¿POR QUÉ EL CURSO ANUAL NO ES UN PROGRAMA?

El formato más frecuente de concientización en organizaciones medianas es el curso anual obligatorio: un módulo o una serie de módulos que todos los empleados deben completar una vez al año, generalmente con una evaluación al final, y que produce el porcentaje de completación que aparece en el reporte de cumplimiento.

Ese formato tiene utilidad como línea de base: asegura que todos los empleados hayan tenido contacto mínimo con los conceptos de seguridad básicos. Lo que no puede hacer es cambiar comportamiento de forma sostenida. El comportamiento cambia con exposición repetida, con práctica en contextos relevantes, con retroalimentación específica, y con un entorno organizacional que refuerza los comportamientos correctos. Nada de eso ocurre en un módulo anual de 45 minutos.

Un programa que cambia comportamiento tiene al menos tres componentes que el curso anual no puede cubrir solo. Primero, comunicación continua y contextualizada: recordatorios frecuentes, alertas sobre amenazas actuales relevantes para la organización, ejemplos de situaciones reales del sector. Segundo, práctica en condiciones cercanas a las reales: simulacros de phishing con escenarios actualizados y relevantes para el contexto de negocio específico, no plantillas genéricas. Tercero, retroalimentación personalizada: cuando un empleado cae en un simulacro o comete un error, la respuesta tiene que ser formativa y específica al comportamiento que falló, no una notificación genérica de que "hizo clic en un enlace de phishing."

ERROR COMÚN

Usar la tasa de clics en simulacros de phishing como la métrica principal del programa de concientización y optimizar el programa para reducir esa tasa. El problema es que una tasa de clics baja en simulacros puede lograrse entrenando a los usuarios para reconocer los indicadores específicos de los simulacros del equipo de TI, sin que eso se traduzca en mejor reconocimiento de phishing real. El objetivo no es que los usuarios no caigan en los simulacros. Es que desarrollen criterio para evaluar comunicaciones sospechosas en cualquier contexto.

¿CÓMO SE PRESENTA ESTO A LA GERENCIA?

La conversación ejecutiva sobre concientización de seguridad tiende a quedarse en el plano del cumplimiento: "el X% de los empleados completó el curso anual." Esa métrica satisface una obligación pero no informa una decisión.

La conversación que produce decisiones tiene otros datos: cuántos incidentes del último período tuvieron un componente de error humano, cuál es la tendencia de reporte voluntario por parte de usuarios, qué áreas tienen mayor reincidencia y qué intervención diferenciada se propone para ellas. Esos datos convierten el programa de concientización en una conversación de gestión de riesgo, no de cumplimiento administrativo.

DECISIÓN QUE DEBE TOMAR EL CIO

Revisar qué métricas está reportando el programa de concientización actual. Si todas las métricas disponibles miden actividad (completación, asistencia, clics en simulacros) y ninguna mide comportamiento (tasa de reporte, tiempo de reporte, reincidencia por área), el programa no puede demostrar impacto. La decisión no es necesariamente invertir más: es cambiar qué se mide para que el programa pueda justificar lo que ya se invierte.

Si el programa de concientización de tu organización no puede responder cuánto aumentó la tasa de reporte de incidentes en el último año, ni cuánto se redujo la reincidencia en las áreas de mayor riesgo, el programa está midiendo que ocurrió, no que funcionó. Y esa diferencia es exactamente la que la gerencia necesita poder distinguir.

Artículo núcleo de la semana: Dejemos de llamar al usuario "el eslabón más débil". Mañana: ingeniería social más allá del phishing por correo.

#CulturaDeSeguridad #Concientización #SecurityAwareness #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #FactorHumano #Phishing #TechCorpLatam #CyberLeadership #Liderazgo #Chile #NISTCSF #ISO27001

Dejemos de llamar al usuario "el eslabón más débil

2026-07-13T09:48:02.697-04:00

Dejemos de llamar al usuario "el eslabón más débil"

Hay una frase que se repite tanto en ciberseguridad que ya nadie la cuestiona: "el usuario es el eslabón más débil de la cadena." La he escuchado en presentaciones de directorio, en capacitaciones, en informes de consultoras internacionales. Y durante años yo también la usé, hasta que empecé a notar algo incómodo: esa frase nunca viene acompañada de una pregunta igual de importante, ¿quién construyó esa cadena y por qué dejó al usuario ahí, expuesto, sin herramientas?

Abro esta nueva serie sobre cultura de seguridad y factor humano con una convicción que se ha ido afirmando con los años: no existe tal cosa como un eslabón débil por naturaleza. Existe una organización que entrenó a alguien una vez al año con una charla aburrida, le dio un manual que nadie leyó completo, y después se sorprendió cuando esa misma persona hizo clic en un enlace que parecía legítimo. El problema no es la persona. El problema es el diseño.

En Chile, y me atrevo a decir que en gran parte de Latinoamérica, la capacitación en seguridad sigue siendo un trámite de compliance. Se hace porque la norma ISO o el auditor lo pide, se mide con un checklist de "capacitación realizada, sí o no", y ahí termina la responsabilidad de la organización. Nadie mide si la persona realmente cambió su comportamiento frente a un correo sospechoso. Nadie mide si sabe a quién avisar cuando algo no le cuadra. Se mide asistencia, no aprendizaje.

Y aquí viene algo que quiero dejar claro desde el primer día de esta serie: la cultura de seguridad no se decreta en un correo corporativo ni se logra con un curso obligatorio de cuarenta minutos que la gente ve a doble velocidad mientras hace otra cosa. La cultura se construye con repetición, con señales pequeñas y constantes, con líderes que modelan el comportamiento que piden, y sobre todo, con un sistema que hace que reportar un error sea más fácil y menos vergonzoso que ocultarlo.

Pienso en cuántas veces, en organizaciones donde he trabajado, un colaborador detectó algo raro, un correo extraño, un acceso que no le correspondía, y no dijo nada por miedo a que lo señalaran como el responsable de "haber hecho algo mal." Ese silencio cuesta más caro que cualquier clic equivocado, porque un clic se puede contener a tiempo si alguien avisa rápido. Un silencio de tres días no se contiene, se lamenta.

Por eso esta semana no voy a hablar de phishing como un problema técnico de filtros y reglas, aunque también importa. Voy a hablar de phishing, ingeniería social y error humano como un problema de diseño organizacional, de incentivos mal puestos, de procesos que castigan la honestidad y premian el silencio. El martes entramos en cómo se construye un programa de concientización que realmente cambia comportamiento, no solo asistencia. El jueves veremos, con el caso de TechCorp Latam, cómo un simple correo con apariencia de factura fue el punto de entrada de un incidente que terminó reescribiendo toda su infraestructura de seguridad.

Si algo quiero que te lleves de este primer post es esto: la próxima vez que en tu organización alguien diga "el usuario es el eslabón más débil," pregunta con qué lo estás armando para defenderse. Casi siempre la respuesta va a ser incómoda, y esa incomodidad es exactamente el punto de partida correcto.

#Ciberseguridad #CulturaDeSeguridad #FactorHumano #Phishing #IngenieríaSocial #LiderazgoTI #CISO #ConcientizaciónDigital #SeguridadDeLaInformación #GestiónDeRiesgo #TechCorpLatam #TransformaciónDigital #GobiernoTI #ResilienciaDigital #Chile #LatAm #MBA

La reunión de seguridad en la nube que termina hablando de dinero

2026-07-10T10:22:56.055-04:00

La reunión de seguridad en la nube que termina hablando de dinero

Llevo quince años sentado en reuniones donde alguien plantea un problema de seguridad y, veinte minutos después, esa misma reunión terminó hablando de presupuesto. No es casualidad. Es un patrón, y esta semana lo desarmé pieza por pieza: los contratos que nadie lee, los accesos que nadie revoca, los datos que nadie sabe dónde están, la resiliencia que nadie prueba. Hoy quiero cerrar con la conversación que las contiene a todas, porque ahí es donde se decide si la nube fue una decisión de seguridad o una decisión de costo disfrazada de estrategia.

Voy a ser directo: en la mayoría de las organizaciones que he visto en Chile y en la región, esa conversación la gana el costo. Y la gana no porque el CFO tenga razón técnica, sino porque llega a la mesa con un lenguaje que el directorio entiende de inmediato: números. El CISO, en cambio, llega con probabilidades, con escenarios, con "qué pasaría si". Contra una hoja de cálculo, un escenario pierde casi siempre.

Esta semana usé el caso de TechCorp Latam para mostrar cómo se ve esto puertas adentro. Después del ransomware, la migración a Azure de los sistemas críticos se hizo bajo presión operacional, no bajo una estrategia de nube pensada con calma. Y ahí surgió una figura que quiero destacar hoy: el subgerente que diseñó esa solución en plena crisis. Fue quien entendió los sistemas, quien tomó las decisiones técnicas bajo presión, quien sostuvo la migración con lo que había disponible en ese momento.

Meses después, cuando la urgencia bajó y llegó la revisión de costos, la empresa trajo a un IT Manager nuevo con un mandato claro: reducir gasto en la nube. Servicios innecesarios, sí, eso correspondía. Pero con el tiempo, la conversación técnica que había sostenido al subgerente durante la crisis desapareció de las reuniones. Las promesas de reconocimiento y de un rol más senior se fueron postergando. El subgerente terminó renunciando, y con él se fue el conocimiento operativo más fino de esa arquitectura, el que no está en ningún documento porque se construyó en tiempo real, resolviendo problemas que nadie había anticipado.

Esto es lo que casi nunca se mide cuando la conversación de nube se reduce a costos: el costo de perder a la persona que entiende por qué la arquitectura quedó como quedó. Se puede optimizar una factura de Azure en una tarde. Reconstruir ese conocimiento tácito toma meses, y muchas veces se reconstruye a costa de errores que ya se habían evitado una vez.

¿Cómo se cambia esta conversación entonces? No creo que la solución sea que el CISO aprenda a hablar de números, aunque ayuda. Creo que el cambio real ocurre cuando la seguridad deja de presentarse como un capítulo aparte y se integra directamente en cada decisión de costo. No "cuánto cuesta el firewall" versus "cuánto cuesta la nube", sino una sola conversación donde el costo de un control de seguridad se compara con el costo real de no tenerlo, incluyendo el conocimiento que se pierde cuando la gente que construyó la solución termina renunciando.

Llevamos toda la semana hablando de contratos mal leídos, accesos mal gestionados, datos sin trazabilidad y continuidad sin probar. El hilo común de todos esos errores es el mismo: la nube se gestionó como si fuera propia, con la misma confianza operacional del centro de datos local, sin ajustar el modelo mental a que ahora hay un tercero de por medio. Y esa conversación, la que reencuadra la nube como una relación con riesgos compartidos y no como una extensión gratuita de la infraestructura propia, sigue siendo, en mi experiencia, la conversación que menos se tiene en los directorios chilenos y latinoamericanos.

La próxima semana entramos en otro terreno. Por ahora, si algo de esta serie te sirvió para tu próxima reunión de presupuesto de nube, ya cumplió su propósito.

TechCorp Latam: la nube que llegó por urgencia, los costos que nadie calculó, y el subgerente que se fue

2026-07-09T16:11:59.465-04:00

CASO DE ESTUDIO · TECHCORP LATAM · SEGURIDAD CLOUD

TechCorp Latam es un caso compuesto que ilustra situaciones reales documentadas en organizaciones de la región.

Esta semana estuve analizando la seguridad cloud como problema de decisiones: las que se toman bajo urgencia, las configuraciones que el proveedor no reporta como error, las fricciones de identidad que se acumulan en entornos híbridos. Hoy quiero juntar todo eso en el caso que ha estado presente como referencia a lo largo de la semana: lo que ocurrió en TechCorp Latam desde el momento en que el ransomware forzó la primera decisión cloud hasta el desenlace organizacional que nadie había planeado.

Este caso tiene tres fases. Cada una tiene sus propias decisiones, sus propias consecuencias, y su propia lógica interna. Y juntas ilustran algo que va más allá de la seguridad cloud: cómo las organizaciones procesan la tensión entre urgencia, deuda técnica y presupuesto, y qué le ocurre a las personas que están en el centro de esa tensión.

FASE 1: LA NUBE QUE LLEGÓ SIN ESTRATEGIA

La noche del ransomware, con los sistemas comprometidos y la operación paralizada, alguien en el equipo de TI de TechCorp Latam tomó una decisión que resultó ser la correcta: mover los sistemas más críticos a Azure para recuperar la continuidad operativa mientras se resolvía el entorno on-premise comprometido. Esa decisión no estaba en ningún plan. No había un proyecto de migración cloud aprobado ni un presupuesto asignado. Había una urgencia que requería una solución en horas, y Azure fue esa solución.

El subgerente de TI que lideró esa iniciativa hizo lo que la situación requería: priorizó la continuidad operativa sobre cualquier otra consideración. Los sistemas críticos se levantaron en Azure con las configuraciones más expeditas posibles. Los permisos se asignaron con margen amplio para que todo funcionara sin fricción. Los controles de seguridad cloud que en condiciones normales habrían sido parte del diseño inicial quedaron para después, cuando la urgencia cediera.

Esa fue la decisión correcta en el contexto del incidente. Y creó la deuda técnica que definiría los meses siguientes.

FASE 2: EL ENTORNO HÍBRIDO QUE NADIE PLANEÓ MANTENER

Durante los meses que siguieron al incidente, TechCorp Latam operó en un entorno híbrido que tampoco estaba en ningún plan: los sistemas críticos en Azure y el resto de la infraestructura resolviéndose gradualmente on-premise, con la nueva infraestructura Fortinet que reemplazó el entorno comprometido. Ese estado era operacionalmente funcional y estratégicamente provisional, pero "provisional" se fue extendiendo porque siempre había algo más urgente que revisar la arquitectura de largo plazo.

En ese entorno híbrido, las brechas que describí esta semana se fueron acumulando. Las configuraciones expeditas del Azure de urgencia nunca se revisaron con criterio de seguridad. Las identidades de servicio creadas en la prisa de la migración inicial siguieron activas con los permisos originales. Los logs de auditoría de algunos servicios estaban deshabilitados porque nadie los había habilitado explícitamente y nadie los había pedido. La gestión de identidad entre el entorno on-premise y el entorno Azure no estaba integrada de forma sistemática.

Al mismo tiempo, el costo del entorno Azure era significativamente mayor de lo que sería sostenible en el mediano plazo. Los servicios se habían provisionado con capacidad generosa para asegurar la disponibilidad durante la recuperación. Nadie tenía mandato ni tiempo de optimizarlos. La factura cloud llegaba todos los meses y era visible para la gerencia, que no tenía el contexto técnico completo de por qué el costo era el que era pero sí tenía claro que era alto.

FASE 3: EL COSTO COMO PROBLEMA Y EL SUBGERENTE COMO SEÑAL

Al año aproximadamente del incidente, cuando la operación se había normalizado, la gerencia de TechCorp Latam inició el proceso que era previsible dado el contexto: una revisión de costos TI con énfasis en el gasto cloud. El argumento era razonable desde la perspectiva financiera: la empresa había incurrido en costos extraordinarios durante el incidente y la recuperación, y la normalización de la operación era el momento de ajustar el presupuesto a un nivel sostenible.

La decisión que tomó la gerencia para ejecutar ese ajuste fue introducir un nuevo Gerente de TI con una misión específica: reducir el gasto. No revisar la arquitectura con criterio técnico. No evaluar qué servicios cloud tenían valor estratégico y cuáles eran herencia de la urgencia. Reducir el gasto.

Esa decisión dejó al subgerente de TI, quien había liderado la respuesta al ransomware, quien había ideado la solución cloud que mantuvo la continuidad operativa, quien conocía en profundidad el estado real del entorno técnico, en una posición subordinada a alguien cuya misión era evaluar y recortar lo que él había construido bajo presión. La gerencia le había hecho promesas durante la crisis que en ese nuevo contexto organizacional quedaron sin cumplir.

La presión fue creciendo. El subgerente que había sido el técnico de referencia durante el incidente más grave que la organización había atravesado terminó retirándose de la empresa. No porque el trabajo técnico hubiera sido deficiente. Sino porque la organización no supo, o no quiso, reconciliar el valor de lo que había hecho con la nueva misión que la gerencia había priorizado.

ERROR COMÚN

Tratar la reducción de costos cloud y la revisión de seguridad cloud como procesos independientes con prioridades separadas. El gasto cloud inflado post-urgencia y la deuda de seguridad cloud post-urgencia son dos manifestaciones del mismo problema: decisiones tomadas bajo presión sin tiempo de planificar. Resolverlas por separado, primero los costos y después la seguridad, o primero la seguridad y después los costos, garantiza que alguna de las dos quede incompleta. La revisión tiene que ser conjunta y con criterio técnico que incluya ambas dimensiones.

LO QUE EL AJUSTE RESOLVIÓ Y LO QUE NO

La revisión de costos cloud que se realizó bajo la conducción del nuevo Gerente de TI produjo resultados concretos: se identificaron servicios que se habían provisionado con capacidad excesiva, se retiraron algunos que no eran necesarios en cloud y podían resolverse on-premise con la nueva infraestructura Fortinet, y el presupuesto cloud se normalizó a un nivel que la gerencia encontró aceptable.

Eso fue positivo. Lo que el proceso de reducción de costos no incluyó de forma sistemática fue la revisión de la postura de seguridad del entorno cloud que quedó. Los servicios que permanecieron en Azure siguieron con muchas de las configuraciones originales de la migración de urgencia. La deuda técnica de seguridad que se había acumulado durante la fase híbrida no fue parte del mandato del ajuste.

El resultado fue un entorno cloud más pequeño y más barato, pero no necesariamente más seguro que antes del ajuste. Y con el conocimiento técnico profundo del entorno, el que tenía el subgerente que conocía cada decisión que se había tomado durante la migración de urgencia y por qué, ya fuera de la organización.

DECISIÓN QUE DEBE TOMAR EL CIO

Cuando la organización enfrenta una revisión de costos cloud post-urgencia, la decisión correcta no es elegir entre reducir costos o revisar seguridad. Es definir que ambas revisiones ocurren en paralelo, con criterio técnico que cubra las dos dimensiones, y con la participación de quien conoce el estado real del entorno. Introducir una nueva figura con mandato de reducción de costos sin ese contexto técnico garantiza que la reducción se haga sobre los costos más visibles, no sobre los más adecuados.

El subgerente de TechCorp Latam tomó la decisión correcta en el momento correcto bajo las peores condiciones posibles. La organización resolvió la crisis gracias a esa decisión y después manejó mal el reconocimiento y la continuidad de quien la tomó. Eso no es un problema técnico. Es un problema de cómo las organizaciones gestionan el conocimiento crítico y las personas que lo sostienen.

Mañana, el cierre de la semana: cómo tener la conversación de seguridad cloud con una gerencia que lo percibe principalmente como un problema de costos.

#SeguridadCloud #CloudSecurity #Azure #TechCorpLatam #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #CyberLeadership #Liderazgo #Chile #NISTCSF #ISO27001 #CasoDeEstudio #GobernanzaTI

Identidad en la nube: por qué los mismos problemas de siempre se vuelven más difíciles

2026-07-08T16:48:01.368-04:00

TÉCNICO-GERENCIAL · IDENTIDAD CLOUD · IAM

Los problemas de identidad no desaparecen al migrar a la nube. Se suman a los que ya existían on-premise, con características propias que los hacen más difíciles de auditar.

Hace dos semanas analicé la gestión de identidad y acceso en entornos on-premise: las cuentas huérfanas, el privilege creep, los accesos de terceros sin vencimiento, y el proceso de revisión con sus cinco pasos y sus fricciones reales. Hoy quiero ver qué ocurre con esos mismos problemas cuando la organización tiene un entorno cloud activo, ya sea como destino de una migración planificada o como resultado de una migración de urgencia.

La respuesta corta es que los problemas de identidad no desaparecen al migrar a la nube. Se suman a los que ya existían on-premise. Y en cloud tienen características propias que los hacen más difíciles de detectar y más fáciles de que se acumulen sin que nadie los encuentre.

EL PROBLEMA DE LAS CREDENCIALES DE LARGA DURACIÓN

En entornos on-premise, las contraseñas de usuario tienen un ciclo de vida definido por la política del directorio: vencen cada cierto tiempo y el usuario tiene que renovarlas. En cloud, hay una categoría de credenciales que no tiene ese ciclo de vida por defecto: las access keys o claves de acceso programático.

Las access keys son pares de identificador y secreto que se usan para autenticar llamadas a la API del proveedor cloud desde aplicaciones, scripts y herramientas automatizadas. Se crean una vez, y salvo que alguien las rote explícitamente, permanecen válidas indefinidamente. En entornos cloud creados bajo urgencia, es frecuente encontrar access keys creadas durante la migración inicial que llevan meses o años activas, usadas por múltiples aplicaciones, conocidas por personas que ya no están en la organización.

La diferencia con una contraseña de usuario es que una access key comprometida puede usarse silenciosamente desde cualquier punto de internet sin que el acceso parezca anómalo. No requiere pasar por el perímetro de la red corporativa. No requiere VPN. Requiere solo la clave y el secreto, que pueden haber sido expuestos en un repositorio de código, en un archivo de configuración, o en la memoria de un sistema comprometido.

LAS IDENTIDADES DE SERVICIO SIN CICLO DE VIDA

En entornos on-premise, las cuentas de usuario tienen un ciclo de vida más o menos visible vinculado a la relación laboral de la persona. Cuando alguien sale, RRHH lo notifica (o debería notificarlo) y TI desactiva la cuenta. Ese ciclo de vida existe, aunque con las fricciones que describí hace dos semanas.

Las identidades de servicio en cloud, los service principals en Azure o los IAM roles y users en AWS, no tienen ese ciclo de vida vinculado a ninguna persona. Se crean para un proyecto, para una aplicación, para una fase de implementación. Y cuando el proyecto termina, la aplicación cambia, o la fase concluye, nadie tiene la obligación formal de revisar si esas identidades siguen siendo necesarias.

El resultado previsible es una acumulación de identidades de servicio activas en el entorno cloud que ya no tienen una función activa pero que mantienen sus permisos originales. En entornos con años de historia cloud o con múltiples proyectos de implementación, ese inventario puede ser extenso y difícil de auditar porque no hay un directorio centralizado equivalente al Active Directory que consolide todas las identidades y sus estados.

ERROR COMÚN

Asumir que las identidades de servicio cloud son menos riesgosas que las cuentas de usuario porque "no las usa ninguna persona." Una identity de servicio con permisos de administrador sobre recursos críticos es exactamente tan riesgosa como una cuenta de usuario con los mismos permisos, y frecuentemente más difícil de monitorear porque su actividad es automatizada y genera volúmenes de logs más difíciles de revisar manualmente.

EL ACCESO FEDERADO Y SUS FRICCIONES ESPECÍFICAS

Una de las ventajas que suele argumentarse para la adopción de cloud es la posibilidad de federar la identidad corporativa con el entorno cloud: los usuarios se autentican con sus credenciales del directorio on-premise, como Active Directory, y ese acceso se extiende al entorno cloud sin necesidad de gestionar identidades separadas. Azure Active Directory, hoy renombrado como Entra ID, está diseñado exactamente para ese escenario.

El problema aparece cuando la federación se configura de forma incompleta o incorrecta. Si las políticas de acceso condicional no están bien definidas, un usuario puede autenticarse en el entorno cloud desde cualquier dispositivo y ubicación sin los controles que aplican en el entorno corporativo. Si la sincronización entre el directorio on-premise y el directorio cloud no está correctamente configurada, las bajas de usuarios pueden no propagarse al entorno cloud, recreando el problema de cuentas huérfanas pero en un entorno que es más difícil de auditar.

En entornos híbridos donde coexisten infraestructura on-premise y cloud, como el que quedó en TechCorp Latam después de migrar solo los sistemas críticos a Azure y mantener el resto on-premise, la gestión de identidad tiene que cubrir dos entornos con herramientas parcialmente distintas y con visibilidad que no siempre es centralizada. Esa complejidad es exactamente donde las brechas tienden a acumularse.

MFA INCONSISTENTE ENTRE ENTORNOS

La autenticación multifactor en entornos on-premise y cloud no siempre se implementa con la misma consistencia. En muchas organizaciones, el MFA se habilitó para el acceso a aplicaciones corporativas específicas pero no se extendió al entorno cloud de forma sistemática. El resultado es que las cuentas administrativas del directorio corporativo pueden tener MFA, pero las cuentas de acceso directo a la consola cloud o a las APIs del proveedor no lo tienen.

Esa inconsistencia crea una asimetría de protección que los atacantes conocen y aprovechan: si el acceso al entorno on-premise requiere MFA pero el acceso directo a la consola Azure o AWS no lo requiere, el entorno cloud se convierte en el punto de menor resistencia para un ataque de credenciales comprometidas.

¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?

La gestión de identidad en entornos cloud no es un problema distinto al de la gestión de identidad on-premise. Es el mismo problema con una superficie más amplia, herramientas más diversas, y menos visibilidad centralizada. Las fricciones que describí hace dos semanas, la transversalidad del proceso, la resistencia de las jefaturas a certificar accesos, la ausencia de un dueño claro del proceso, todas existen también en cloud, con la complejidad adicional de que el inventario de identidades cloud es más difícil de obtener y más difícil de mantener actualizado.

El punto de partida práctico es el mismo que para el entorno on-premise: el inventario. En cloud, eso significa listar todas las identidades activas en el tenant o la cuenta cloud, incluyendo usuarios, grupos, cuentas de servicio, roles y cualquier identidad federada, con los permisos asignados a cada una. Ese inventario, la primera vez que se construye en un entorno con historia, produce casi siempre más identidades de las esperadas y más permisos de los que se recuerdan haber asignado.

DECISIÓN QUE DEBE TOMAR EL CIO

¿Tiene la organización un inventario actualizado de todas las identidades activas en su entorno cloud, con los permisos de cada una y la última vez que fueron usadas? Si ese inventario no existe, la gestión de identidad cloud está operando a ciegas. Las herramientas nativas del proveedor, Azure Entra ID Access Reviews, AWS IAM Access Analyzer, permiten construir ese inventario sin herramientas adicionales. La decisión es asignar a alguien el tiempo para hacerlo.

En cloud, las identidades se crean más rápido, se multiplican más, y tienen menos visibilidad centralizada que en un directorio on-premise. Eso no significa que el problema sea distinto. Significa que requiere más disciplina para no dejar que crezca sin control.

Artículo núcleo de la semana: Seguridad en la nube: las decisiones que se toman mal cuando la infraestructura deja de ser tuya. Mañana: el caso TechCorp Latam.

#SeguridadCloud #CloudSecurity #Azure #IAM #IdentidadCloud #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #NISTCSF #ISO27001 #EntraID

Las configuraciones cloud que el proveedor no reporta como error pero que igual te exponen

2026-07-07T08:52:29.404-04:00

TÉCNICO-GERENCIAL · SEGURIDAD CLOUD · CONFIGURACIONES

Seis configuraciones cloud frecuentes que son técnicamente válidas y operacionalmente peligrosas. El proveedor no alerta porque hiciste exactamente lo que le pediste que hiciera.

Ayer planteé que migrar a la nube no transfiere la responsabilidad de seguridad al proveedor: la redistribuye. Hoy quiero bajar eso a los casos concretos más frecuentes en entornos cloud de organizaciones medianas, las configuraciones que generan exposición real pero que el proveedor no marca como error porque técnicamente hacen exactamente lo que se les pidió que hicieran.

Ese es el punto central de hoy: el proveedor cloud no tiene forma de saber si una configuración es correcta para el contexto de negocio de la organización. Solo sabe si la configuración es técnicamente válida. Un bucket con acceso público es una configuración perfectamente válida en Azure o AWS. Si ese bucket contiene datos de clientes que no deberían ser públicos, el problema no es del proveedor. Es de quien configuró el acceso sin considerar qué había adentro.

CONFIG 1: ALMACENAMIENTO CON ACCESO PÚBLICO

Los buckets de almacenamiento con acceso público han sido el origen de algunos de los incidentes de exposición de datos más grandes de los últimos años en organizaciones de todos los tamaños. El mecanismo es simple: durante una migración o una prueba, alguien habilita el acceso público a un contenedor de almacenamiento para facilitar el trabajo, con la intención de restringirlo después. Después no llega, o llega demasiado tarde.

En Azure, un blob storage con acceso público anónimo es un recurso completamente accesible desde internet para cualquier persona que conozca o pueda descubrir la URL. En AWS, un S3 bucket con acceso público tiene el mismo resultado. El proveedor no alerta porque el acceso público es una funcionalidad legítima que tiene casos de uso válidos: distribución de contenido estático, assets de sitios web públicos, archivos descargables. El problema ocurre cuando esa configuración se aplica por error o por urgencia a contenedores que tienen datos que no deberían ser accesibles.

La revisión de este punto no requiere herramientas sofisticadas: requiere listar todos los contenedores de almacenamiento activos y verificar cuáles tienen acceso público habilitado, luego validar que el contenido de cada uno justifica esa configuración.

CONFIG 2: CUENTAS DE SERVICIO CON PRIVILEGIOS EXCESIVOS

El privilege creep que describí en la semana de identidad on-premise tiene un equivalente cloud con características propias. En entornos cloud, las cuentas de servicio, que son identidades usadas por aplicaciones y servicios automatizados para autenticarse contra recursos cloud, frecuentemente se crean con el rol de Owner o Contributor a nivel de suscripción o de grupo de recursos, porque es la forma más rápida de que la aplicación funcione sin errores de permisos.

Una cuenta de servicio con permisos de Owner sobre la suscripción completa de Azure puede hacer prácticamente cualquier cosa en el entorno cloud de la organización. Si esa cuenta de servicio es comprometida, el atacante tiene acceso equivalente al de un administrador global sobre todos los recursos cloud. El principio de mínimo privilegio aplica aquí con especial importancia: esa cuenta de servicio probablemente solo necesita acceso a un recurso específico o a un conjunto acotado de operaciones, no a toda la suscripción.

El proveedor no reporta esto como error porque una cuenta de servicio con permisos de Owner es una configuración técnicamente válida. Auditar los roles asignados a las cuentas de servicio y reducirlos al mínimo necesario es trabajo de revisión que el equipo tiene que hacer activamente.

ERROR COMÚN

Asumir que porque una aplicación "funciona" en el entorno cloud, los permisos están bien configurados. Una aplicación funciona cuando tiene suficientes permisos para ejecutar sus tareas. No cuando tiene exactamente los permisos necesarios y nada más. La diferencia entre esas dos condiciones define la superficie de ataque disponible si esa aplicación o sus credenciales son comprometidas.

CONFIG 3: REGLAS DE RED VIRTUAL DEMASIADO PERMISIVAS

Los Network Security Groups en Azure o los Security Groups en AWS son el equivalente cloud de las reglas de firewall. Durante una migración bajo urgencia, es frecuente crear reglas que permiten acceso desde cualquier origen (0.0.0.0/0) a puertos de administración como el 22 (SSH) o el 3389 (RDP), para poder conectarse a las máquinas virtuales sin restricciones y resolver problemas rápidamente.

Esa regla, que en el contexto de la urgencia era conveniente, convierte a esas máquinas virtuales en objetivos directamente accesibles desde internet para cualquier atacante que esté escaneando rangos de IP en busca de puertos abiertos. En producción, el acceso SSH o RDP debería estar restringido a rangos de IP específicos, a través de un bastion host o una VPN, nunca abierto al mundo.

La naturaleza del problema es idéntica al caso del bucket: el proveedor no alerta porque una regla que permite todo el tráfico entrante en un puerto específico es técnicamente válida. Es la organización la que tiene que determinar si esa configuración es apropiada para ese recurso en producción.

CONFIGS 4, 5 Y 6: VISIBILIDAD, CREDENCIALES Y AUTENTICACIÓN

Los logs de auditoría deshabilitados son una configuración frecuente en entornos cloud donde se redujo el costo de almacenamiento apagando servicios de logging. El problema es que sin esos logs, la organización no tiene visibilidad sobre qué ocurre en su entorno cloud: quién accedió a qué recurso, qué cambios de configuración se hicieron, qué operaciones ejecutó cada cuenta de servicio. En caso de incidente, la investigación forense es prácticamente imposible sin esos registros.

Las credenciales hardcodeadas en código son un problema que se agravó con la adopción de cloud. Durante el desarrollo o la migración bajo urgencia, es tentador incluir directamente las access keys o connection strings en el código o en archivos de configuración para que todo funcione rápido. Si ese código termina en un repositorio, las credenciales quedan expuestas para cualquiera que tenga acceso al repositorio. Incluso en repositorios privados, una brecha en el control de acceso expone todas las credenciales que el código contenga.

La ausencia de MFA en cuentas administrativas cloud es la brecha que con más frecuencia facilita el compromiso inicial de un entorno cloud. Una contraseña robada o filtrada es suficiente para acceder a una cuenta de administrador cloud si no hay un segundo factor. El proveedor ofrece MFA como opción, generalmente sin costo adicional, pero no lo exige por defecto. La decisión de habilitarlo es de la organización, y en entornos cloud creados bajo urgencia es frecuente que esa decisión no se tome en el momento inicial.

DECISIÓN QUE DEBE TOMAR EL CIO

Revisar estas seis configuraciones en el entorno cloud actual. No como un proyecto de seguridad cloud de largo plazo sino como un diagnóstico de una tarde: ¿hay almacenamiento con acceso público? ¿Hay cuentas de servicio con permisos de Owner? ¿Hay puertos de administración abiertos al mundo? ¿Están habilitados los logs de auditoría? ¿Hay credenciales en repositorios de código? ¿Tienen MFA las cuentas administrativas? Las respuestas a esas seis preguntas ya definen los riesgos más urgentes del entorno cloud.

¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?

Lo que tienen en común estas seis configuraciones es que ninguna de ellas es un error técnico. Son decisiones de configuración que el entorno cloud ejecuta correctamente. El problema no está en la herramienta: está en la decisión que se tomó cuando se configuró, generalmente bajo presión y sin tiempo de considerar las implicaciones de seguridad.

En entornos cloud creados bajo urgencia, como el de TechCorp Latam después del ransomware, la probabilidad de que alguna de estas configuraciones esté presente es alta. No porque el equipo sea descuidado, sino porque bajo urgencia las prioridades son distintas. El jueves voy a ver exactamente qué configuraciones quedaron pendientes en el entorno cloud de TechCorp Latam y qué papel jugaron en la tensión posterior entre seguridad y costos.

El proveedor cloud no puede decirte si una configuración es correcta para tu contexto de negocio. Solo puede decirte si es técnicamente válida. La diferencia entre esas dos condiciones es exactamente el espacio donde viven la mayoría de los incidentes cloud.

Artículo núcleo de la semana: Seguridad en la nube: las decisiones que se toman mal cuando la infraestructura deja de ser tuya. Mañana: identidad y acceso en entornos cloud.

#SeguridadCloud #CloudSecurity #Azure #AWS #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #IAM #NISTCSF #ISO27001 #Misconfiguration

Seguridad en la nube: las decisiones que se toman mal cuando la infraestructura deja de ser tuya

2026-07-06T09:06:28.663-04:00

ESTRATEGIA · SEGURIDAD EN LA NUBE · DECISIONES TI

El modelo de responsabilidad compartida existe en todos los contratos cloud. Lo que no existe en muchas organizaciones es la comprensión operacional de qué lado de la línea está cada decisión de seguridad.

Hay una frase que escucho seguido cuando hablo con equipos de TI que han migrado servicios a la nube: "el proveedor se encarga de la seguridad." A veces se dice con convicción, como una ventaja del modelo cloud. A veces como una racionalización para no tener que gestionar algo que siempre fue complejo. En ambos casos, la frase es incorrecta, y la incorrección tiene consecuencias concretas que aparecen en forma de configuraciones mal hechas, datos expuestos, y cuentas con privilegios que nadie revisó desde que se crearon en la urgencia de una migración.

Esta semana analizo la seguridad en la nube no como un problema técnico de configuración, sino como lo que es en la mayoría de las organizaciones medianas: un problema de decisiones que se tomaron bajo presión, sin tiempo de planificar, con supuestos incorrectos sobre quién era responsable de qué, y con consecuencias que se fueron acumulando mientras nadie tenía el mandato claro de revisarlas.

LA NUBE QUE LLEGA SIN ESTRATEGIA

Las migraciones cloud más problemáticas desde el punto de vista de seguridad no son las planificadas. Son las que ocurren bajo urgencia: el incidente que obliga a mover sistemas críticos en días, la oportunidad de negocio que requiere escalar rápidamente, la decisión de reducir costos de datacenter que se implementa con un plazo irreal. En esos contextos, la pregunta no es "cómo migramos de forma segura." Es "cómo migramos antes de que la situación empeore."

Bajo esa presión, las decisiones de seguridad se toman de la forma más expedita posible. Los permisos se configuran más amplios de lo necesario para que todo funcione rápido. Las cuentas de acceso se crean sin el rigor que se aplicaría en condiciones normales. Los servicios cloud se habilitan con configuraciones por defecto que nadie revisó. La visibilidad y el monitoreo quedan para después, cuando la urgencia pase.

El problema es que "después" tiene la misma característica que el próximo trimestre del simulacro de continuidad: siempre hay algo más urgente que revisarlo. Las configuraciones de emergencia se vuelven configuraciones permanentes. Los accesos provisorios se vuelven accesos vigentes. Y la deuda técnica de seguridad cloud crece en silencio mientras la organización asume que el proveedor se está encargando de lo que en realidad sigue siendo responsabilidad propia.

EL MODELO DE RESPONSABILIDAD COMPARTIDA EN LA PRÁCTICA

Todos los proveedores cloud, Azure, AWS, GCP, documentan el modelo de responsabilidad compartida. El proveedor es responsable de la seguridad de la infraestructura física: los datacenters, el hardware, la red subyacente, el hypervisor. La organización es responsable de todo lo que corre sobre esa infraestructura: la configuración de los servicios, los permisos de acceso, los datos almacenados, las identidades que tienen acceso al entorno, la red virtual y sus reglas.

Ese modelo existe en papel en todos los contratos. Lo que no existe en muchas organizaciones medianas es la comprensión operacional de qué lado de la línea está cada decisión de seguridad concreta. ¿Quién es responsable de que el bucket de almacenamiento no sea accesible públicamente? ¿La organización. ¿Quién es responsable de que las credenciales de las cuentas de servicio se roten periódicamente? La organización. ¿Quién es responsable de que los logs de actividad estén habilitados y retenidos? La organización. ¿Quién es responsable de que los grupos de seguridad de la red virtual no tengan reglas demasiado permisivas? La organización.

Cada una de esas responsabilidades requiere una decisión activa de configuración. El proveedor no las toma por defecto de forma segura en todos los casos, porque las configuraciones por defecto están optimizadas para la facilidad de adopción, no para la postura de seguridad mínima. Y las configuraciones que se hicieron bajo urgencia en una migración de emergencia raramente tienen en cuenta esas responsabilidades con el criterio necesario.

EL COSTO QUE NADIE CALCULÓ AL INICIO

Las migraciones cloud de urgencia también tienen una característica económica que genera tensión organizacional en el mediano plazo: el costo inicial es más alto de lo sostenible. Cuando la prioridad es recuperar operaciones, se habilitan servicios sin optimizar, se aprovisiona capacidad con margen amplio para no quedarse corto, y nadie tiene tiempo de revisar qué se puede apagar o reducir.

Ese costo inflado, que en el contexto del incidente era justificable, se convierte en el presupuesto de referencia de los meses siguientes. Y cuando la gerencia empieza a revisar los números, lo que ve es un gasto en cloud que es significativamente mayor de lo que esperaba para la escala de la organización. La presión para reducir ese gasto es legítima. El problema es que la reducción de costos cloud y la revisión de seguridad cloud son dos procesos distintos que en muchas organizaciones se confunden o se hacen en el orden incorrecto.

Reducir costos cloud sin revisar la postura de seguridad puede llevar a apagar servicios de monitoreo y logging que eran controles de seguridad, a consolidar cuentas de acceso de forma que se aumentan los privilegios, o a mover servicios de vuelta a on-premise sin validar que la configuración de seguridad del entorno de destino está lista para recibirlos. Y hacer la revisión de seguridad sin tener en cuenta los costos puede llevar a invertir en controles cloud en un entorno que después se va a desmantelar parcialmente.

LO QUE ESTA SEMANA ANALIZO

El martes voy a ver las configuraciones incorrectas más frecuentes en entornos cloud de organizaciones medianas, las que el equipo de TI no siempre detecta porque el proveedor no las reporta como errores. El miércoles, cómo gestionar la identidad y el acceso en un entorno cloud con las mismas fricciones que describí hace dos semanas para el entorno on-premise, más algunas específicas del modelo cloud. El jueves, el caso TechCorp Latam: la nube que llegó por urgencia, las decisiones de seguridad que quedaron pendientes, y lo que pasó cuando el foco se puso en reducir costos antes de revisar la postura de seguridad. El viernes, cómo tener la conversación de seguridad cloud con una gerencia que lo percibe principalmente como un problema de costos.

DECISIÓN QUE DEBE TOMAR EL CIO

¿Sabe la organización exactamente qué servicios cloud están activos hoy, quién tiene acceso a cada uno, y cuáles de esas configuraciones fueron hechas bajo urgencia y nunca revisadas? Si esa respuesta no existe, el primer paso no es un proyecto de seguridad cloud. Es el inventario: qué hay, quién tiene acceso, y qué configuraciones de seguridad se aplicaron cuando se creó cada servicio.

Migrar a la nube no transfiere la responsabilidad de seguridad al proveedor. La redistribuye. Y la parte que queda del lado de la organización es exactamente la que más frecuentemente nadie está gestionando: los permisos, las identidades, las configuraciones, los datos. Todo lo que el proveedor no puede ver porque está del otro lado de la línea.

Esta semana en el blog: cinco días analizando la seguridad cloud como decisión organizacional. Mañana: las configuraciones incorrectas más frecuentes que el proveedor no reporta.

#SeguridadCloud #CloudSecurity #Azure #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #NISTCSF #ISO27001 #ResponsabilidadCompartida

¿Cómo llevar el riesgo de terceros a la conversación ejecutiva?

2026-06-05T17:53:30.934-04:00

REFLEXIVO · LIDERAZGO · CIERRE DE SERIE

El argumento técnicamente correcto y el argumento que produce decisiones son dos cosas distintas. La gestión de riesgo de terceros necesita el segundo.

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

TechCorp Latam: el acceso del integrador que nadie cerró

2026-06-04T18:41:04.319-04:00

CASO DE ESTUDIO · TECHCORP LATAM · RIESGO DE TERCEROS

TechCorp Latam es un caso compuesto que ilustra situaciones reales documentadas en organizaciones de la región.

Esta semana estuve analizando el riesgo que viene de afuera: los proveedores y terceros con acceso a la infraestructura de la organización, las categorías de mayor riesgo, y los controles básicos disponibles antes de tener un programa formal. Hoy quiero bajar todo eso al caso concreto que ha estado presente en esta serie como referencia: lo que ocurrió con el acceso del integrador en TechCorp Latam, cómo ese acceso se convirtió en un riesgo activo durante meses sin que nadie lo detectara, y qué cambió en la gestión de ese tipo de relación después del incidente.

EL CONTEXTO DE LA RELACIÓN

TechCorp Latam había contratado a una empresa integradora para implementar y configurar la infraestructura de red de sus dos data centers. El proyecto incluyó la configuración del perímetro WatchGuard, la segmentación de red con switching Cisco, la definición de VLANs y las reglas de firewall para los distintos segmentos de la organización. Era un proyecto técnico complejo que requirió varias semanas de trabajo, acceso profundo a la infraestructura, y el uso de credenciales de administración de alto privilegio.

Al cierre del proyecto, el integrador entregó la documentación técnica y las credenciales definitivas de los sistemas. Lo que no ocurrió fue un proceso formal de cierre del acceso remoto del integrador. La cuenta VPN del integrador permaneció activa. Las credenciales que se habían usado durante la implementación, algunas de ellas compartidas entre el equipo del integrador y el equipo interno de TI, no fueron rotadas al concluir el proyecto. El argumento implícito era que podría haber ajustes posteriores y que era conveniente mantener el acceso disponible "por si acaso."

Ese "por si acaso" duró ocho meses. En ese período no hubo ninguna sesión documentada del integrador sobre esa VPN. El acceso estaba activo y no se usaba, lo que desde cierta perspectiva podría parecer que no era un problema. Pero acceso activo y sin uso no es lo mismo que acceso seguro: es un acceso que puede usarse en cualquier momento por cualquiera que tenga las credenciales, que no estaban bajo el control exclusivo de la organización.

LO QUE ESE ACCESO REPRESENTABA

El acceso del integrador no era un acceso cualquiera. Era el acceso de alguien que conocía en profundidad la arquitectura de la red: dónde estaban los sistemas más críticos, cómo estaba segmentada la red, cuáles eran las excepciones de configuración que se habían hecho por limitaciones del proyecto, qué reglas de firewall en el WatchGuard tenían excepciones documentadas y cuáles tenían excepciones que habían quedado sin documentar por las urgencias del cierre de proyecto.

Ese conocimiento de arquitectura, combinado con acceso VPN activo y credenciales no rotadas, creaba un perfil de riesgo equivalente al de un administrador interno con privilegios elevados y conocimiento profundo del entorno. La diferencia es que ese administrador estaba fuera del control organizacional de TechCorp Latam: sus prácticas de seguridad, el estado de sus propios sistemas, quién más en su empresa conocía esas credenciales, eran factores que TechCorp Latam no podía controlar ni verificar.

Lo que hacía el riesgo particularmente difícil de detectar es que no generaba ninguna señal. El acceso VPN estaba activo pero sin uso reciente. Las credenciales eran válidas pero nadie las estaba usando. Ningún sistema de monitoreo interno hubiera levantado una alerta sobre este estado, porque desde la perspectiva del directorio y de los sistemas de autenticación todo estaba en orden.

ERROR COMÚN

Interpretar la ausencia de actividad en una cuenta como evidencia de que no representa riesgo. Una cuenta VPN de integrador sin uso durante ocho meses no es una cuenta segura: es una cuenta que todavía no ha sido usada por quien tiene las credenciales. La distinción es fundamental. El riesgo no está en lo que alguien está haciendo con ese acceso en este momento. Está en lo que podría hacer en cualquier momento futuro. Y ese riesgo no desaparece con el tiempo: crece, porque las credenciales pueden circular por más personas mientras el tiempo avanza.

LA INVESTIGACIÓN POST-INCIDENTE

Después del incidente de ransomware, durante el proceso de investigación forense, el acceso del integrador fue uno de los elementos que surgió como brecha no gestionada. No como vector de entrada confirmado del incidente, sino como una exposición que existía y que en el contexto del análisis completo de la superficie de ataque de TechCorp Latam era imposible ignorar.

Lo que la investigación no pudo determinar con certeza es si ese acceso fue usado de alguna forma durante el período en que estuvo activo sin justificación. Los logs de VPN tenían una retención de 30 días, insuficiente para cubrir los ocho meses del período relevante. Esa ausencia de evidencia no equivale a que el acceso no fue usado: equivale a que no hay forma de saberlo. Y esa incertidumbre es en sí misma una consecuencia de no haber gestionado el acceso correctamente.

¿QUÉ CAMBIÓ DESPUÉS?

La remediación incluyó la implementación completa de infraestructura Fortinet, con FortiManager para gestión centralizada y FortiAnalyzer para análisis de logs. En el contexto de ese reemplazo, el onboarding del nuevo integrador, que implementó la infraestructura Fortinet, se hizo con un protocolo diferente al que existía con el integrador anterior.

Las credenciales usadas durante la implementación fueron rotadas al cierre de cada fase del proyecto, no solo al cierre total. El acceso VPN del integrador fue configurado como just-in-time: inactivo por defecto, habilitado para sesiones específicas coordinadas con el equipo interno, y deshabilitado automáticamente al vencer la ventana. Los logs de acceso remoto pasaron a tener retención de 12 meses en FortiAnalyzer, cubriendo el período relevante para cualquier investigación futura. Y el contrato incluyó cláusulas explícitas de revocación de acceso al cierre del proyecto y de notificación de incidentes.

El protocolo cambió no porque el nuevo integrador sea menos confiable que el anterior. Cambió porque la organización entendió que la confiabilidad del integrador no es el único factor relevante: también lo es la gestión del acceso independientemente de esa confiabilidad.

DECISIÓN QUE DEBE TOMAR EL CIO

Revisar los accesos activos de integradores y proveedores de soporte que hayan completado proyectos en los últimos 18 meses. Para cada uno: ¿el acceso tiene una justificación vigente? ¿Hay alguna sesión activa reciente que indique que el acceso se sigue usando para algo? ¿Las credenciales han sido rotadas desde el cierre del proyecto? Si la respuesta a cualquiera de esas preguntas apunta a un acceso que ya no está justificado, la acción es revocar, no monitorear.

El acceso del integrador en TechCorp Latam no era un riesgo nuevo el día del incidente. Era un riesgo que llevaba ocho meses acumulándose porque nadie había definido que el cierre del proyecto implicaba el cierre del acceso. No por descuido. Por ausencia de proceso. Y esa es exactamente la diferencia que los controles básicos de ayer están diseñados para resolver.

Mañana, el cierre de la semana: cómo llevar el riesgo de terceros a la conversación ejecutiva y qué argumentos mueven esa discusión.

#RiesgoTerceros #SupplyChainSecurity #TechCorpLatam #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #WatchGuard #Cisco #CyberLeadership #Liderazgo #Chile #NISTCSF #ISO27001 #CasoDeEstudio

¿Qué puede hacer una organización mediana con el riesgo de terceros sin un programa formal?

2026-06-03T15:52:23.127-04:00

TÉCNICO-GERENCIAL · RIESGO DE TERCEROS · CONTROLES BÁSICOS

Seis controles básicos de riesgo de terceros. La implementación no requiere nueva tecnología en la mayoría de los casos.

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

Los proveedores que más riesgo generan: cinco categorías y ¿por qué cada una es distinta?

2026-06-02T11:55:56.771-04:00

TÉCNICO-GERENCIAL · RIESGO DE TERCEROS · CATEGORÍAS DE PROVEEDOR

Cinco categorías de proveedor clasificadas por perfil de riesgo. La prioridad de gestión debería seguir esta clasificación, no el tamaño del contrato.

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

El riesgo que viene de afuera: ¿por qué la superficie de ataque de los proveedores es la que más crece?

2026-06-02T11:41:28.556-04:00

ESTRATEGIA · RIESGO DE TERCEROS · SUPPLY CHAIN SECURITY

Cada proveedor conectado a la organización amplía la superficie de ataque. La organización no puede controlar la seguridad interna de sus proveedores, pero sí puede gestionar la relación de riesgo.

Hay un ejercicio que le propongo a quienes quieren entender el estado real de su superficie de ataque: listar todos los proveedores, contratistas y terceros que tienen algún tipo de acceso a sus sistemas, redes o datos. No solo los grandes contratos formales. También el proveedor de soporte técnico que se conecta remotamente para resolver problemas, el integrador que implementó la infraestructura hace dos años y todavía tiene acceso para mantenimiento, el SaaS que el área de marketing contrató sin pasar por TI, la empresa de outsourcing que gestiona la mesa de ayuda.

En la mayoría de los casos, ese listado completo no existe. Y cuando se construye por primera vez, el número sorprende. No porque la organización sea descuidada, sino porque la expansión de la superficie de ataque a través de terceros ocurre de forma incremental, proveedor por proveedor, sin que nadie esté midiendo el total acumulado.

Esta semana analizo el riesgo de terceros como decisión organizacional: no qué es la gestión de riesgo de proveedores en términos de framework, sino por qué la mayoría de las organizaciones medianas de la región no la tienen implementada de forma real, qué consecuencias tiene esa ausencia, y qué se puede hacer con los recursos disponibles antes de que un incidente en la cadena de proveedores lo haga urgente.

EL PROBLEMA QUE NADIE ESTÁ MIDIENDO

Cuando una organización mejora su seguridad interna, cierra las brechas más visibles: parchea las vulnerabilidades críticas, revisa el modelo de acceso, prueba el plan de continuidad. Eso es necesario. Pero hay algo que esas mejoras no tocan: el riesgo que entra a través de las relaciones con terceros.

El proveedor de soporte remoto que se conecta a la red interna para resolver problemas tiene acceso a los mismos sistemas que un empleado de TI. Si ese proveedor tiene una brecha de seguridad en su propio entorno, o si sus credenciales de acceso a la organización son comprometidas, el atacante entra con acceso legítimo a la red interna sin haber tocado ninguno de los controles del perímetro tecnológico.

El SaaS que el área comercial adoptó para gestionar el pipeline de ventas procesa datos de clientes que pueden incluir información sensible. Si ese SaaS tiene una brecha de seguridad, esos datos están expuestos, y la organización tiene una responsabilidad sobre ellos aunque el incidente haya ocurrido en los sistemas del proveedor.

El integrador que implementó la infraestructura Fortinet hace 18 meses y que todavía tiene acceso de administración para soporte tiene un perfil de riesgo equivalente al de un administrador interno con privilegios elevados. Si ese acceso no está gestionado con la misma rigurosidad que los accesos internos, es exactamente la brecha que describí la semana pasada en el contexto de TechCorp Latam.

¿POR QUÉ LA GESTIÓN DE RIESGO DE TERCEROS NO EXISTE EN LA MAYORÍA DE LAS ORGANIZACIONES MEDIANAS?

La respuesta más honesta que he encontrado es que la gestión formal de riesgo de terceros tiene un costo de implementación que se percibe como alto para organizaciones que no han tenido un incidente originado en un proveedor. El beneficio, como ocurre con la continuidad y con las vulnerabilidades, es preventivo y abstracto. Y compite con costos operacionales concretos.

Hay además un elemento relacional que hace el problema más difícil que el riesgo interno: exigir condiciones de seguridad a un proveedor implica una negociación. El proveedor puede percibir la exigencia como una señal de desconfianza. Puede argumentar que sus procesos son adecuados sin demostrar evidencia. Puede trasladar el costo de un proceso de auditoría al precio del servicio. En relaciones donde la organización no tiene poder de negociación significativo frente al proveedor, esa conversación es incómoda.

El resultado es que muchas organizaciones tienen contratos con proveedores que no incluyen ninguna cláusula de seguridad, que no han evaluado la postura de seguridad del proveedor en ningún momento de la relación, y que no monitorean activamente el uso que el proveedor hace de los accesos que le fueron otorgados.

LO QUE ESTA SEMANA ANALIZO EN DETALLE

El martes voy a ver las categorías de proveedor con mayor perfil de riesgo y los vectores de entrada más frecuentes. El miércoles, qué se puede hacer con los recursos disponibles en una organización mediana: no un programa de gestión de riesgo de terceros de nivel enterprise, sino los controles básicos que reducen la exposición de forma significativa sin requerir una inversión desproporcionada. El jueves, el caso TechCorp Latam: el acceso del integrador que siguió activo y cómo ese tipo de relación se gestiona diferente después del incidente. El viernes, cómo llevar el riesgo de terceros a la conversación ejecutiva y qué argumentos mueven esa discusión.

DECISIÓN QUE DEBE TOMAR EL CIO

Construir el listado completo de proveedores con acceso a sistemas, redes o datos de la organización. Ese ejercicio, que puede completarse en días con la información disponible en contratos y en el directorio de accesos, ya muestra el tamaño real de la superficie de ataque externa. Sin ese listado, no es posible priorizar ni gestionar el riesgo. Con ese listado, aparecen los proveedores que requieren atención urgente antes de cualquier programa formal.

La organización que mejora su seguridad interna pero no gestiona el riesgo de sus proveedores está construyendo un perímetro con una puerta trasera que no controla. El atacante no necesita superar los controles internos si puede entrar a través de alguien que ya tiene acceso legítimo.

Esta semana en el blog: cinco días analizando el riesgo que viene de afuera. Mañana: las categorías de proveedor con mayor perfil de riesgo.

#RiesgoTerceros #SupplyChainSecurity #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #pfSense #TechCorpLatam #CyberLeadership #Liderazgo #Chile #NISTCSF #ISO27001 #ZeroTrust

¿Quién es responsable del modelo de acceso?: el limbo que ningún incidente debería resolver

2026-06-02T11:31:49.821-04:00

REFLEXIVO · LIDERAZGO · CIERRE DE SERIE

TI gestiona el sistema pero no decide quién accede. RRHH sabe quién trabaja pero no gestiona accesos. Las jefaturas saben qué hace su equipo pero no piensan en términos de acceso TI. El modelo de acceso cae en el medio.

La semana pasada terminé el jueves con una pregunta que quedó abierta: si TechCorp Latam sabía que las credenciales de administrador llevaban 11 meses sin rotar, que había un acceso de proveedor activo post-contrato, que una cuenta de ex-empleado seguía activa, ¿por qué ese respaldo organizacional para actuar sobre esas brechas llegó después del incidente y no antes?

La respuesta no es simple, pero hay un elemento que aparece con consistencia en los casos que he analizado: la responsabilidad del modelo de acceso tiende a quedar en un limbo entre tres áreas que tienen información parcial y autoridad parcial, y ninguna de las cuales tiene la responsabilidad completa de que el modelo funcione. Ese limbo no es accidental ni producto de mala fe. Es el resultado predecible de cómo se distribuye la información y la autoridad en organizaciones medianas que no han definido explícitamente quién es dueño del proceso.

TRES ÁREAS, TRES PIEZAS DEL ROMPECABEZAS, NINGÚN DUEÑO

TI tiene la información técnica: sabe cuántas cuentas existen, qué privilegios tienen asignados, cuándo fue el último acceso registrado. TI también tiene la capacidad técnica de ejecutar los cambios: desactivar cuentas, retirar privilegios, configurar fechas de vencimiento. Lo que TI no tiene, en la mayoría de las organizaciones, es la autoridad unilateral para decidir quién debería o no tener acceso a un sistema de negocio. Esa decisión requiere información sobre roles y responsabilidades que vive fuera de TI.

RRHH tiene la información sobre personas: sabe quién está activo en la organización, cuándo alguien sale, cuándo alguien cambia de rol. Es la fuente de verdad sobre el estado de la relación laboral. Lo que RRHH generalmente no tiene es la visión sobre qué sistemas usa cada persona ni la capacidad técnica para gestionar accesos de TI. Su proceso de offboarding contempla las dimensiones laborales y administrativas de la salida; la revocación de accesos digitales puede estar mencionada en la política pero raramente tiene un mecanismo de verificación activo vinculado al proceso de RRHH.

Las jefaturas de área tienen la información de negocio: saben qué hace cada persona de su equipo, qué sistemas necesita para sus responsabilidades actuales, qué cambió cuando alguien rotó de rol. Esa información es la que permite determinar si un acceso específico está justificado para una persona específica. Lo que las jefaturas típicamente no tienen es el hábito de pensar en términos de acceso TI como parte de su responsabilidad de gestión. Para ellas, el acceso a los sistemas es algo que TI gestiona, no algo que ellas tienen que certificar periódicamente.

Cuando la responsabilidad se distribuye entre tres áreas sin un proceso explícito que defina quién hace qué, cuándo y con qué mecanismo de verificación, el resultado predecible es que cada área asume que alguna de las otras dos está cubriendo lo que falta. TI asume que RRHH le notificará cuando alguien sale. RRHH asume que TI gestiona los accesos como parte de su rol. Las jefaturas asumen que alguien en TI o en RRHH se encarga de mantener el modelo actualizado. Nadie está equivocado en su comprensión parcial del problema. Pero el sistema como conjunto falla.

LO QUE CAMBIA CUANDO ALGUIEN NOMBRA AL DUEÑO

La diferencia entre organizaciones que tienen un modelo de acceso razonablemente administrado y las que no casi nunca está en la tecnología. Está en si alguien, con nombre y cargo, tiene la responsabilidad explícita de que el proceso funcione.

Ese alguien no tiene que hacer todo el trabajo solo. Tiene que asegurarse de que el proceso se ejecute: que TI tenga el listado de empleados vigentes cuando lo necesita, que RRHH active la notificación de bajas y cambios de rol hacia TI, que las jefaturas respondan las certificaciones en el plazo comprometido, que las excepciones se documenten y se revisen. Es un rol de coordinación y seguimiento, no de ejecución técnica.

En organizaciones medianas, ese rol puede recaer en el responsable de TI o en el CIO, pero requiere que la gerencia general valide que esa responsabilidad incluye la autoridad para exigir colaboración de RRHH y de las jefaturas de área cuando el proceso lo requiere. Sin esa autoridad explícita, el responsable de TI puede proponer, puede documentar, puede insistir, pero no puede garantizar que el proceso funcione cuando los demás actores no priorizan su parte.

¿POR QUÉ EL RESPALDO LLEGA DESPUÉS DEL INCIDENTE?

Volviendo a la pregunta de ayer: el respaldo llega después del incidente porque antes del incidente el costo de no tenerlo es abstracto y futuro, y el costo de construirlo es concreto y presente.

Construir el proceso de gestión de accesos requiere tiempo de TI, coordinación con RRHH, colaboración de las jefaturas y respaldo de la gerencia general. Cada uno de esos elementos tiene un costo visible en el corto plazo: reuniones, definición de procesos, fricción con usuarios, excepciones que gestionar. El beneficio, la reducción del riesgo de un incidente que todavía no ocurrió, es invisible.

Después del incidente, ese cálculo se invierte. El costo de no haber tenido el proceso es ahora concreto, documentado en horas de recuperación, en pérdida de datos, en costo de remediación, en impacto reputacional. Frente a ese número real, el costo de implementar el proceso parece razonable. Y el respaldo de la gerencia, que antes era difícil de obtener, llega de forma casi automática.

El trabajo de quien gestiona TI, antes del incidente, es acortar esa distancia. Construir el argumento que hace que el costo del incidente potencial sea tan concreto como el costo del proceso de prevención. Eso requiere estimaciones, números propios de la organización, y la disposición de la gerencia a escuchar ese argumento antes de que la urgencia lo haga inevitable.

No siempre funciona. Pero es el único camino que no pasa por el incidente primero.

LO QUE ESTA SEMANA DEJA SOBRE LA MESA

Esta semana analicé la identidad y el acceso desde cinco ángulos: el lunes, el encuadre del problema y por qué es el perímetro más importante en el contexto actual. El martes, las cuatro brechas concretas más frecuentes. El miércoles, el proceso de revisión con sus cinco pasos y sus fricciones reales. El jueves, el caso TechCorp Latam. Hoy, quién es responsable y por qué el respaldo llega tarde.

El patrón que conecta esta semana con las anteriores sobre continuidad y vulnerabilidades es el mismo: la organización sabe lo que tiene que hacer, tiene los recursos para hacerlo, y no lo hace porque la cadena de responsabilidad y autoridad que necesita el proceso no está claramente definida ni respaldada desde arriba.

Resolver eso no es un problema técnico. Es un problema de gobernanza. Y la gobernanza no se resuelve con herramientas. Se resuelve con decisiones.

Si esta semana alguien con autoridad en tu organización te preguntara quién es responsable de que el modelo de acceso esté actualizado, ¿habría una respuesta clara con un nombre? Si la respuesta es "entre varios" o "no está definido", ya sabes cuál es la decisión que está pendiente. No es tecnológica. Es de gobernanza.

Artículo núcleo de la semana: Identidad y acceso: el perímetro que nadie administra.

#IdentidadYAcceso #IAM #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #GobernanzaTI #NISTCSF #ISO27001

TechCorp Latam: los accesos que nadie revisó antes del incidente

2026-05-28T15:33:35.811-04:00

CASO DE ESTUDIO · TECHCORP LATAM · IDENTIDAD Y ACCESO

TechCorp Latam es un caso compuesto que ilustra situaciones reales documentadas en organizaciones de la región. Los detalles específicos son referenciales.

Esta semana estuve analizando la gestión de identidad y acceso como perímetro organizacional: las brechas más frecuentes, el proceso de revisión y sus fricciones. Hoy quiero bajar eso al caso concreto que da contexto a todo lo anterior: qué brechas de identidad tenía TechCorp Latam antes del incidente de ransomware, cómo contribuyeron a la capacidad del atacante de operar dentro de la red, y qué cambió en el modelo de acceso después de la remediación.

EL ESTADO DEL MODELO DE ACCESO ANTES DEL INCIDENTE

TechCorp Latam no tenía una postura de seguridad negligente en términos generales. Tenía WatchGuard cubriendo el perímetro de sus dos data centers, switching Cisco en el core y las sucursales, y algunos procesos de seguridad documentados. Lo que no tenía era un proceso activo de gestión del modelo de acceso. La política existía en papel. La administración periódica, no.

El resultado de esa ausencia, acumulado durante meses, era un conjunto de brechas de identidad que una revisión de accesos básica habría encontrado en el primer ejercicio.

La más crítica era la rotación de credenciales de administrador de dominio. La política documentaba rotación semestral. La última rotación verificada había sido 11 meses antes del incidente. En ese período, esas credenciales eran conocidas por técnicos que habían rotado de rol y por al menos una persona que ya no estaba en la organización. No había forma de saber con certeza cuántas personas tenían esas credenciales al momento del incidente, porque nunca se habían gestionado con esa granularidad.

El segundo problema era un acceso de proveedor externo activo 8 meses después del cierre del contrato. La empresa de integración que había implementado parte de la infraestructura de red tenía acceso a la consola de gestión con privilegios elevados. Ese acceso nunca fue revocado formalmente porque el cierre del contrato no generó una notificación al equipo de TI. La cuenta existía, las credenciales eran válidas, y el acceso permitía gestión remota de infraestructura crítica.

El tercero era una cuenta activa de un técnico que había salido de la organización 8 meses antes. La cuenta tenía accesos a varios sistemas internos incluyendo la red de gestión. El proceso de offboarding había incluido la devolución del equipo y la desactivación del correo corporativo, pero no la revisión y desactivación de todos los accesos de sistemas. Esa cuenta no tenía actividad reciente registrada en los logs, lo que era tranquilizador desde cierta perspectiva pero no significaba que no pudiera usarse.

El cuarto problema era privilege creep documentado pero no remediado: tres usuarios del equipo técnico tenían privilegios de administrador local en sistemas que excedían lo necesario para sus roles actuales. Esos privilegios habían sido otorgados en distintos momentos para tareas puntuales y nunca retirados. En un escenario de movimiento lateral dentro de la red, esos privilegios ampliaban significativamente la superficie de acción disponible para un atacante que ya hubiera comprometido una de esas cuentas.

¿POR QUÉ ESTAS BRECHAS IMPORTAN EN EL CONTEXTO DEL RANSOMWARE?

El ransomware que afectó a TechCorp Latam no entró por una vulnerabilidad técnica de día cero. El vector de entrada inicial involucró credenciales comprometidas. Una vez dentro, el movimiento lateral dentro de la red fue facilitado por la disponibilidad de credenciales de administrador con acceso amplio y por los privilegios elevados de cuentas que el atacante pudo comprometer progresivamente.

El perímetro tecnológico, el WatchGuard en el borde de la red, no podía detener ese movimiento porque el tráfico generado por las credenciales comprometidas era indistinguible del tráfico legítimo de administración. El firewall vio actividad autorizada de cuentas válidas con privilegios correctamente asignados. Desde su perspectiva, todo estaba en orden.

Este es el punto que más me interesa subrayar con este caso, porque es el que conecta directamente con el argumento de esta semana: la inversión en tecnología de perímetro no puede compensar un modelo de acceso mal administrado. No porque la tecnología sea insuficiente, sino porque opera sobre un supuesto que el modelo de acceso roto invalida: que las credenciales válidas corresponden a usuarios legítimos con acceso justificado.

ERROR COMÚN

Asumir que la ausencia de actividad sospechosa en los logs de una cuenta huérfana indica que es segura. Una cuenta sin actividad reciente no es una cuenta sin riesgo: es una cuenta que todavía no ha sido usada por quien la tiene. La diferencia entre las dos es imposible de determinar sin saber si las credenciales siguen siendo conocidas por personas fuera de la organización. La única forma de eliminar ese riesgo es desactivar la cuenta, no monitorear su inactividad.

¿QUÉ CAMBIÓ DESPUÉS DEL INCIDENTE?

La remediación de TechCorp Latam incluyó dos dimensiones paralelas: la renovación de infraestructura y la reconstrucción del modelo de acceso.

En infraestructura, la decisión fue reemplazar el entorno completo por Fortinet: firewalls en ambos data centers y sucursales, switching, APs y gestión centralizada con FortiManager y FortiAnalyzer. Eso resolvió también parte del problema de acceso, porque la migración obligó a reconstruir desde cero los perfiles de acceso a los sistemas de gestión, sin arrastrar la acumulación histórica del entorno anterior.

En el modelo de acceso, los cambios fueron más estructurales que tecnológicos. Se estableció una política de rotación de credenciales de administrador con cumplimiento técnico forzado, no solo documentado. Se implementó un proceso formal de offboarding que incluye la revocación verificada de todos los accesos como paso obligatorio antes del cierre del expediente de salida. Los accesos de terceros pasaron a tener fecha de vencimiento técnicamente configurada, vinculada a la vigencia del contrato. Y se definió una revisión semestral del modelo de acceso con certificación por jefatura.

Ninguno de esos cambios requería nueva tecnología. Todos requerían proceso, disciplina y respaldo organizacional. Ese respaldo llegó después del incidente porque el costo de no tenerlo se había vuelto concreto e inocultable. La pregunta que el caso deja abierta, y que he estado analizando toda la semana, es por qué ese mismo respaldo no pudo obtenerse antes.

DECISIÓN QUE DEBE TOMAR EL CIO

Hacer el diagnóstico básico antes de que un incidente lo haga urgente: cruzar el listado de cuentas activas con el listado de empleados vigentes, revisar los accesos de terceros contra los contratos activos, verificar cuándo fue la última rotación de credenciales de administrador. Ese diagnóstico, que puede completarse en días, ya muestra si la organización tiene el mismo tipo de brechas que TechCorp Latam tenía antes del incidente. La diferencia es que hacerlo ahora lo convierte en una decisión proactiva. Esperar a que el incidente lo revele lo convierte en una remediación de emergencia.

Las brechas de identidad que el ransomware encontró en TechCorp Latam no aparecieron el día del incidente. Llevaban meses ahí, visibles para quien hubiera hecho la revisión. Nadie la hizo porque no había una urgencia concreta que la justificara. Hasta que la hubo.

Mañana, el cierre de la semana: quién es responsable del modelo de acceso en la organización, y por qué esa responsabilidad suele quedar en un limbo entre TI, RRHH y las jefaturas de área.

#IdentidadYAcceso #IAM #TechCorpLatam #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #CyberLeadership #Liderazgo #Chile #ZeroTrust #ActiveDirectory #Ransomware #NISTCSF #ISO27001

¿Cómo hacer una revisión real del modelo de acceso?: el proceso y las fricciones que nadie menciona

2026-05-27T16:50:08.933-04:00

TÉCNICO-GERENCIAL · IDENTIDAD Y ACCESO · REVISIÓN DE ACCESOS

El proceso de revisión de accesos en cinco pasos, con las fricciones reales de cada uno. El proceso importa tanto como el resultado.

Ayer describí las cuatro categorías de brecha de identidad más frecuentes: cuentas huérfanas, privilege creep, accesos de terceros sin vencimiento y credenciales compartidas. Todas tienen en común que no generan alerta por sí solas y que solo una revisión periódica puede identificarlas antes de que alguien las explote. Hoy quiero ver cómo se hace esa revisión en la práctica, con sus pasos concretos y, sobre todo, con las fricciones que aparecen en cada uno de ellos y que son las que hacen que el proceso se postergue o se abandone a mitad de camino.

Porque la revisión de accesos es uno de esos procesos donde la dificultad real no es técnica. No requiere herramientas sofisticadas. Requiere coordinación entre áreas que no siempre hablan el mismo idioma, disposición a tomar decisiones que generan fricción con usuarios, y la disciplina de repetirlo con cadencia aunque el resultado del ejercicio anterior haya sido incómodo.

PASO 1: EL INVENTARIO QUE NADIE TIENE COMPLETO

El primer paso es obtener el inventario completo de cuentas activas con acceso a sistemas relevantes. Suena simple. No lo es.

El problema estructural es que en la mayoría de las organizaciones medianas el directorio principal, generalmente Active Directory o un equivalente en entornos cloud, no es la única fuente de identidad. Hay sistemas que tienen su propia gestión de usuarios independiente: el ERP, la plataforma de gestión de proyectos, los sistemas de monitoreo de red, la consola de administración del FortiManager o el sistema de gestión de la infraestructura Cisco. Cada uno de esos sistemas puede tener cuentas que no están sincronizadas con el directorio central.

El inventario completo requiere listar no solo las cuentas del directorio sino las cuentas de acceso en cada sistema relevante. Ese ejercicio, la primera vez que se hace, típicamente revela más cuentas de las que el equipo esperaba. Y algunos sistemas no tienen una forma simple de exportar la lista de usuarios activos, lo que agrega fricción técnica al proceso.

PASO 2: EL CRUCE CON RECURSOS HUMANOS

Una vez que existe el inventario de cuentas, el siguiente paso es cruzarlo con el listado de personas que tienen una relación vigente con la organización: empleados activos y contratistas con contrato vigente. Ese cruce identifica las cuentas huérfanas.

La fricción aquí es de coordinación. El listado de empleados activos vive en Recursos Humanos. El listado de cuentas vive en TI. Esas dos áreas no siempre tienen un canal de comunicación establecido para intercambiar esa información de forma sistemática. Y el listado de RRHH no siempre está actualizado en tiempo real: en algunas organizaciones, el proceso administrativo de baja de un empleado tiene un retraso de días o semanas respecto a la fecha efectiva de salida.

Establecer ese canal de comunicación, definir el formato del intercambio de información y acordar la frecuencia de actualización es trabajo de proceso, no de tecnología. Pero es el trabajo que hace que el cruce sea posible de forma sistemática y no solo como un ejercicio puntual cada vez que alguien lo pide.

PASO 3: LA REVISIÓN DE PRIVILEGIOS

Identificar las cuentas activas cuyos titulares siguen en la organización es necesario pero no suficiente. El siguiente paso es revisar que los privilegios asignados a cada cuenta correspondan al rol actual de la persona, no a la acumulación histórica de roles anteriores.

Aquí aparece la fricción más difícil de resolver sin un trabajo previo: para comparar los privilegios actuales con el perfil de rol correspondiente, tiene que existir una definición de qué accesos corresponde a cada rol. Si la organización no tiene esa matriz de roles y accesos documentada, la revisión de privilegios no tiene un referente contra el cual comparar. El técnico que tiene acceso a doce sistemas distintos, ¿cuántos de esos accesos son necesarios para su rol actual? Sin la matriz, esa pregunta no tiene respuesta objetiva.

Construir esa matriz de roles y accesos es, en sí mismo, un proyecto de cierta envergadura. Pero no tiene que ser perfecta para ser útil. Una versión básica que defina los accesos mínimos necesarios para los roles más críticos de la organización, administradores de sistemas, accesos a datos financieros, accesos a infraestructura de red, es suficiente para empezar a identificar las desviaciones más evidentes.

ERROR COMÚN

Intentar hacer la revisión completa de todos los accesos de toda la organización en un solo ejercicio la primera vez. Ese alcance genera una carga de trabajo que el equipo no puede absorber, produce resultados tan voluminosos que nadie los procesa completamente, y lleva a que el ejercicio se abandone antes de completarse. La primera revisión debe ser acotada: los accesos a sistemas críticos, los usuarios con privilegios elevados, las cuentas de terceros. Un alcance manejable que produzca resultados accionables es más valioso que un inventario exhaustivo que nadie termina de revisar.

PASO 4: LA CERTIFICACIÓN POR JEFATURA

La revisión técnica de accesos puede identificar anomalías, pero la decisión de si un acceso específico está justificado para una persona específica en su rol actual no es siempre una decisión técnica. Es una decisión de negocio que tiene que tomar quien conoce las responsabilidades actuales de esa persona: la jefatura directa.

El proceso de certificación consiste en presentar a cada jefatura la lista de accesos activos de las personas bajo su responsabilidad y pedirle que confirme cuáles están justificados y cuáles no. Ese paso es el que distribuye la responsabilidad de la revisión más allá de TI y la convierte en un proceso organizacional.

La fricción aquí es de tiempo y contexto. Las jefaturas tienen sus propias prioridades. Revisar una lista de accesos de diez personas con quince sistemas cada una requiere atención que compite con otras demandas. Y en algunos casos, la jefatura no tiene el contexto técnico para evaluar si un acceso específico está justificado. El proceso tiene que facilitar ese trabajo: listas pre-filtradas, preguntas simples, plazos claros y un escalamiento definido para los casos donde la jefatura no puede determinar si el acceso es necesario.

PASO 5: LA REMEDIACIÓN Y LA FRICCIÓN CON EL USUARIO

El último paso es actuar sobre lo que la revisión encontró: desactivar cuentas huérfanas, retirar privilegios excesivos, revocar accesos de terceros vencidos, separar y personalizar credenciales compartidas. Cada una de esas acciones tiene el potencial de generar una fricción con el usuario o el sistema afectado.

La persona cuya cuenta huérfana se desactiva puede haber estado usando esas credenciales para acceder ocasionalmente a sistemas después de su salida, algo que no debería ocurrir pero que en la práctica a veces ocurre. El técnico al que se le retiran privilegios acumulados puede descubrir que los usaba de forma informal para hacer tareas que en teoría ya no le corresponden. El proveedor cuyo acceso se revoca puede argumentar que todavía tiene trabajo pendiente.

Anticipar esa fricción, tener un proceso claro para gestionar las excepciones justificadas y ser firme con las que no lo son, requiere respaldo explícito de la gerencia. Sin ese respaldo, la presión de los casos individuales tiende a erosionar el resultado de la revisión antes de que se consolide.

DECISIÓN QUE DEBE TOMAR EL CIO

Definir la cadencia del proceso antes de hacer la primera revisión: revisión completa semestral, revisión de accesos de terceros trimestral, y revisión por evento ante cualquier baja o cambio de rol significativo. Sin esa cadencia definida, la revisión es un proyecto puntual que se hace una vez y no se repite. Con la cadencia definida, es un proceso que mejora con cada ciclo porque el equipo ya sabe qué hacer, dónde están las fricciones y cómo gestionarlas.

La revisión de accesos no es un proyecto de seguridad. Es un proceso de higiene organizacional que tiene que repetirse con cadencia. La primera vez cuesta porque hay que construir el proceso, coordinar las áreas y gestionar la fricción de los resultados. La segunda vez cuesta menos. La tercera ya es rutina. El problema es que la mayoría de las organizaciones nunca llegan a la segunda.

Artículo núcleo de la semana: Identidad y acceso: el perímetro que nadie administra. Mañana: el caso TechCorp Latam.

#IdentidadYAcceso #IAM #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #Ubiquiti #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #ActiveDirectory #NISTCSF #ISO27001

Cuentas huérfanas, privilegios acumulados y terceros sin vencimiento: las brechas que nadie ve hasta que alguien las usa

2026-05-26T10:16:50.118-04:00

TÉCNICO-GERENCIAL · IDENTIDAD Y ACCESO · BRECHAS OPERACIONALES

Cuatro categorías de brecha de identidad. Ninguna requiere un atacante sofisticado para ser explotada. Todas requieren un proceso de revisión periódica para ser detectadas.

Ayer planteé que la identidad es el perímetro que las organizaciones construyen con política y tecnología, y que luego dejan de administrar. Hoy quiero bajar eso a las brechas concretas: cuáles son, por qué aparecen, y por qué son particularmente peligrosas comparadas con vulnerabilidades técnicas del tipo CVE.

La diferencia más relevante entre una brecha de identidad y una vulnerabilidad de software es la siguiente: la vulnerabilidad de software, cuando es explotada, genera comportamiento anómalo que los sistemas de detección pueden identificar. La cuenta huérfana explotada genera comportamiento completamente normal desde la perspectiva de los sistemas de control, porque el acceso es técnicamente válido. Eso la hace más difícil de detectar y, en muchos casos, más costosa cuando finalmente se identifica el compromiso.

BRECHA 1: CUENTAS HUÉRFANAS

Una cuenta huérfana es cualquier cuenta de usuario activa cuyo titular ya no tiene una relación vigente con la organización: ex-empleados, ex-contratistas, proveedores cuyo contrato terminó. La cuenta existe, tiene credenciales válidas, tiene accesos asignados, y puede ser usada por cualquiera que tenga las credenciales, que pueden estar en manos del ex-titular o haberse filtrado.

La frecuencia con que aparece esta brecha en organizaciones medianas es llamativa. En auditorías de directorio de Active Directory en empresas de entre 50 y 300 empleados, es frecuente encontrar entre un 10 y un 20 por ciento de cuentas activas cuyos titulares ya no están en la organización. No por mala fe: por ausencia de un proceso formal de offboarding que incluya la revocación de accesos digitales como paso verificado.

El proceso de offboarding en muchas organizaciones se concentra en los aspectos visibles y urgentes: devolución del equipo, liquidación de haberes, traspaso de responsabilidades. La desactivación de cuentas en el directorio, la revocación de accesos a sistemas de negocio, la eliminación de claves de VPN, la desvinculación de cuentas de correo corporativo, todo eso suele tener menor urgencia y a veces no ocurre de forma sistemática. Especialmente cuando la salida del empleado es planificada y no conflictiva: nadie percibe urgencia en revocar el acceso de alguien que salió en buenos términos.

El problema es que las cuentas no distinguen entre salidas amistosas y no amistosas. La cuenta existe o no existe. Y mientras existe y está activa, es un vector de acceso.

BRECHA 2: PRIVILEGE CREEP, LOS PRIVILEGIOS QUE SE ACUMULAN

El privilege creep, la acumulación progresiva de privilegios, es quizás la brecha más silenciosa de las cuatro. Ocurre cuando una persona cambia de rol dentro de la organización y recibe nuevos accesos para sus nuevas responsabilidades, pero nadie retira los accesos correspondientes a su rol anterior.

El técnico de soporte que fue ascendido a administrador de sistemas sigue teniendo los accesos del técnico de soporte más los del administrador. El analista que rotó de área sigue con acceso a los sistemas de la unidad anterior. El jefe de proyecto que terminó un proyecto con acceso a sistemas específicos del cliente sigue con ese acceso activo. Cada transición suma. Nada resta.

Con el tiempo, algunas personas en la organización acumulan un conjunto de privilegios que no refleja ningún rol existente sino la suma de todos los roles que tuvieron. Ese perfil de acceso excesivo viola el principio de mínimo privilegio, que establece que cada usuario debería tener acceso únicamente a los recursos que necesita para sus responsabilidades actuales. Es un principio que la mayoría de las políticas de seguridad mencionan. Es un principio que muy pocas organizaciones aplican con consistencia porque requiere revisar activamente lo que se tiene, no solo lo que se agrega.

ERROR COMÚN

Gestionar los accesos únicamente en el momento del alta: cuando alguien entra, se le otorgan los accesos que necesita. Sin un proceso simétrico de revisión y depuración periódica, el modelo de acceso solo crece. Cada alta agrega. Ningún proceso resta. Con el tiempo, la distancia entre los accesos que el directorio registra y los accesos que las personas realmente necesitan para sus roles actuales se convierte en una superficie de ataque que nadie está midiendo.

BRECHA 3: ACCESOS DE TERCEROS SIN FECHA DE VENCIMIENTO

Los proveedores externos, consultores, empresas de soporte técnico, integradores de sistemas, todos ellos requieren en algún momento acceso a sistemas internos de la organización para hacer su trabajo. Ese acceso es legítimo durante la vigencia del proyecto o el contrato.

El problema es cuando ese acceso no tiene una fecha de vencimiento técnicamente configurada y vinculada al fin del contrato. En la práctica, lo que ocurre es que el acceso se otorga para el proyecto, el proyecto termina, y el acceso permanece activo indefinidamente porque nadie en la organización recibió la señal formal de que había que revocarlo. El equipo de TI no siempre sabe cuándo termina el contrato de un proveedor específico. El área que contrató al proveedor no siempre notifica a TI cuando el contrato vence. El proveedor ciertamente no va a reportar que su acceso sigue activo.

El resultado es una acumulación de accesos de terceros que en algunos casos lleva meses o años activos después de que la relación comercial terminó. Desde el punto de vista del directorio, esas cuentas son indistinguibles de accesos vigentes y justificados.

BRECHA 4: CUENTAS Y CREDENCIALES COMPARTIDAS

Las cuentas compartidas, especialmente las de administración, son una práctica que persiste en muchas organizaciones porque parece conveniente: un solo conjunto de credenciales para las tareas de administración, conocido por todos los técnicos que las necesitan. El problema es que eliminan la trazabilidad.

Cuando varios técnicos usan las mismas credenciales de administrador, el log de actividad muestra la cuenta, no la persona. Si esa cuenta hace algo que genera un incidente, no hay forma directa de saber quién estaba usando las credenciales en ese momento. Si uno de los técnicos sale de la organización, las credenciales compartidas siguen siendo válidas porque cambiarlas requiere notificar y actualizar a todos los que las usan. Esa fricción hace que el cambio se postergue.

En entornos con Fortinet, Cisco, WatchGuard o Ubiquiti, las credenciales de gestión compartidas son un vector de acceso que no requiere ningún exploit técnico: requiere que alguien que conocía esas credenciales, y que ya no tiene relación vigente con la organización, las use desde cualquier punto con conectividad.

DECISIÓN QUE DEBE TOMAR EL CIO

Antes de implementar cualquier herramienta de gestión de identidad, hacer el diagnóstico con los datos que ya existen: exportar el listado completo de cuentas activas del directorio y cruzarlo con el listado de empleados y contratistas vigentes de Recursos Humanos. Ese cruce, que puede hacerse en horas, ya identifica las cuentas huérfanas. El privilege creep requiere un paso adicional: revisar los grupos y roles asignados a cada cuenta contra el perfil actual de la persona. Esas dos acciones no requieren nueva tecnología. Requieren tiempo y voluntad de hacer el ejercicio.

¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?

Lo que tienen en común estas cuatro categorías de brecha es que ninguna genera alerta por sí sola. El directorio no distingue entre una cuenta activa legítima y una cuenta huérfana. El sistema de autenticación no distingue entre un privilegio justificado y uno acumulado sin revisión. El firewall no distingue entre el acceso de un proveedor vigente y el de uno cuyo contrato terminó.

La única forma de identificarlas antes de que alguien las use es el proceso de revisión periódica. Mañana voy a ver cómo se hace esa revisión en condiciones reales de una organización mediana: qué pasos tiene, qué fricción genera, y cómo se estructura para que sea sostenible en el tiempo.

Una cuenta huérfana no necesita ser descubierta por un atacante sofisticado. Necesita existir. El tiempo hace el resto. Cada día que la cuenta permanece activa sin titular vigente es un día en que puede ser usada, y nadie lo va a saber hasta que el daño ya esté hecho.

Artículo núcleo de la semana: Identidad y acceso: el perímetro que nadie administra. Mañana: cómo hacer una revisión real del modelo de acceso.

Identidad y acceso: el perímetro que se dejó de administrar

2026-05-25T20:28:36.439-04:00

ESTRATEGIA · IDENTIDAD Y ACCESO · DECISIONES TI

Las organizaciones cuidan el perímetro tecnológico. El perímetro de identidad, quién tiene acceso a qué y desde hace cuánto, suele gestionarse de forma informal o directamente no gestionarse.

Hay una pregunta que muy pocas organizaciones pueden responder con precisión en menos de diez minutos: ¿cuántas cuentas de usuario activas tienen en este momento con acceso a sistemas críticos? No el número aproximado. El número exacto, con la lista de quiénes son, qué nivel de privilegio tienen, cuándo fue la última vez que iniciaron sesión, y si todos ellos siguen siendo empleados o contratistas activos de la organización.

Esa incapacidad de responder no es un problema técnico. Las herramientas para tener esa información existen y son accesibles. Es un problema de administración: alguien tiene que haber decidido mantener ese inventario actualizado, con un proceso periódico de revisión y depuración, y en la mayoría de las organizaciones medianas de la región esa decisión nunca se tomó formalmente.

Esta semana quiero analizar la identidad y el acceso no como un tema de arquitectura de seguridad, sino como lo que es en la práctica: un perímetro que las organizaciones construyen con política y tecnología, y que luego dejan de administrar mientras la brecha entre la política documentada y la realidad operacional crece silenciosamente.

¿POR QUÉ LA IDENTIDAD ES EL PERÍMETRO QUE MÁS IMPORTA?

Durante años, el perímetro de seguridad fue físico y tecnológico: el firewall en el borde de la red, los controles de acceso a las instalaciones, los sistemas de detección en el tráfico entrante. Ese modelo sigue siendo relevante. Fortinet en el perímetro, WatchGuard en entornos mixtos, pfSense o OPNsense en infraestructuras más pequeñas: toda esa tecnología tiene un rol concreto y necesario.

Pero hay algo que ese perímetro tecnológico no puede hacer: distinguir entre un atacante que entró con credenciales robadas y un usuario legítimo. Si alguien tiene las credenciales de un administrador de dominio, el firewall lo ve como tráfico autorizado. El sistema de detección ve actividad normal de un usuario con privilegios elevados. El endpoint protection no genera alerta porque las credenciales son válidas.

Eso convierte a la identidad en el perímetro que más importa en el contexto de amenazas actual. La mayoría de los incidentes significativos que analizamos en los últimos años, incluyendo el ransomware que afectó a TechCorp Latam, involucran en algún punto el uso de credenciales comprometidas o privilegios mal administrados. No porque el perímetro tecnológico falle, sino porque el atacante lo rodea usando la identidad como llave.

LA BRECHA ENTRE TENER UNA POLÍTICA Y ADMINISTRARLA

La mayoría de las organizaciones medianas que conozco tienen alguna versión de política de gestión de accesos. Hay un documento que dice que las contraseñas deben rotarse cada 90 días. Que los accesos de administrador deben estar justificados y revisados. Que cuando un empleado sale de la organización, sus cuentas deben desactivarse en un plazo definido. Que los accesos de terceros deben tener fecha de vencimiento.

Y luego está la realidad operacional. Contraseñas que llevan 18 meses sin rotación porque el sistema no la exige de forma técnica y nadie la audita. Cuentas de personas que salieron de la organización hace meses, activas en el directorio porque el proceso de offboarding no incluye un paso formal de revocación de accesos. Privilegios de administrador que se otorgaron para un proyecto específico y que nadie retiró cuando el proyecto terminó. Accesos de un proveedor externo que terminó su contrato hace ocho meses y cuya cuenta sigue activa porque nadie llevó el registro.

Cada uno de esos casos es una puerta abierta. No en el firewall, no en el sistema operativo sin parchear. En la capa de identidad, que es exactamente donde los atacantes buscan primero porque es la que más frecuentemente encuentra puertas sin cerrar.

¿POR QUÉ NADIE ESTÁ HACIENDO LA LIMPIEZA?

La revisión y depuración del modelo de acceso es una de esas tareas que todo el mundo reconoce como importante y casi nadie prioriza. Los frenos son predecibles y tienen la misma naturaleza organizacional que los que describí en la semana de gestión de vulnerabilidades.

El primer freno es la transversalidad. Revisar y depurar accesos no es una tarea de TI que se puede hacer en aislamiento. Requiere saber qué sistemas usa cada área, qué personas tienen justificación para qué niveles de acceso, y qué ha cambiado en la organización desde la última vez que alguien revisó. Esa información vive en TI, en Recursos Humanos, en las jefaturas de cada área, y en los contratos con proveedores externos. Coordinar todo eso requiere tiempo y voluntad política que compite con otras prioridades.

El segundo freno es la fricción con usuarios. Depurar accesos implica, en algún momento, restringir el acceso de alguien que lo tenía y que puede percibir esa restricción como un problema operacional. Ese conflicto potencial hace que la revisión se postergue, especialmente cuando quien tendría que impulsarla no tiene el respaldo explícito de la gerencia para hacerlo.

El tercer freno es la invisibilidad del riesgo. Una cuenta huérfana activa no genera alertas. Un privilegio excesivo no aparece en ningún dashboard hasta que alguien lo explota. La ausencia de consecuencias visibles hace que la urgencia de revisar el modelo de acceso sea siempre menor que la urgencia de resolver el problema operacional del día.

LO QUE ESTA SEMANA ANALIZO EN DETALLE

El martes voy a ver las brechas concretas más frecuentes en el modelo de acceso de organizaciones medianas: cuentas huérfanas, privilegios acumulados, contraseñas sin rotación y accesos de terceros sin vencimiento. El miércoles, cómo se hace una revisión real del modelo de acceso y cuáles son las fricciones organizacionales que la frenan. El jueves, el caso TechCorp Latam: las credenciales sin rotación que el ransomware encontró, y qué diferencia habría hecho un proceso de revisión activo. El viernes, quién es responsable del modelo de acceso, y por qué esa responsabilidad suele quedar en un limbo entre TI, RRHH y las jefaturas de área.

DECISIÓN QUE DEBE TOMAR EL CIO

¿Cuándo fue la última vez que se revisó la lista completa de cuentas con acceso a sistemas críticos y se verificó que todos los titulares siguen siendo empleados o contratistas activos con justificación vigente para ese nivel de acceso? Si la respuesta honesta es "no recuerdo" o "no tenemos ese proceso", ese es el primer problema de identidad que hay que resolver, antes de cualquier inversión en tecnología de gestión de identidad.

El atacante que entra con credenciales válidas no rompe el perímetro. Lo usa. Y puede usarlo porque alguien, en algún momento, dejó de administrar quién tenía las llaves y si seguía necesitándolas.

Esta semana en el blog: cinco días analizando la gestión de identidad como decisión organizacional. Mañana: las brechas concretas que aparecen cuando nadie revisa el modelo de acceso.

#IdentidadYAcceso #IAM #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #pfSense #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #NISTCSF #ISO27001 #ActiveDirectory

¿Cómo medir un programa de vulnerabilidades?: las métricas que la gerencia necesita ver

2026-05-20T14:59:59.596-04:00

TÉCNICO-GERENCIAL · MÉTRICAS · GESTIÓN DE VULNERABILIDADES

Tres métricas que convierten la gestión de vulnerabilidades en una conversación ejecutiva. No reemplazan el análisis técnico; lo traducen.

Ayer describí los seis frenos que explican por qué el parche existe y nadie lo aplica. Hoy el ángulo es distinto: cómo saber si el programa de vulnerabilidades está funcionando, con métricas que tengan sentido no solo para el equipo técnico sino para la gerencia que tiene que respaldar las decisiones de inversión y priorización que el programa requiere.

Porque hay un problema estructural en cómo la mayoría de los programas de vulnerabilidades reportan su estado: reportan volumen; Cuántos CVEs se detectaron esta semana; Cuántos son críticos; Cuántos son altos. Esa información es útil para el equipo técnico, pero no le dice nada a la gerencia sobre si la organización está mejorando su postura de seguridad o empeorando. El número de CVEs detectados depende en gran medida de cuánto escaneas y de cuánto crece la superficie de ataque. No es una métrica de gestión; es una métrica de inventario.

Las métricas de gestión miden qué está haciendo la organización con lo que el escáner encuentra. Y hay tres que, en mi experiencia, son las más útiles para llevar la conversación a nivel ejecutivo.

MTTR: EL TIEMPO QUE DICE TODO

El Mean Time to Remediate es el tiempo promedio entre la detección de una vulnerabilidad y su cierre, medido por nivel de criticidad. Es la métrica más directa del programa porque mide velocidad de respuesta real, no actividad.

Los benchmarks de referencia más citados establecen objetivos de 7 días para vulnerabilidades críticas, 30 días para altas y 90 días para medias. Esos números no son absolutos; dependen del sector, del tamaño de la organización y del nivel de madurez del programa. Pero sirven como punto de referencia para una conversación honesta sobre en qué punto está la organización.

Lo que el MTTR revela cuando se analiza con criterio no es solo el número promedio. Es la distribución. Un MTTR promedio de 25 días para vulnerabilidades críticas puede esconder que el 80% se cierran en 5 días y el 20% llevan más de 90. Ese 20% es exactamente donde están los frenos que describí ayer: los sistemas que no se pueden tocar, el EOL sin presupuesto de reemplazo, la dependencia del proveedor. El promedio los oculta. La distribución los expone.

Para organizaciones que recién empiezan a medir el MTTR, el primer número que aparece suele ser sorprendente. He visto MTTRs reales para vulnerabilidades críticas que superan los 60 días en organizaciones que creían tener un programa razonablemente activo. La sorpresa es útil: es el punto de partida para una conversación honesta sobre qué está frenando la remediación.

PORCENTAJE DE CVEs CERRADOS EN SLA: LA MÉTRICA DE CUMPLIMIENTO

Si el MTTR mide velocidad promedio, el porcentaje de CVEs cerrados dentro del SLA mide consistencia. ¿Qué fracción de las vulnerabilidades detectadas se está cerrando en el plazo que el programa comprometió?

Esta métrica solo tiene sentido si existe un SLA definido. Y ese es el primer diagnóstico que hace: si la organización no puede calcular este número porque no tiene SLAs de remediación establecidos, el programa tiene una brecha fundamental antes de cualquier discusión sobre herramientas o recursos.

Los rangos orientativos que uso como referencia: un programa maduro debería cerrar al menos el 85% de sus vulnerabilidades críticas y altas dentro del SLA comprometido. Un programa aceptable, el 70%. Por debajo del 60%, hay algo estructural que está fallando, ya sea el SLA es irreal para la capacidad del equipo, los frenos organizacionales no están siendo gestionados, o las excepciones no tienen proceso formal.

La razón por la que esta métrica es especialmente útil para la conversación ejecutiva es que conecta directamente con compromisos. Cuando la gerencia aprueba un programa de vulnerabilidades con SLAs definidos, el porcentaje de cumplimiento es la evidencia de que el compromiso se está honrando o no. Eso es un lenguaje que los directivos entienden sin necesidad de conocer los detalles técnicos del CVE.

DENSIDAD DE VULNERABILIDADES POR ACTIVO CRÍTICO

El número total de CVEs abiertos en la organización es un número que crece naturalmente con el tiempo y con la superficie de ataque, y que no es comparable entre organizaciones de distinto tamaño. La densidad de vulnerabilidades por activo crítico es un indicador más fino: cuántas vulnerabilidades abiertas tiene cada uno de los sistemas más importantes de la organización.

Definir qué es un activo crítico es el primer paso, y ese ejercicio en sí mismo es valioso: obliga a la organización a nombrar explícitamente cuáles son los sistemas cuyo compromiso tendría mayor impacto. El firewall perimetral. El servidor de autenticación. El sistema de respaldo. El ERP. La plataforma de gestión de clientes. Esos activos deberían tener densidad de vulnerabilidades abiertas igual a cero para CVEs críticos, y una tendencia decreciente para los demás.

Cuando un activo crítico tiene un CVE crítico abierto hace más de 30 días, eso no es un indicador técnico. Es una señal de gobernanza: algo en el proceso está fallando específicamente en ese activo, y alguien con autoridad necesita saberlo y actuar. La densidad por activo crítico es la métrica que hace esa señal visible en el nivel correcto.

ERROR COMÚN

Reportar a la gerencia el número total de vulnerabilidades detectadas como indicador de actividad del programa. Ese número sube cuando escaneas más, no necesariamente cuando la postura empeora. Peor aún, puede generar la percepción de que el programa está "encontrando más problemas", lo que lleva a cuestionarlo en lugar de reforzarlo. Las métricas de gestión, MTTR, SLA y densidad, muestran qué está haciendo la organización con lo que encuentra, que es la pregunta que importa.

¿CÓMO PRESENTAR ESTAS MÉTRICAS A LA GERENCIA?

El formato importa tanto como los números. Lo que he visto funcionar mejor en organizaciones medianas de la región es un reporte ejecutivo mensual de no más de una página, con tres elementos: el estado de los tres indicadores clave contra el objetivo, la tendencia respecto al mes anterior, y los dos o tres ítems que requieren una decisión que excede la autoridad del equipo de TI.

Ese tercer elemento es el más importante para construir el vínculo entre el programa técnico y la gobernanza ejecutiva. "El servidor X tiene un CVE crítico abierto hace 45 días porque requiere una ventana de mantenimiento que el área de negocio no ha aprobado" es una decisión que la gerencia necesita tomar, no que TI puede resolver solo. Hacerla visible en el reporte convierte el programa de vulnerabilidades en una conversación organizacional, no en una lista técnica de pendientes.

DECISIÓN QUE DEBE TOMAR EL CIO

Definir las tres métricas, establecer los SLAs de remediación por criticidad, y comprometerse con un reporte mensual ejecutivo que las incluya. Ese compromiso no requiere nueva tecnología: la mayoría de las herramientas de gestión de vulnerabilidades disponibles en el mercado, incluyendo integraciones con el ecosistema Fortinet o soluciones open source sobre pfSense, pueden exportar los datos necesarios para calcular estas métricas. Lo que requiere es la decisión de hacerlo y la disciplina de mantenerlo.

¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?

Un programa de vulnerabilidades sin métricas de gestión es un programa que no puede demostrar su valor ni identificar sus propias fallas. El equipo técnico puede tener una percepción cualitativa de si las cosas están mejorando o empeorando, pero esa percepción no escala a la gerencia y no produce los cambios organizacionales que los frenos de ayer requieren.

Mañana voy a ver el caso TechCorp Latam: qué vulnerabilidades estaban identificadas antes del incidente de ransomware, qué frenó su remediación, y qué habrían mostrado estas tres métricas si alguien las hubiera estado midiendo.

Sin métricas, la gestión de vulnerabilidades es una actividad técnica que vive dentro de TI. Con métricas que llegan a la gerencia, se convierte en una conversación de riesgo organizacional. La diferencia define si el programa obtiene el respaldo que necesita para funcionar.

Artículo núcleo de la semana: Gestión de vulnerabilidades: la brecha entre saber y actuar. Mañana: el caso TechCorp Latam.

#GestiónDeVulnerabilidades #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #pfSense #TechCorpLatam #CyberLeadership #Liderazgo #Chile #MTTR #CVE #NISTCSF #ISO27001 #KPIs

Los frenos reales de la remediación: ¿por qué el parche existe pero nadie lo aplica?

2026-05-19T20:00:48.828-04:00

TÉCNICO-GERENCIAL · GESTIÓN DE VULNERABILIDADES · REMEDIACIÓN

Los seis frenos de la remediación. Ninguno requiere más tecnología para resolverse. Todos requieren decisión.

Ayer planteé que la brecha entre detectar una vulnerabilidad y remediarla es donde viven la mayoría de los incidentes que después llamamos evitables. Hoy quiero bajar eso a los frenos concretos que explican por qué esa brecha existe y se mantiene en organizaciones que ya saben perfectamente lo que tienen que hacer.

Porque ese es el punto que más me interesa subrayar: en la mayoría de los casos que he analizado, el problema no es falta de conocimiento técnico. El equipo sabe cuál es la vulnerabilidad, sabe cuál es el parche, sabe cómo aplicarlo. El problema es que entre saber y hacer hay una serie de fricciones organizacionales que nadie ha resuelto formalmente, y que en ausencia de un proceso que las gestione, simplemente frenan la remediación indefinidamente.

FRENO 1: LAS VENTANAS DE CAMBIO SIN CARRIL DE SEGURIDAD

El proceso de gestión de cambios es necesario. Reduce el riesgo de interrupciones no planificadas, coordina con las áreas de negocio que dependen de los sistemas, genera trazabilidad para auditoría. No estoy cuestionando su existencia.

Lo que sí es un problema es cuando ese proceso no tiene un carril diferenciado para parches de seguridad críticos. Cuando una vulnerabilidad con CVSS 9.1 y exploit público disponible tiene que esperar la próxima ventana de mantenimiento quincenal junto con el cambio de configuración del servidor de impresión y la actualización del software de inventario, el proceso de cambio está trabajando en contra de la postura de seguridad de la organización.

Un programa maduro de gestión de vulnerabilidades define, en coordinación con el proceso de gestión de cambios, un carril de emergencia para vulnerabilidades críticas con exploit activo, y un carril expedito para vulnerabilidades altas con SLA de remediación no mayor a 72 horas desde la confirmación. Ese acuerdo entre seguridad y operaciones no es técnico: es político, requiere que alguien con autoridad en ambas áreas lo respalde, y tiene que estar documentado como una política, no como una práctica informal.

FRENO 2: LOS SISTEMAS QUE "NO SE PUEDEN TOCAR"

En casi todas las organizaciones medianas hay al menos un sistema del que alguien dice "ese no se puede tocar." A veces es el ERP que corre sobre una versión de sistema operativo que ya no recibe soporte. A veces es el sistema de control de una línea de producción que nadie quiere reiniciar porque la última vez que se reinició costó cuatro horas de inactividad. A veces es el servidor de base de datos que lleva ocho años sin una actualización mayor porque "si funciona, no lo toques."

La lógica detrás de esa postura no es irracional: cambiar un sistema estable tiene un riesgo conocido de interrupción. No cambiarlo tiene un riesgo de seguridad incierto y futuro. El patrón es el mismo que describí la semana pasada con el simulacro de continuidad.

El problema es que "no se puede tocar" en muchas organizaciones no es el resultado de un análisis formal de riesgo con controles compensatorios documentados. Es una convención cultural que se fue instalando sin que nadie la cuestionara formalmente. Cuando el sistema que no se puede tocar tiene una vulnerabilidad crítica explotable, esa convención se convierte en una exposición activa que nadie ha autorizado formalmente pero que todos están aceptando de facto.

ERROR COMÚN

Dejar la decisión de "no tocar" como una práctica implícita en lugar de formalizarla como una excepción de riesgo aceptado. La diferencia importa: una excepción documentada tiene un responsable, tiene controles compensatorios definidos (segmentación de red, monitoreo intensivo, restricción de acceso), y tiene una fecha de revisión. Una práctica implícita no tiene nada de eso. El riesgo es el mismo; la gestión no lo es.

FRENO 3: EL EQUIPAMIENTO EOL SIN DECISIÓN DE REEMPLAZO

Este freno es el más costoso y el más predecible. Cuando un dispositivo o sistema llega al fin de su vida útil de soporte, las vulnerabilidades que se descubren después ya no tienen parche del fabricante. No es que el parche tarde en llegar: es que no va a llegar.

En infraestructuras con switching Cisco EOL, con versiones de FortiOS sin soporte activo, con appliances WatchGuard fuera del ciclo de actualizaciones de seguridad, o con instancias de pfSense sobre hardware sin mantenimiento, las vulnerabilidades que aparece el escáner tienen un estado especial: conocidas, no remediables con parche, y abiertas indefinidamente hasta que alguien tome la decisión de reemplazar el activo.

Esa decisión de reemplazo requiere presupuesto que excede el operacional de TI, planificación de migración, coordinación con el negocio, y en muchos casos un proceso de evaluación y licitación que toma meses. Todo eso es razonable. Lo que no es razonable es dejar esa decisión indefinidamente en el mismo estado de "está en la agenda" en que llevaba TechCorp Latam su switching Cisco EOL durante los años previos al incidente.

El EOL no resuelto no es un problema técnico pendiente. Es una exposición activa con fecha de vencimiento desconocida, que crece con cada nuevo CVE que el fabricante ya no va a parchear.

FRENOS 4, 5 Y 6: LOS QUE NADIE NOMBRA EN LAS REUNIONES

La dependencia de proveedor es un freno que aparece especialmente en software de negocio: el ERP que tiene una vulnerabilidad en la capa de aplicación y cuya solución depende del fabricante del software, no del equipo interno de TI. El equipo sabe que la vulnerabilidad existe. No puede hacer nada hasta que el proveedor libere la actualización. Y el proveedor tiene su propio calendario. Mientras tanto, la vulnerabilidad permanece abierta.

La brecha de conocimiento es menos frecuente pero más delicada. En algunos casos el equipo técnico sabe que hay una vulnerabilidad crítica en un sistema complejo, y sabe que hay un parche disponible, pero no tiene la experiencia suficiente para aplicarlo sin riesgo de afectar el sistema. Parchear un firewall Fortinet bajo carga en producción, actualizar el firmware de un switch de core con VLANs de misión crítica, o aplicar un parche a un servidor de base de datos con réplicas activas requiere conocimiento específico que no siempre está en el equipo. Y la alternativa, aplicarlo sin ese conocimiento, puede ser peor que la vulnerabilidad.

El conflicto de prioridades es quizás el más honesto de los seis frenos. Los equipos de TI en organizaciones medianas tienen más trabajo del que pueden absorber. La remediación de vulnerabilidades compite con la migración en curso, con el soporte al usuario, con el proyecto de implementación que tiene fecha de entrega comprometida con el cliente. Cuando no hay una política que establezca la prioridad relativa de la remediación de seguridad frente a otros proyectos, siempre pierde frente a lo que tiene un deadline visible.

DECISIÓN QUE DEBE TOMAR EL CIO

Identificar cuáles de estos seis frenos están activos en la organización y cuál es el que más vulnerabilidades tiene bloqueadas. Ese diagnóstico no requiere una herramienta nueva: requiere una conversación honesta con el equipo técnico sobre qué está frenando la remediación de las vulnerabilidades que ya están identificadas. La respuesta a esa conversación define dónde hay que intervenir primero, y casi nunca es en la herramienta de detección.

¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?

Lo que tienen en común los seis frenos es que ninguno es técnico. Todos son organizacionales: procesos que no contemplan la urgencia de seguridad, convenciones culturales que nunca se formalizaron, decisiones de inversión que nadie quiere llevar a la gerencia, brechas de capacidad que nadie ha priorizado cerrar.

Y todos tienen solución. No necesariamente rápida ni barata, pero sí definible. El carril de emergencia en la gestión de cambios es un acuerdo político entre dos áreas. La excepción del sistema que no se puede tocar es un proceso de documentación y controles compensatorios. El EOL es una decisión de inversión con argumentos concretos. La dependencia de proveedor es un SLA contractual que se negocia. La brecha de conocimiento es una decisión de capacitación o de soporte externo. El conflicto de prioridades es una política de clasificación de trabajo.

Mañana voy a ver cómo medir el programa de vulnerabilidades con métricas que tengan sentido para la gerencia, no solo para el equipo técnico.

El parche que no se aplica no es un problema técnico pendiente. Es una exposición activa con fecha de vencimiento desconocida. La diferencia entre las dos formas de verlo define cómo la organización va a priorizar resolverlo.

Artículo núcleo de la semana: Gestión de vulnerabilidades: la brecha entre saber y actuar. Mañana: cómo medir el programa con métricas ejecutivas.