Tema 24

24. Proyecto final: diseño e implementación de una estrategia defensiva completa

El proyecto final integra todo el curso: arquitectura defensiva, firewalls, IDS/IPS, hardening, monitoreo, validación, respuesta a incidentes y operación continua.

Objetivo Diseñar una defensa completa y justificable
Enfoque Arquitectura, controles, validación y operación
Resultado Producir un plan defensivo aplicable a un entorno realista

24.1 Introducción

Durante el curso estudiamos controles por separado: firewalls, reglas, NAT, segmentación, IDS/IPS, SIEM, hardening, validación, respuesta y operación continua. En la práctica, estos controles deben trabajar juntos.

El proyecto final consiste en diseñar una estrategia defensiva completa para una organización ficticia. El objetivo no es elegir herramientas por marca, sino justificar decisiones técnicas: qué proteger, cómo segmentar, qué permitir, qué monitorear, cómo validar y cómo mantener.

Este tema funciona como guía de trabajo. Puede usarse como ejercicio individual, evaluación de curso o base para un proyecto real adaptado.

24.2 Escenario del proyecto

La organización ficticia tiene los siguientes elementos:

  • Usuarios internos en una oficina principal.
  • Red Wi-Fi corporativa y red Wi-Fi de invitados.
  • Aplicación web pública para clientes.
  • Base de datos interna usada por la aplicación.
  • Servidor de archivos interno.
  • Administradores que gestionan servidores y dispositivos de red.
  • Usuarios remotos mediante VPN.
  • Algunos servicios en nube.
  • Firewalls perimetrales e internos.
  • IDS/IPS, logs centralizados y EDR en endpoints críticos.

El estudiante debe proponer una defensa razonable para este entorno.

24.3 Objetivos defensivos

Antes de diseñar controles, hay que definir objetivos. En este proyecto, la estrategia debe buscar:

  • Reducir superficie de ataque.
  • Controlar tráfico entre zonas.
  • Publicar servicios externos de forma segura.
  • Proteger accesos administrativos.
  • Detectar actividad sospechosa.
  • Endurecer sistemas y servicios críticos.
  • Registrar eventos útiles para investigación.
  • Preparar validación, respuesta y operación continua.

24.4 Entregables esperados

El proyecto final debe producir entregables claros. No basta con una descripción general.

Entregable Contenido mínimo
Diagrama lógico Zonas, flujos principales, firewalls, DMZ, nube, VPN y sensores.
Tabla de zonas Nombre, propósito, activos y nivel de confianza.
Matriz de reglas Origen, destino, servicio, acción, logging y justificación.
Plan IDS/IPS Ubicación de sensores, modo de operación y alertas prioritarias.
Plan de hardening Sistemas, servicios, red, nube y contenedores si aplican.
Plan de monitoreo Logs, métricas, alertas, SIEM y retención.
Plan de validación Pruebas, escaneos, benchmarks y evidencias.
Plan operativo Mantenimiento, documentación, indicadores y revisión periódica.

24.5 Fase 1: inventario y clasificación

El primer paso es identificar activos, servicios y niveles de criticidad.

El inventario debe incluir:

  • Servidores y sistemas.
  • Aplicaciones y bases de datos.
  • Dispositivos de red.
  • Servicios expuestos.
  • Usuarios y roles administrativos.
  • Dependencias entre sistemas.
  • Datos sensibles.
  • Servicios cloud o externos.

Clasificar ayuda a priorizar controles. No todos los activos requieren el mismo nivel de protección.

24.6 Fase 2: diseño de zonas

El diseño debe separar zonas por función, confianza y criticidad.

Zonas mínimas recomendadas:

  • Internet.
  • DMZ para servicios publicados.
  • Usuarios internos.
  • Servidores internos.
  • Bases de datos.
  • Administración.
  • Invitados.
  • VPN.
  • Nube o servicios híbridos.
  • Backups.
El diseño debe evitar una red plana. Cada zona debe tener una razón de existir y reglas claras de comunicación.

