Proyecto personal en desarrollo activo. Laboratorio doméstico de SOC orientado a entornos OT/ICS, con arquitectura Purdue segmentada (Zonas y Conductos, IEC 62443), detección de amenazas y simulación de PLC/HMI real.
Los entornos industriales requieren una aproximación de seguridad distinta a la de IT tradicional: protocolos propios (Modbus, DNP3), disponibilidad como prioridad sobre confidencialidad, y una superficie de ataque que rara vez se monitoriza con el mismo rigor que la red corporativa. Quería construir un entorno realista de principio a fin —desde la segmentación de red hasta la detección en un SIEM— para entender de forma práctica cómo se defiende (y cómo se ataca) una infraestructura de este tipo.
Arquitectura de 4 zonas con pfSense como router central, con una interfaz directa por zona. El nivel de campo (OT) queda deliberadamente fuera del alcance del firewall corporativo, replicando un patrón común en entornos reales donde la gestión IT no siempre llega al nivel de planta.
| Zona Purdue | Contenido |
|---|---|
| Nivel 4 (Corporativo) | Equipo atacante (Kali Linux) |
| DMZ | Sensor de red (Suricata IDS) |
| Nivel 3 (SCADA/SIEM) | Suricata, ELK Stack, HMI (ScadaBR) |
| Nivel 1/2 (Campo/PLC) | HMI (puente), PLC simulado (OpenPLC) |
El puente entre Nivel 3 y Nivel 1/2 lo gestiona la propia máquina HMI, no el firewall — así se modela que el firewall corporativo no siempre tiene visibilidad del nivel de campo.
| Componente | Tecnología |
|---|---|
| Hipervisor | VirtualBox 7.x |
| Firewall / Segmentación | pfSense (Zonas y Conductos, IEC 62443) |
| IDS | Suricata, con reglas personalizadas para Modbus/DNP3 |
| SIEM | ELK Stack (Elasticsearch, Kibana, Logstash, Filebeat) |
| PLC simulado | OpenPLC Runtime, programa en IEC 61131-3 (Structured Text) |
| HMI | ScadaBR |
| Protocolo de campo | Modbus TCP |
| Fase | Contenido | Estado |
|---|---|---|
| 0-3 | Red, VMs, pfSense, segmentación por zonas | ✅ Completado y verificado con pruebas cruzadas |
| 4 | Suricata IDS con reglas OT personalizadas | ✅ Completado — capturando tráfico real |
| 5-6 | Pipeline ELK completo (Elasticsearch/Kibana/Logstash/Filebeat) | ✅ Completado y verificado |
| 8 | OpenPLC — instalación y programa ST | 🔧 En progreso — depurando un problema de mapeo de variables |
| 9 | Generación de tráfico Modbus continuo | ⏳ Bloqueado por la fase 8 |
| 10 | HMI con fuente de datos Modbus | ⏳ Pendiente |
| 11 | Escenarios de ataque mapeados a MITRE ATT&CK for ICS | ⏳ Pendiente |
| 12 | Dashboards y alertas en Kibana | ⏳ Pendiente |
El PLC simulado ejecuta un proceso realista (nivel de un tanque con válvula de llenado y alarmas de umbral) expuesto vía Modbus TCP. Depurar por qué la variable de proceso no se actualizaba en tiempo de ejecución —pese a que el runtime estaba activo y el servidor Modbus respondía— llevó a descartar varias hipótesis (exposición Modbus, parada del runtime, sintaxis de direccionamiento) antes de encontrar la causa real: una variable de control sin dirección física asignada no persistía su estado entre ciclos de ejecución. Detalle completo en las lecciones aprendidas.
El HMI (ScadaBR) ya está desplegado y leyendo datos reales del PLC a través de un Data Source Modbus TCP configurado.
Este proyecto ha generado un catálogo real de incidentes de infraestructura resueltos —desde bucles de reinicio en Suricata hasta incompatibilidades de compilación en dependencias de OpenPLC—. Documentados en docs/lessons-learned.md.
