21. Validación defensiva: escaneo, pruebas de configuración, auditorías y benchmarks CIS

21.1 Introducción

Una regla de firewall puede estar creada pero mal ubicada. Un servicio puede parecer cerrado pero seguir escuchando en otra interfaz. Un servidor puede tener hardening parcial. Un IDS puede estar activo pero sin recibir tráfico. Por eso la validación defensiva es esencial.

Validar significa comprobar con evidencia que los controles cumplen su objetivo. No se trata solo de confiar en la configuración declarada, sino de observar resultados: qué está expuesto, qué se bloquea, qué se registra y qué alertas se generan.

En este tema veremos escaneos, pruebas de configuración, auditorías, benchmarks CIS, manejo de hallazgos y seguimiento de remediación.

21.2 Qué es validación defensiva

La validación defensiva es el proceso de verificar que los controles de seguridad estén correctamente implementados y sean efectivos para reducir riesgo.

Puede incluir:

• Escaneo de puertos y servicios.
• Escaneo de vulnerabilidades.
• Revisión de reglas de firewall.
• Pruebas de segmentación.
• Validación de logs y alertas.
• Auditoría de permisos.
• Comparación contra benchmarks.
• Pruebas de restauración y continuidad.

21.3 Escaneo de puertos

El escaneo de puertos permite identificar qué servicios están escuchando en un sistema o red. Es una forma básica pero muy útil de revisar exposición.

Preguntas que responde:

• ¿Qué puertos están abiertos?
• ¿Coinciden con lo documentado?
• ¿Hay servicios administrativos expuestos?
• ¿Un servidor escucha en interfaces no esperadas?
• ¿La regla de firewall bloquea lo que debería bloquear?

El resultado debe compararse contra la función real del activo. Un puerto abierto puede ser correcto o riesgoso según contexto.

21.4 Escaneo de vulnerabilidades

Un escaneo de vulnerabilidades busca versiones débiles, configuraciones inseguras, parches faltantes o servicios con problemas conocidos.

Aspectos importantes:

• Debe tener alcance definido.
• Debe coordinarse para evitar impacto operativo.
• Los resultados deben validarse antes de remediar en masa.
• La criticidad debe ajustarse por exposición y contexto.
• Los hallazgos deben tener responsable y fecha objetivo.

Un escáner ayuda a descubrir, pero no reemplaza análisis técnico. Puede generar falsos positivos o no detectar configuraciones específicas.

21.5 Pruebas de segmentación

La segmentación debe probarse. No alcanza con tener VLAN o zonas declaradas. Hay que verificar que el tráfico no autorizado realmente se bloquea.

Ejemplos de pruebas:

• Desde red de invitados hacia servidores internos: debe bloquearse.
• Desde usuarios hacia base de datos: debe bloquearse salvo excepción justificada.
• Desde DMZ hacia red interna: solo flujos específicos deben permitirse.
• Desde red administrativa hacia servidores: solo protocolos autorizados.
• Desde servidores hacia internet: solo destinos necesarios.

21.6 Pruebas de reglas de firewall

Las reglas deben validarse desde el origen correcto y hacia el destino correcto. Probar desde otro punto puede dar una falsa lectura.

21.7 Validación de IDS/IPS

Un IDS/IPS también debe validarse. Es necesario confirmar que recibe tráfico, que genera alertas, que las firmas relevantes están activas y que el bloqueo funciona cuando se usa modo IPS.

Pruebas útiles:

• Confirmar que el sensor ve tráfico del segmento esperado.
• Generar una alerta de prueba controlada.
• Verificar que la alerta llega al SIEM.
• Confirmar severidad, origen, destino y firma.
• Probar bloqueo en un entorno controlado antes de producción.
• Revisar que no haya exceso de falsos positivos.

21.8 Validación de hardening

Validar hardening significa comprobar que el sistema cumple una configuración esperada.

Controles a revisar:

• Servicios activos.
• Puertos abiertos.
• Usuarios y grupos.
• Permisos de archivos críticos.
• Parches instalados.
• Políticas de contraseña y bloqueo.
• Firewall local.
• Logs y auditoría.
• Agentes de seguridad activos.

21.9 Auditoría de configuración

Una auditoría de configuración compara el estado real con una política, estándar o baseline. Puede ser manual, automatizada o mixta.

Ejemplos:

• Revisar reglas de firewall contra política aprobada.
• Comparar servidores contra baseline de hardening.
• Verificar que cuentas administrativas tengan MFA.
• Revisar almacenamiento cloud público.
• Auditar permisos excesivos.
• Comprobar que logs se envían a plataforma central.

21.10 Benchmarks CIS

Los benchmarks CIS son guías de configuración segura para sistemas, aplicaciones, servicios cloud y plataformas. Proponen controles concretos y verificables.

