Hardening y bastionado de sistemas

Es el proceso de reducir la superficie de ataque de un sistema mediante configuración: deshabilitar servicios y protocolos innecesarios, aplicar políticas de autenticación robustas, limitar privilegios al mínimo necesario, activar registros que permitan investigar incidentes, separar planos de gestión de los de producción y verificar todo contra una guía reconocida (CIS Benchmarks, DISA STIG o equivalente del fabricante). No es parchear vulnerabilidades —eso es gestión de parches— ni instalar un antivirus. Es asegurar que, aunque haya parches al día y EDR encima, el sistema no presente configuraciones débiles aprovechables.

Combinamos varias según plataforma. Como base usamos CIS Benchmarks (Center for Internet Security) porque cubre el mayor catálogo y mantiene actualización continua. Para entornos de defensa, gobierno y críticos añadimos DISA STIG cuando el cliente lo exige por contrato. Microsoft Security Baselines para todo lo que toca Microsoft 365 y Windows Server. Recomendaciones de fabricante para vSphere, NetApp, Cisco, F5, Palo Alto y similares. Para cloud, Well-Architected Framework (AWS/Azure/GCP) cruzado con CIS Cloud. El criterio: la guía más estricta que el negocio pueda absorber sin romper operación.

Porque EDR y firewalls son capas de detección y contención reactivas. El hardening reduce el número y la gravedad de los caminos que el atacante puede recorrer antes de que el EDR lo vea. Casos típicos: SMBv1 habilitado, NTLMv1 permitido, LM Hash almacenado, contraseñas locales reutilizadas en cientos de equipos, RDP expuesto sin NLA, configuración débil de TLS, permisos de bucket S3 demasiado amplios, cuentas privilegiadas usadas para tareas rutinarias. Ninguna de esas cosas se arregla con un parche ni la detecta automáticamente un EDR como problema activo. Y todas son las que un atacante explota antes de tocar nada que dispare alerta.

Lo que use el cliente. Sistemas operativos: Windows Server 2016/2019/2022, Windows 10/11 cliente, Linux (RHEL, Ubuntu Server, Debian, SUSE, Amazon Linux). Virtualización: VMware vSphere/ESXi, Hyper-V, Proxmox, Nutanix. Contenedores: Docker, Kubernetes (kubeadm, EKS, AKS, GKE, Rancher), runtime containerd/CRI-O. Cloud: AWS, Azure, GCP — cuenta, IAM, red, almacenamiento, cómputo, gestión. Productividad: Microsoft 365, Google Workspace. Bases de datos: SQL Server, Oracle, PostgreSQL, MySQL, MongoDB, Redis. Red: Cisco IOS/NX-OS, Juniper, Fortinet, Palo Alto, F5, Aruba. Identidad: Active Directory, Entra ID, Okta, Keycloak. Si el cliente trabaja con plataformas muy verticales, lo evaluamos en walkthrough.

Depende del alcance. Bastionado de una flota de 30-80 Windows Server o equivalente: 3-6 semanas con 1-2 ingenieros, coste orientativo 14-32 mil euros. Proyecto multi-plataforma para empresa mediana (servidores + virtualización + cloud + M365 + red): 8-16 semanas, 1-3 ingenieros, 40-110 mil euros. Antes de presupuestar pedimos un walkthrough técnico para entender el inventario real, las dependencias operativas y el apetito de riesgo de cambios disruptivos. Sin eso, cualquier cifra es estimación. La operación posterior (vigilancia de drift, nuevos sistemas, actualizaciones de benchmarks) se gestiona con suscripción mensual.

Es la pregunta correcta y la razón por la que el proceso siempre incluye fase de pruebas en entorno réplica antes de tocar producción, ventana de mantenimiento programada, plan de rollback documentado, y propagación gradual (canary deployment: 5% → 25% → 100% con ventanas de validación). Cada cambio se documenta como código (Ansible, DSC, Terraform, scripts) para que sea reproducible, auditable y reversible. Los controles que el negocio no puede absorber se documentan como excepción justificada con plazo y compensación; no se aplican por dogma.

Sí, vuelve a degradarse —se llama drift— y por eso el hardening no es un proyecto puntual sino una práctica continua. Tras la fase inicial entregamos: configuración como código (idempotente, en repositorio versionado), reglas de detección de drift en SCAP/OpenSCAP, AWS Config, Azure Policy, GCP Forseti, Kubernetes Gatekeeper o lo que aplique según plataforma, dashboard de cumplimiento por sistema, alertas operativas en SIEM cuando un control crítico cambia. Si se contrata operación continua, asumimos la vigilancia con cadencia mensual de reporting y revisión trimestral con el cliente.

ENS exige configuración de seguridad documentada y verificable (op.pl.2, op.pl.5, mp.s.2 mp.eq.4 entre otros) y el bastionado es el mecanismo natural de cumplirlo. ISO 27001:2022 (A.8.9 Configuration management) cubre explícitamente la gestión de configuración segura. NIS2 art. 21.2.e exige medidas en ciberhigiene y configuración segura. DORA art. 9 + RTS de gestión TIC lo recoge en controles técnicos. El paquete documental que entregamos —baseline, evidencia de aplicación, gestión de excepciones, plan de revisión, monitorización de drift— está diseñado para sostener auditoría externa sin trabajo adicional del cliente.

Lo que mejor encaje. Si ya tenéis Ansible, Puppet, Chef, Terraform o módulos de DSC, trabajamos sobre lo existente: añadimos roles/módulos nuevos, ampliamos los actuales, integramos en vuestro CI/CD. Si no hay nada, lo construimos como entregable —preferentemente Ansible para sistemas operativos y Terraform o Bicep/ARM para cloud— en repositorio del cliente, con documentación, pipeline de validación y formación al equipo de operación. No imponemos herramienta: nos adaptamos a lo que el equipo va a mantener sin fricción.

Llamada de 30 minutos para entender el inventario aproximado (cuántos sistemas, qué plataformas, dónde corren), el motivo (cumplimiento, post-incidente, modernización, exigencia de cliente) y el apetito de cambios disruptivos. Si tiene sentido, walkthrough técnico de 1-3 horas con un sysadmin o ingeniero de plataforma. Con eso emitimos propuesta firme en 48-72 horas: alcance, ventana, equipo, entregables y precio cerrado. Sin compromisos hasta la firma. Si vemos que conviene partir el proyecto en fases o combinarlo con gestión de vulnerabilidades, lo decimos honestamente.