¿Y si el atacante ya entró? La pregunta que separa la ciberseguridad de la ciberresiliencia

Firewall. WAF. EDR. MFA. SIEM. Si su organización tiene todo eso desplegado y funcionando, probablemente se siente protegida.

Y sin embargo, esa misma organización puede no sobrevivir a un ataque exitoso.

No porque las herramientas fallen, sino porque responden a una pregunta distinta de la que realmente importa. La ciberseguridad tradicional pregunta "¿cómo evitamos que el atacante entre?". La ciberresiliencia parte de una pregunta más incómoda:

¿Qué pasa si entra de todas maneras?

¿Puede moverse lateralmente? ¿Llega a comprometer identidades privilegiadas? ¿Alcanza los backups? ¿Cuánto del negocio sigue operando mientras se contiene el incidente? ¿Desde dónde se recupera, y en cuánto tiempo?

Esta es la tesis: muchas empresas creen que están seguras porque invirtieron en impedir la entrada. Pocas se han preparado para lo que pasa después de que alguien entra igual. Y con IA generativa acelerando el phishing dirigido, la automatización de reconocimiento y la velocidad con la que se explotan vulnerabilidades nuevas, esa probabilidad de "entrar igual" ya no es una posibilidad remota. Es, cada vez más, cuestión de tiempo.

Dos arquitecturas, una misma organización

La mayoría de organizaciones tiene, en la práctica, algo así:

No hay nada mal en esto. Cada componente es necesario. El problema no es tenerlos: es asumir que tenerlos es la resiliencia.

Esta es una arquitectura preventiva. Está optimizada para reducir la probabilidad de que el atacante entre. No responde qué pasa cuando entra igual, y estadísticamente, tarde o temprano, entra.

Una arquitectura resiliente parte del mismo perímetro, pero con otra lógica:

Prevent → Detect → Contain → Continue → Recover → Evolve

Se asume que el intento de intrusión va a ocurrir (Prevent), que en algún punto tendrá éxito parcial (Detect), y que a partir de ahí lo que define la supervivencia del negocio es qué tan rápido se limita el daño (Contain), qué tan bien sigue operando lo esencial mientras eso pasa (Continue), qué tan rápido se restablece el servicio (Recover) y qué tanto cambia la arquitectura después del incidente (Evolve).

En alto nivel, se vería así:

La diferencia entre ambas arquitecturas no está en los productos. Está en el diseño de las rutas de falla: qué pasa cuando un componente cae, y qué tan lejos puede llegar ese daño antes de que algo más lo contenga.

Blast radius: la pregunta que cambia el diseño

No se trata solo de evitar que un atacante entre. Se trata de limitar cuánto daño puede causar una identidad, un endpoint o un segmento comprometido antes de ser contenido. A esto se le llama blast radius: el radio de impacto.

El ransomware expone esto con crudeza. Un atacante que compromete una sola credencial no necesita "romper" el firewall: si esa credencial tiene acceso amplio, sin segmentación ni control de identidades privilegiadas, puede moverse lateralmente hasta alcanzar sistemas críticos y, con frecuencia, los propios backups.

Y ahí está el punto central: un backup que el atacante puede cifrar junto con producción no es una estrategia de recuperación. Es una copia adicional del mismo problema. Por eso los backups inmutables, las copias aisladas y el control de accesos privilegiados (PAM) no son "extras" de seguridad: son la diferencia entre recuperarse en horas o negociar con un atacante porque no queda otra opción.

La pregunta correcta no es únicamente "¿cómo evitamos la intrusión?". Es: ¿la arquitectura permite que una parte de la organización sea comprometida sin que toda la empresa deje de operar?

Lo que esto le cambia al Project Manager

Soy PMP y he gestionado proyectos tecnológicos y de ciberseguridad. Durante años el foco fue alcance, cronograma, presupuesto, riesgos y proveedores. Eso sigue siendo necesario y no va a dejar de serlo.

Pero dirigir un proyecto de infraestructura o ciberseguridad sin entender la arquitectura tiene un costo concreto. Es la diferencia entre firmar un cronograma y poder cuestionarlo con criterio:

• ¿Qué dependencias reales existen entre esta capa y la siguiente, más allá de las que aparecen en el diagrama del proveedor?
• ¿Qué supuesto está dando por sentado el equipo técnico que nadie ha verificado?
• ¿Dónde está el single point of failure que no se mencionó en el kickoff?
• Si cambiamos este componente, ¿qué más se mueve con él?
• ¿Puedo sostener una conversación técnica con el arquitecto o el especialista de seguridad sin depender de que me traduzcan todo?
• ¿Esta decisión técnica en qué afecta la continuidad del negocio, no solo el cronograma del proyecto?

Un PM que no puede responder estas preguntas termina gestionando actas, fechas y proveedores, mientras las decisiones que realmente definen el proyecto se toman sin él. Un PM que sí puede responderlas se vuelve el puente entre negocio y arquitectura — y ese es un lugar mucho más difícil de reemplazar.

El PM tecnológico del futuro necesita aumentar progresivamente su profundidad técnica. No para dejar de ser PM, sino porque esa profundidad es lo que abre la puerta hacia Solution Architecture, Cybersecurity Architecture o AI Architecture. Es, en buena medida, el camino que yo misma vengo recorriendo.

El cierre

La ciberseguridad tradicional mide el éxito por lo que impidió. La ciberresiliencia lo mide por lo que la organización sigue pudiendo hacer después de que algo salió mal. Ninguna arquitectura, por bien construida que esté, elimina el riesgo de una intrusión. La pregunta que de verdad separa a las organizaciones no es si tienen firewall, sino si diseñaron algo capaz de seguir en pie cuando el firewall ya no fue suficiente.