El perímetro de red ha desaparecido y la identidad ha ocupado su lugar. Una base práctica para defender sistemas que viven en todas partes, y por qué planificar la respuesta importa más que prevenir.
Los supuestos que dieron forma a la seguridad corporativa durante dos décadas ya no se sostienen. Ya no hay un borde de red que defender: la plantilla trabaja desde casa, las aplicaciones se ejecutan en el centro de datos de otro y los datos se mueven entre servicios que la organización no posee. Una seguridad construida alrededor de un perímetro protege una forma que ha dejado de existir.
Cuando las aplicaciones son accesibles desde cualquier sitio, la credencial se convierte en el control. La inmensa mayoría de las intrusiones no empiezan con un exploit sofisticado, sino con un inicio de sesión válido usado por la persona equivocada: obtenido por phishing, reutilizado de otra brecha o sencillamente nunca revocado cuando alguien se fue.
Esto reordena las prioridades. La autenticación multifactor en toda cuenta que pueda llegar a algo sensible es el control de mayor valor disponible para la mayoría de las organizaciones, y en muchísimas sigue desplegado a medias. Revisar quién tiene acceso de verdad, y retirar lo que ya no hace falta, es poco vistoso y funciona de forma consistente.
Los sistemas modernos se ensamblan, no se construyen. Cada integración, cada plugin y cada servicio gestionado es un camino hacia tu entorno que no controlas del todo. Los atacantes lo saben bien: comprometer a un proveedor permite alcanzar a cientos de sus clientes de una sola vez.
Esto no significa evitar a los terceros, que no es posible. Significa saber cuáles tienen acceso a qué, exigir evidencias de su postura de seguridad en lugar de garantías verbales, y poder cortar una conexión rápidamente cuando algo va mal.
La mayoría de los ataques con éxito no requieren técnicas novedosas. Requieren un hueco en lo básico. Una base defendible tiene este aspecto:
Parchea con un calendario que puedas cumplir de verdad. Un proceso de parcheo imperfecto que se ejecuta cada mes vale más que uno ideal que se ejecuta cuando alguien se acuerda.
Mínimo privilegio, aplicado. Los permisos de administración concedidos «temporalmente» tienen la costumbre de volverse permanentes. Cada cuenta debe tener el acceso que el rol necesita y nada más.
Copias de seguridad que se han restaurado. Una copia que nadie ha probado es una hipótesis. La respuesta ante un ransomware depende por completo de que la restauración funcione, y eso se descubre en un simulacro o en una crisis.
Registros que puedas consultar. Cuando ocurre un incidente, la pregunta es qué tocó el atacante y cuándo. Sin registros conservados y consultables esa pregunta no tiene respuesta, y la investigación se convierte en conjeturas.
La diferencia entre un incidente y una catástrofe suele estar en la preparación, no en la prevención. A quién se llama a las dos de la madrugada. Quién puede autorizar dejar un sistema de producción fuera de servicio. Qué se comunica a los clientes, y quién lo comunica. A qué regulador hay que notificar, y en qué plazo: en la UE, ese plazo es corto.
Las organizaciones que han ensayado esto se recuperan en días. Las que lo descubren durante el incidente se recuperan en semanas, y el coste de esa diferencia rara vez es técnico.
La seguridad añadida al final de un proyecto es cara y parcial. Incorporada desde el principio —en cómo se gestiona la identidad, cómo se segmentan los datos, cómo se despliega— resulta mucho más barata y bastante más eficaz. El panorama de amenazas seguirá cambiando. La disciplina que lo afronta, no.