24.7 Fase 3: matriz de comunicaciones

La matriz de comunicaciones define qué tráfico se permite entre zonas. Debe seguir mínimo acceso.

Origen Destino Servicio Acción Justificación
Internet Reverse proxy en DMZ HTTPS Permitir y registrar Acceso de clientes a la aplicación pública.
DMZ Base de datos interna Puerto específico Permitir y registrar Consulta necesaria de la aplicación.
Invitados Red interna Cualquiera Bloquear Aislamiento de red no confiable.
Administración Servidores SSH/RDP Permitir y registrar Gestión autorizada desde bastión.

24.8 Fase 4: diseño de firewall

El diseño de firewall debe indicar dónde se aplican controles y qué política general se usará.

Debe incluir:

  • Firewall perimetral.
  • Firewall interno o ACL entre zonas.
  • Regla final de bloqueo.
  • Logging en reglas críticas.
  • NAT y publicación de servicios.
  • Objetos y grupos con nombres claros.
  • Procedimiento de cambios.
  • Revisión periódica de reglas.

24.9 Fase 5: publicación segura

La aplicación web pública debe publicarse con exposición controlada.

Diseño recomendado:

  1. Internet accede solo por HTTPS.
  2. El punto de entrada está en DMZ o detrás de WAF/reverse proxy.
  3. La aplicación no expone administración desde internet.
  4. La comunicación hacia base de datos es específica y registrada.
  5. El servidor está endurecido y actualizado.
  6. Los logs web, firewall e IDS/IPS se centralizan.
  7. Los certificados TLS tienen monitoreo de vencimiento.

24.10 Fase 6: IDS/IPS y telemetría

El proyecto debe ubicar sensores donde aporten visibilidad real.

Puntos recomendados:

  • Tráfico hacia DMZ.
  • Tráfico entre DMZ y red interna.
  • Tráfico entre usuarios y servidores.
  • Segmentos de servidores críticos.
  • Endpoints críticos mediante EDR o HIDS.
  • Nube mediante logs, flujos y sensores disponibles.

Debe indicarse qué alertas son críticas y cuáles pueden quedar solo como monitoreo.

24.11 Fase 7: hardening

El plan de hardening debe cubrir sistemas, servicios, red y nube.

Controles mínimos:

  • Parches aplicados por criticidad.
  • Servicios innecesarios deshabilitados.
  • Usuarios y permisos revisados.
  • Administración remota restringida.
  • Firewall local activo en servidores.
  • SSH, RDP y consolas protegidas.
  • Bases de datos no expuestas directamente.
  • Routers, switches y Wi-Fi endurecidos.
  • Nube con MFA, mínimo privilegio y logs de auditoría.

24.12 Fase 8: monitoreo y alertas

El plan debe definir qué eventos se registran y qué alertas se generan.

Fuentes mínimas:

  • Firewalls.
  • IDS/IPS.
  • EDR o sensores de host.
  • Servidores críticos.
  • Aplicación web.
  • Base de datos.
  • VPN.
  • Identidad y autenticación.
  • Nube.

También debe definirse retención, severidad, responsables y canal de escalamiento.

24.13 Fase 9: validación

La defensa propuesta debe probarse. El proyecto debe incluir un plan de validación.

Pruebas recomendadas:

  • Escaneo de puertos externos.
  • Validación de reglas permitidas y bloqueadas.
  • Prueba de segmentación entre invitados, usuarios, servidores y DMZ.
  • Validación de logs en SIEM o plataforma central.
  • Prueba controlada de alerta IDS/IPS.
  • Revisión contra baseline o benchmark.
  • Prueba de restauración de configuración.

24.14 Fase 10: respuesta a incidentes

La estrategia debe incluir cómo responder si algo falla o se detecta un ataque.

