TechCorp Latam tenía un proveedor de ciberseguridad contratado. Tenía un contrato, tenía un número de contacto, tenía reportes mensuales que llegaban puntualmente con gráficos y métricas. Y fue comprometida igual.
La reacción más común ante ese tipo de situación es buscar culpables hacia afuera: el proveedor falló, el contrato no cubría lo necesario, la consultora no cumplió. A veces eso es cierto. Pero con más frecuencia de la que se admite, el problema es anterior al proveedor: está en cómo la organización entendió, o no entendió, lo que estaba comprando.
Externalizar la ciberseguridad no transfiere la responsabilidad. Esa frase suena simple. Las consecuencias de no entenderla son complejas y costosas.
El error de comprar tranquilidad en lugar de seguridad
Cuando una organización contrata un proveedor de ciberseguridad, hay dos formas muy distintas de llegar a esa decisión. La primera es estratégica: se analiza qué capacidades faltan internamente, se define qué se necesita del proveedor, se establecen métricas de desempeño concretas y se mantiene supervisión activa del servicio. La segunda es la más común: se contrata porque algo salió mal, porque el directorio pidió "hacer algo", o porque tener un proveedor genera la sensación de que el problema está cubierto.
La segunda forma es comprar tranquilidad, no seguridad. Y la tranquilidad tiene un problema: desactiva la vigilancia interna. Cuando el directorio cree que "ya hay alguien viendo eso", las preguntas difíciles dejan de hacerse. ¿Cuándo fue la última prueba de recuperación de backups? ¿Qué tan rápido detectaríamos un movimiento lateral en la red interna? ¿Quién tiene acceso privilegiado a los sistemas críticos y desde cuándo? Si la respuesta implícita es "eso lo maneja el proveedor", hay un problema serio.
En el caso de TechCorp Latam, la contratación del proveedor de ciberseguridad ocurrió después de señales de alerta que no fueron atendidas con suficiente profundidad. Infraestructura con años de antigüedad, controles de acceso que nunca habían sido auditados formalmente, segmentación de red insuficiente. El proveedor llegó a un entorno con brechas estructurales y un mandato que no incluía resolverlas. El resultado fue predecible.
¿Qué salió mal?, punto por punto
El análisis post-incidente de TechCorp Latam identificó varios factores que operaron en conjunto. Ninguno por sí solo causó el incidente; la combinación de todos ellos lo hizo posible.
El alcance del contrato no cubría los vectores reales de riesgo. El proveedor monitoreaba el perímetro y generaba reportes de amenazas externas. El vector de entrada del incidente, sospechado pero nunca confirmado, fue un dispositivo interno con acceso a la red; el servidor Dahua de las cámaras de seguridad. El movimiento lateral posterior ocurrió en segmentos de red que no estaban dentro del alcance de monitoreo contratado. El proveedor no vio lo que no estaba mirando, y nadie había definido que debía mirarlo.
No existía un modelo de responsabilidad compartida documentado. En servicios cloud, el modelo de responsabilidad compartida es explícito: el proveedor es responsable de la infraestructura, el cliente es responsable de los datos y las configuraciones. En ciberseguridad externalizada, ese modelo raramente se documenta con el mismo nivel de claridad. ¿Quién es responsable de verificar que los parches se aplican? ¿Quién define las reglas del firewall perimetral Fortinet? ¿Quién audita los accesos privilegiados? Si esas preguntas no tienen respuesta explícita en el contrato, la respuesta implícita es nadie.
La organización había dejado de desarrollar capacidad interna. Al contratar el proveedor, el equipo interno redujo su foco en seguridad bajo el supuesto de que "eso ya estaba cubierto". Con el tiempo, el conocimiento interno sobre la configuración real de la infraestructura, sobre los accesos existentes y sobre los riesgos específicos del entorno fue degradándose. Cuando el incidente ocurrió, el equipo interno tardó más tiempo del necesario en diagnosticar porque parte del conocimiento operativo estaba en manos del proveedor, no en manos propias.
Los reportes mensuales medían actividad, no riesgo real. Los informes del proveedor reportaban cantidad de alertas procesadas, intentos de intrusión bloqueados, eventos correlacionados. Ninguno de esos indicadores reflejaba el estado real de la superficie de ataque interna: la antigüedad de la infraestructura Cisco, la cobertura de parches en pfSense y Ubiquiti, la solidez de la segmentación de red, el estado de los backups en VEEAM. Métricas de actividad que generaban sensación de control sin respaldarlo.
Lo que el proveedor no puede hacer por tu organización
Hay capacidades que un proveedor externo puede proveer genuinamente bien: monitoreo 24/7 que un equipo interno pequeño no puede sostener, acceso a inteligencia de amenazas actualizada, especialización en áreas específicas como análisis forense o respuesta a incidentes, perspectiva externa sobre la postura de seguridad. Todo eso tiene valor real.
Lo que ningún proveedor puede hacer, independientemente de cuánto se pague o de qué tan bueno sea, es lo siguiente: conocer tu infraestructura mejor que tú. Un consultor externo puede auditar la configuración del FortiGate perimetral o del WatchGuard en sucursales. No puede saber que hay un servidor Dahua conectado a la red corporativa con acceso irrestricto porque "siempre estuvo ahí". Ese conocimiento vive adentro de la organización, o no vive en ningún lado.
Tampoco puede generar la cultura de seguridad que determina si un empleado reporta un correo sospechoso o lo ignora, si el equipo de TI documenta los cambios de configuración o los hace sin registro, si el acceso de un empleado que salió se deshabilita el mismo día o queda activo semanas después. Esas decisiones ocurren adentro, en el día a día, y no tienen solución contractual.
Lo que TechCorp Latam hizo diferente después
Después del incidente, la relación con proveedores externos de ciberseguridad se reestructuró completamente. No se eliminó: se redefinió. El nuevo modelo incluyó tres cambios fundamentales.
Primero, un inventario completo de la infraestructura como punto de partida. Antes de cualquier contrato de monitoreo, la organización documentó cada dispositivo en red: los firewalls Fortinet reemplazando el WatchGuard anterior, los nuevos switches y access points Fortinet con administración centralizada, los dispositivos IoT como las cámaras, los servidores en Azure y los que permanecían on-premise. El proveedor no puede monitorear lo que no sabe que existe.
Segundo, un modelo de responsabilidad compartida explícito en el contrato. Qué monitorea el proveedor, con qué SLA de respuesta, qué hace el equipo interno ante cada tipo de alerta, quién tiene autoridad para tomar decisiones de contención. Sin ambigüedad sobre quién hace qué cuando algo ocurre a las 4 de la mañana.
Tercero, métricas de riesgo real en lugar de métricas de actividad. El reporte mensual dejó de contar alertas procesadas y empezó a medir: cobertura de parches en activos críticos, MTTR por tipo de incidente, estado de segmentación verificado, fecha de última prueba de recuperación de backups. Indicadores que dicen algo sobre la postura real de seguridad, no sobre la actividad del proveedor.
Contratar un proveedor de ciberseguridad es una decisión correcta en muchos contextos. El error no está en externalizar capacidades; el error está en externalizar la responsabilidad. Esa distinción, bien entendida antes de firmar el contrato, cambia completamente el resultado.
¿Tu organización tiene un proveedor de ciberseguridad, o tiene seguridad?
Suscríbete al newsletter Cybersecurity Insights en LinkedIn. Casos reales, análisis sin filtro corporativo, cada semana.
#Ciberseguridad #CasoDeEstudio #TechCorpLatam #CIO #ITManager #Fortinet #Cisco #WatchGuard #pfSense #ISO27001 #NISTCSF #GestiónDeRiesgos #Outsourcing #CyberLeadership #Chile
Comentarios
Publicar un comentario