Bastionado (Hardening)

El bastionado es la práctica de fortalecer un sistema o una red configurándolos para que expongan y permitan lo menos posible. También se le llama por su nombre inglés, hardening, y las dos formas conviven en español: las guías CCN-STIC y la documentación del ENS usan bastionado.

El objetivo es reducir la superficie de ataque: desactivar los servicios que no se usan, retirar las configuraciones por defecto que se pueden aprovechar y dejar solo los permisos necesarios. No se aplica solo al sistema operativo, sino también a las aplicaciones, a los dispositivos de red y a cualquier componente que ejecute código de un tercero.

En la práctica son cuatro frentes. Configuración segura de sistemas, aplicaciones y equipos de red. Actualizaciones y parches al día, que es un trabajo distinto y complementario, el de la actualización de seguridad. Gestión de cuentas y accesos, con contraseñas robustas, cuentas innecesarias retiradas y privilegios mínimos. Y monitorización y registro de la actividad, porque un sistema bastionado que no deja rastro no se puede auditar después.

El software se entrega configurado para funcionar en todas partes y para todo el mundo. Eso significa servicios activados que la mayoría de las instalaciones no usa nunca, protocolos antiguos encendidos por compatibilidad, permisos concedidos con manga ancha para que nada se rompa durante la puesta en marcha, y valores por defecto habladores que ayudan igual a un administrador y a un atacante. El bastionado es el proceso de restar de ahí.

Trabaja sobre cuatro capas, y estas suelen tener dueños distintos, que es por lo que se deteriora. Retirar lo que no hace falta: roles, paquetes, contenido de ejemplo, servicios de red sin uso. Cerrar los valores por defecto: credenciales por defecto, acceso anónimo, recursos compartidos permisivos, protocolos de autenticación antiguos, interfaces de gestión activadas y sin usar. Restringir lo que queda: atar los servicios a la interfaz que les corresponde, ejecutarlos con cuentas que tengan los derechos justos, exigir cifrado. Y demostrar el estado: aplicar la configuración desde una línea base que se impone de forma continua en vez de teclearse una vez.

Las líneas base están publicadas, no hay que inventarlas. Los CIS Benchmarks cubren la mayoría de los sistemas operativos, bases de datos y servicios cloud habituales, con su razonamiento por cada punto. En el sector público español la referencia son las guías CCN-STIC, y no son opcionales: una auditoría de ENS espera ver aplicada la guía que corresponda, o un motivo documentado de por qué no. Los fabricantes publican sus propias líneas base de seguridad para sus plataformas. Elegir a cuál te acoges es una decisión que se toma una vez y se deja escrita.

El bastionado importa más de lo que sugiere su fama de tarea gris, y el motivo es de tiempos. Parchear arregla un fallo conocido después de conocerse. El bastionado decide qué puede hacer un atacante el día en que un fallo todavía no se conoce, y decide a qué puede llegar cuando un correo de phishing funciona. Esas son las dos situaciones en las que todo lo demás ya ha fallado.

El bastionado se aplica al construir y después no lo impone nada. Seis meses de cambios más tarde, se volvió a activar un servicio para que funcionara una integración, se amplió un permiso durante un incidente y no se volvió a estrechar, se concedió una excepción para el agente de un proveedor. La construcción estaba bastionada; el parque no. En un proyecto, la diferencia entre la imagen maestra y la máquina viva es justo donde trabajamos.

La propia imagen maestra es el segundo problema. Se clona, y con ella se clona todo lo que lleva dentro: la contraseña del administrador local, el agente que se instaló con una credencial incrustada, el certificado, la tarea programada que apunta a un recurso compartido. Una imagen comprometida una vez son todas las máquinas construidas a partir de ella.

El tercero es la excepción que se hace permanente. La autenticación antigua es el caso más claro. Se desactiva como parte de una línea base, el dispositivo de un departamento no lo lleva bien, se escribe una excepción para ese departamento, y dos años después la excepción cubre el parque entero porque nadie la volvió a probar. Esa excepción es la razón de que se pueda saltar la autenticación multifactor en un tenant que se cree que la impone en todas partes, y es una de las primeras cosas que buscamos.

El cuarto es lo que sigue confiando una máquina bastionada. Llegamos a un puesto de trabajo configurado exactamente según el benchmark, y guarda una credencial en caché, una unidad mapeada a un recurso compartido con permisos amplios, y un agente de gestión al que se le puede dar órdenes desde un servidor al que llegamos. Bastionar la máquina no cambió con quién se le permitía hablar, y el movimiento lateral no necesita una máquina mal configurada cuando una bien configurada tiene el mismo acceso.

Las organizaciones discuten sobre esto y la discusión suele ir de obligaciones y no de mérito técnico. Las tres se solapan mucho en la sustancia.