Debe contemplar:

  • Playbooks para servidor web explotado, malware en endpoint y cuenta comprometida.
  • Procedimiento de bloqueo temporal en firewall.
  • Aislamiento de endpoint.
  • Preservación de evidencia.
  • Escalamiento técnico y ejecutivo.
  • Recuperación desde respaldos.
  • Revisión post-incidente.

24.15 Fase 11: operación continua

El proyecto debe mostrar cómo se mantendrá la defensa con el tiempo.

Actividades mínimas:

  • Revisión mensual de reglas temporales.
  • Revisión periódica de reglas sin uso.
  • Actualización de firmas IDS/IPS.
  • Revisión de falsos positivos.
  • Validación de respaldos.
  • Revisión de parches críticos.
  • Actualización de documentación.
  • Indicadores de operación defensiva.

24.16 Indicadores del proyecto

El proyecto debe proponer indicadores para medir la operación.

Indicador Qué mide
Reglas vencidas Excepciones temporales que requieren cierre o renovación.
Hallazgos críticos abiertos Riesgos pendientes de remediación.
Falsos positivos frecuentes Necesidad de ajuste de detecciones.
Sistemas sin parches críticos Exposición por vulnerabilidades conocidas.
Cumplimiento de baseline Estado de hardening por activo.
Tiempo de respuesta Velocidad para reconocer, contener y cerrar alertas.

24.17 Criterios de evaluación

Una estrategia defensiva completa debe evaluarse por coherencia, no por cantidad de herramientas.

  • El diseño separa zonas con sentido defensivo.
  • Las reglas respetan mínimo acceso.
  • Los servicios publicados están protegidos y monitoreados.
  • La administración remota está restringida.
  • IDS/IPS están ubicados donde aportan visibilidad.
  • El hardening cubre sistemas, servicios, red y nube.
  • Existe plan de validación con evidencias.
  • Existe plan de respuesta y operación continua.
  • Las decisiones están justificadas por riesgo.

24.18 Errores frecuentes

  • Diseñar una red plana: dificulta contención y favorece movimiento lateral.
  • Permitir reglas amplias: resuelve rápido pero aumenta riesgo.
  • Ubicar sensores sin propósito: genera costo sin visibilidad útil.
  • Olvidar operación continua: la defensa se degrada con el tiempo.
  • No validar: se asume que los controles funcionan sin evidencia.
  • No documentar excepciones: se acumulan riesgos invisibles.
  • Enfocarse solo en herramientas: la estrategia necesita procesos y responsables.

24.19 Lista de verificación final

  • Inventario de activos y servicios completo.
  • Zonas defensivas definidas.
  • Matriz de comunicaciones documentada.
  • Reglas de firewall con logging y justificación.
  • Servicios publicados mediante DMZ, WAF o reverse proxy cuando corresponda.
  • IDS/IPS ubicados en puntos relevantes.
  • Hardening definido para sistemas, servicios, red y nube.
  • Logs centralizados y alertas priorizadas.
  • Plan de validación con evidencias.
  • Plan de respuesta y operación continua.

24.20 Ideas clave para recordar

  • Una estrategia defensiva combina prevención, detección, respuesta y operación.
  • Firewalls, IDS/IPS y hardening se complementan; ninguno reemplaza a los demás.
  • La segmentación y el mínimo acceso reducen movimiento lateral.
  • La validación convierte diseño en evidencia.
  • La documentación y los indicadores permiten sostener la defensa.
  • El proyecto debe justificar decisiones, no solo enumerar herramientas.

24.21 Conclusión del curso

Este curso recorrió los fundamentos y prácticas necesarias para diseñar una defensa basada en firewalls, IDS/IPS y hardening. Aprendimos a controlar tráfico, segmentar, publicar servicios, detectar actividad sospechosa, endurecer sistemas, validar controles y operar la defensa en el tiempo.

El proyecto final integra todo ese recorrido. Una defensa efectiva no depende de una única herramienta, sino de decisiones coherentes, controles bien ubicados, configuraciones revisadas, evidencia, respuesta y mejora continua.

Volver al índice