Ventajas:

• Dan una base reconocida para hardening.
• Ayudan a estandarizar revisiones.
• Permiten medir cumplimiento.
• Facilitan auditorías y documentación.

Limitación importante: no todas las recomendaciones aplican igual a todos los entornos. Algunas requieren adaptación y pruebas.

21.11 Cumplimiento vs. seguridad real

Cumplir un benchmark no garantiza seguridad total. Es una base útil, pero debe complementarse con análisis de riesgo, arquitectura, monitoreo y respuesta.

21.12 Evidencias

Una validación debe generar evidencias. La evidencia permite demostrar estado, justificar decisiones y dar seguimiento.

Ejemplos de evidencia:

• Captura de configuración.
• Reporte de escaneo.
• Log de firewall permitiendo o bloqueando una prueba.
• Alerta recibida en SIEM.
• Resultado de auditoría contra baseline.
• Ticket de remediación.
• Fecha, responsable y alcance de la prueba.

21.13 Gestión de hallazgos

Un hallazgo es una brecha, debilidad o desviación detectada durante la validación. Debe gestionarse hasta su cierre o aceptación formal.

Un hallazgo debería incluir:

• Descripción clara.
• Activo afectado.
• Evidencia.
• Riesgo e impacto.
• Prioridad.
• Responsable.
• Fecha objetivo.
• Estado de remediación.

21.14 Priorización de remediación

No todos los hallazgos se corrigen con la misma urgencia. La priorización debe considerar riesgo real, no solo la severidad del escáner.

21.15 Revalidación

Después de corregir un hallazgo, hay que revalidar. Cerrar un ticket sin comprobar puede dejar el problema activo.

La revalidación debe confirmar:

• Que el cambio fue aplicado.
• Que el hallazgo ya no se reproduce.
• Que no se generó una nueva exposición.
• Que el servicio sigue funcionando.
• Que logs y alertas siguen operativos.

21.16 Frecuencia de validación

La validación debe repetirse porque el entorno cambia. Nuevas reglas, parches, despliegues, usuarios y servicios pueden introducir desviaciones.

Momentos recomendados:

• Después de cambios importantes.
• Después de publicar servicios.
• Después de incidentes.
• De forma periódica según criticidad.
• Antes de auditorías externas.
• Después de aplicar hardening o parches.

21.17 Ejemplo práctico: validar una DMZ

Para validar una DMZ, se pueden realizar pruebas como:

1. Escanear desde internet los servicios publicados.
2. Confirmar que solo están abiertos puertos esperados.
3. Probar que la DMZ no accede libremente a la red interna.
4. Verificar logs de conexiones permitidas y bloqueadas.
5. Confirmar que el IDS/IPS observa tráfico relevante.
6. Revisar hardening de servidores publicados.
7. Documentar hallazgos y remediaciones.

21.18 Errores frecuentes

• Escanear sin autorización: puede generar impactos o conflictos operativos.
• Confiar solo en reportes automáticos: los hallazgos requieren análisis.
• No revalidar: una corrección no comprobada puede no haber funcionado.
• No guardar evidencia: dificulta auditoría y seguimiento.
• No priorizar por contexto: se corrige lo fácil en lugar de lo más riesgoso.
• Probar desde ubicaciones incorrectas: puede dar resultados engañosos.
• Ignorar logs y alertas durante pruebas: se pierde oportunidad de validar monitoreo.

21.19 Lista de verificación inicial

• Definir alcance y autorización de pruebas.
• Escanear puertos y servicios expuestos.
• Validar reglas de firewall con pruebas positivas y negativas.
• Comprobar segmentación entre zonas.
• Validar que IDS/IPS reciba tráfico y genere alertas.
• Comparar sistemas contra baseline o benchmark CIS.
• Guardar evidencias de configuración, logs y resultados.
• Crear hallazgos con responsable y fecha objetivo.
• Priorizar por riesgo real.
• Revalidar después de remediar.

21.20 Ideas clave para recordar

• La validación demuestra si los controles funcionan realmente.
• Escaneo, auditoría y pruebas funcionales se complementan.
• Los benchmarks CIS son una base útil, pero deben adaptarse al contexto.
• La evidencia es necesaria para auditoría, seguimiento y aprendizaje.
• Los hallazgos deben priorizarse por riesgo y cerrarse con revalidación.
• Validar debe ser un proceso continuo, no una actividad única.

21.21 Conclusión

La validación defensiva cierra el ciclo entre diseño, implementación y operación. Permite comprobar que firewalls, IDS/IPS y hardening no solo existen, sino que cumplen su función con evidencia verificable.

En el próximo tema estudiaremos respuesta ante incidentes: contención, bloqueo, erradicación, recuperación y aprendizaje.