La guía práctica: si estás dentro del ámbito del ENS, arranca de la guía CCN-STIC de la categoría, porque es lo que te va a pedir el auditor. Si no, arranca de CIS para el sistema operativo y de la línea base del fabricante para la plataforma del fabricante, porque el fabricante sabe qué ajustes rompen su producto. Lo que importa mucho más que la elección es que se elija una, se aplique por política y se mida de forma continua.

Aplicar un benchmark entero de golpe en producción. Algunos puntos rompen cargas de trabajo reales. Prueba, decide punto por punto y deja escrita la decisión con un responsable. Un benchmark aplicado a ciegas y luego revertido te deja sin el ajuste y sin el registro.

Bastionar el sistema operativo e ignorar la capa de identidad. Un servidor configurado a la perfección cuyo grupo de administradores locales contiene un grupo de dominio con doscientos miembros no está bastionado de ninguna forma que le cambie el día a un atacante.

Tratarlo como un proyecto. La configuración se deteriora sin parar, así que el control es la medida continua, no un ejercicio con fecha de fin.

Confundirlo con la gestión de parches. Resuelven mitades distintas. Parchear retira fallos conocidos; bastionar reduce a qué llega cualquier fallo. Un parque que solo parchea está completamente expuesto el día que aparece un fallo nuevo.

Dejar la misma contraseña de administrador local en todas las máquinas. Es la vía más rápida para cruzar un parque y convierte un puesto comprometido en todos ellos.

Lleva la configuración a código y aplícala de forma continua. Una herramienta de gestión de configuración, un motor de políticas de cloud o una política de grupo que se reaplique con una periodicidad convierten el deterioro en una medida en vez de en un descubrimiento. Lo que importa no es que un ajuste se hiciera, sino que se rehaga cada vez que algo lo cambia.

Después mide contra la línea base e informa de las excepciones, no del porcentaje de cumplimiento. Un porcentaje esconde las dos máquinas que importan. La lista de excepciones con su responsable y su fecha es el documento que merece la pena revisar.

Aleatoriza las contraseñas de administrador local por máquina, para que la credencial recuperada en una no valga nada en la siguiente. Desactiva los protocolos de autenticación antiguos de forma centralizada y audita las excepciones cada mes. Ata las interfaces de gestión a una red de gestión. Y vuelve a pasar la medida después de cada actualización de plataforma, porque las actualizaciones reintroducen valores por defecto.

El bastionado se empareja directamente con la reducción de la superficie de ataque: una retira lo que se alcanza desde fuera y el otro retira lo que se puede usar una vez dentro.

La revisión de configuración forma parte de la mayoría de los proyectos internos y de cloud, y el hallazgo se escribe contra el ajuste y el grupo de máquinas, con el punto del benchmark referenciado donde exista, para que el cliente pueda actuar sin un paso de traducción. Registramos el valor observado, el valor esperado y qué nos permitió hacer la diferencia, porque lo último decide la prioridad.

La severidad no es la severidad del benchmark. Es lo que la configuración incorrecta nos dio en este parque. El mismo recurso compartido permisivo es una observación en una máquina de pruebas aislada y un hallazgo crítico cuando guarda un script con la contraseña de una cuenta de servicio dentro. Un hallazgo de configuración sin consecuencia demostrada se escribe como tal, con honestidad, en vez de inflarlo.

El trabajo de línea base sobre plataformas de colaboración y tenants de identidad es el objeto de una revisión dedicada de la configuración de Microsoft 365, donde los ajustes por defecto son permisivos por diseño y la distancia entre lo que viene de fábrica y lo bastionado es inusualmente grande.

¿Cuál es la diferencia entre bastionado y parcheo? Parchear retira fallos conocidos concretos. Bastionar reduce a qué puede llegar y qué puede reutilizar cualquier fallo, conocido o no. Hacen falta los dos, y el bastionado es lo que te sostiene durante la ventana entre que un fallo existe y que se aplica un parche.

¿Qué línea base de bastionado deberíamos usar? Aquella a la que apunten tus obligaciones, aplicada con constancia. CCN-STIC donde se aplique el ENS, CIS Benchmarks para una cobertura amplia, y la línea base del fabricante para la plataforma de ese fabricante. La constancia y la medida continua importan más que la elección entre ellas.

¿El bastionado rompe cosas? Algunos puntos sí, y por eso se aplican probando y no por decreto. El proceso honesto es aplicar la línea base en un entorno de pruebas, dejar escritas las excepciones que necesites con un motivo y un responsable, y volver a revisarlas, en vez de abandonar la línea base tras la primera caída.

¿Bastionado es lo mismo que hardening? Sí. Es el término español habitual para el mismo trabajo, y es el que usan las guías CCN-STIC y la documentación del ENS.