La infraestructura crítica chilena—energía, agua, telecomunicaciones, transporte, salud—depende de sistemas de control industrial (ICS/OT) que fueron diseñados décadas atrás, típicamente sin considerar seguridad cibernética moderna. La Ley Marco de Ciberseguridad (Ley 21.663) que entró en vigencia en marzo 2025 transformó estas prácticas heredadas en requisitos legales obligatorios.
Diferentemente de TI tradicional (donde la confidencialidad de datos es prioritaria), OT/ICS prioriza disponibilidad y seguridad física. Una brecha en un servidor web = pérdida de datos. Una brecha en un control SCADA = apagón, contaminación de agua, accidente laboral o muerte.
Este documento proporciona guía práctica para implementar seguridad OT/ICS en contexto chileno, considerando:
- Sistemas legacy que no pueden pausarse
- Regulación nacional (ANCI, Ley 21.663, Ley 21.719)
- Realidad operacional de empresas críticas
1. OT vs IT: Diferencias Fundamentales que Cambian Todo
1.1 Prioridades de Seguridad: El Cambio Paradigmático
| Aspecto | IT (Tradicional) | OT/ICS (Industrial) |
|---|---|---|
| Prioridad 1 | Confidencialidad | Disponibilidad |
| Prioridad 2 | Integridad | Integridad |
| Prioridad 3 | Disponibilidad | Confidencialidad |
| Tolerancia a Downtime | Horas aceptables | Cero minutos |
| Impacto de Brecha | Pérdida de datos | Daño físico, muerte |
| Ciclo de Patching | Semanal/mensual | Años o nunca |
| Modernización | 3-5 años | 10-20+ años |
Implicación Práctica: Aplicar políticas IT estándar (reinicios obligatorios para patches, MFA con SMS que requiere internet) rompe sistemas OT. Una bomba de agua que se reinicia mata gente en pleno verano en Santiago. Un control SCADA que pierde conexión durante cambio de credenciales detiene producción durante horas.
1.2 Diferencias Técnicas
Sistemas IT:
- Variedad de SO (Windows, Mac, Linux)
- Actualizaciones frecuentes
- Conectividad de diseño: internet normal
- Protocolos estándar (HTTP, TCP/IP)
- Ciclo de vida: 3-5 años
Sistemas OT/ICS:
- SO propietario o embebido (RTOS, sistema operativo de tiempo real)
- Actualizaciones raras (requieren pausa operacional)
- Históricamente: air-gapped (sin internet)
- Protocolos industriales especializados (Modbus, DNP3, OPC, Profibus)
- Ciclo de vida: 10-20+ años (algunos aún más antiguos)
1.3 Vectores de Ataque: Crecimiento Reciente
En 2024, 58% de los incidentes OT fueron iniciados desde compromisos IT, porque IT y OT ahora están conectados. La Ley 21.663 reconoce esto explícitamente: empresas que operan servicios esenciales deben reportar incidentes en 24-72 horas.
Casos reales (últimos 4 años):
- 2015 – Ukraine Power Grid: Malware BlackEnergy accedió a SCADA, causó apagón de 230,000 personas por 6 horas en invierno
- 2017 – Saudi Aramco Refinery: Triton/Trisis malware intentó desactivar sistemas de seguridad en facilidad petroquímica
- 2021 – Colonial Pipeline (EE.UU.): Ransomware paralizó pipeline de combustible
- 2024 – Iran Steel Mill: Atacantes Predatory Sparrow provocaron incendio masivo en fundición (ataque físico desde cyber)
2. Marco Regulatorio Chileno para OT/ICS
2.1 Ley 21.663 (Ley Marco de Ciberseguridad)
Entered full force March 2025. Creates Agencia Nacional de Ciberseguridad (ANCI) with enforcement power.
Empresas Afectadas:
Prestadores de Servicios Esenciales (PSE):
- Energía (generación, transmisión, distribución)
- Agua y saneamiento
- Telecomunicaciones
- Transporte (aéreo, terrestre, marítimo, ferroviario)
- Salud (hospitales, clínicas)
- Farmacéutica
Operadores de Vital Importancia (OVI):
- Subconjunto designado por ANCI
- ~1,700 empresas en lista preliminar (Sept 2025)
- Requisitos más estrictos
- Multas: hasta $690,000 USD
Requisitos Obligatorios para PSE/OVI:
- Reportar incidentes en 24-72 horas a ANCI (vs 30 días en otros países)
- Designar oficial de seguridad responsable
- Implementar medidas técnicas y organizacionales alineadas con NIST SP 800-207 (Zero Trust), ISO 27001, IEC 62443
- Segmentación de red (Nivel 3.5 DMZ es obligatorio)
- Trazabilidad completa de acceso a sistemas críticos
- Testing trimestral de capacidad de respuesta
2.2 Ley 21.719 (Protección de Datos Personales)
Aprobada agosto 2024, alineada con GDPR/LGPD. Requiere:
- Cifrado de datos personales en OT/ICS
- DPIA para procesamiento alto riesgo
- Notificación de brecha en 30 días
- Auditoría completa de acceso a datos
2.3 IEC 62443: Estándar Industrial de Referencia
Aunque no es ley chilena, ANCI reconoce IEC 62443 como framework técnico de referencia. Define:
| Nivel | Descripción | Inversión |
|---|---|---|
| 1 | Actividades defensivas básicas | Bajo |
| 2 | Mejoras a través de gestión proactiva | Medio |
| 3 | Proceso estructurado para detección/respuesta | Alto |
| 4 | Defensa dinámica y adapativa | Muy Alto |
Mayoría de industrias chilenas actualmente está en Nivel 1-2. Ley 21.663 requiere mínimo Nivel 2, con meta de Nivel 3.
3. La Realidad de Sistemas Legacy en Chile
3.1 Estadísticas Globales (Aplicables a Chile)
- 80% de plantas industriales aún ejecutan sistemas legacy
- 50% de compañías tienen >50% de su OT en sistemas >10 años
- 20% tienen >75% legacy
- 0 vendors para 40% de sistemas (end-of-life, soporte descontinuado)
3.2 El Dilema Air-Gap → Always-Connected
Tradicional (Previo a 2015):
SCADA systems = Isolated
↓
Air-gapped = Sin internet
↓
Seguridad = Física (guardias, cerraduras)
↓
Muy seguro vs cyber, pero:
- Sin remote monitoring
- Mantenimiento lento
- Sin data para decisiones
Moderno (2020+):
Industry 4.0 Requirement = Conectado
↓
Remote monitoring + Cloud analytics
↓
Conectado a redes corporativas
↓
Conectado a internet (directa o indirectamente)
↓
Exposición exponencial
↓
Sistemas legacy sin defensas cibernéticas
Implicación: Las empresas chilenas con OT no pueden volver a air-gap puro (negocio lo requiere). Deben implementar seguridad moderna sin romper operaciones. Esto es el desafío central.
3.3 Riesgos de Modernización Rápida
Error común: Rip-and-replace (reemplazar todo rápido)
Resultado: Downtime durante implementación
↓
Ventana de vulnerabilidad (mientras se cambia)
↓
Posible introducción de malware
↓
Peor que no modernizar
Correcto: Modernización faseada, layer-by-layer, validada en paralelo
4. Arquitectura OT Segura: Modelo Purdue Aplicado
4.1 ¿Qué es el Modelo Purdue?
Framework estándar para segmentar OT en capas, cada una con diferentes requisitos de seguridad. Desarrollado por Purdue University en 1990s, actualizado para era moderna.
Niveles:
NIVEL 5: Enterprise Network
├─ Email, web, datos corporativos
├─ Conectado a internet normal
└─ Standard IT security (antivirus, firewall, EDR)
NIVEL 4: Business Planning & Logistics
├─ ERP, CRM, sistemas de reporte
├─ Conectado a Nivel 3 a través de DMZ
└─ Firewall stateful entre 4-3
>> LEVEL 3.5: DEMILITARIZED ZONE (DMZ) <<
├─ Buffer zone crítica entre IT y OT
├─ Data historians, proxy servers, jump hosts
├─ ICS-aware firewalls (entienden Modbus, DNP3)
└─ Unidirectional data flow (solo salida desde OT a IT)
NIVEL 3: Supervisory Control & Monitoring
├─ SCADA, HMI (Human-Machine Interface)
├─ Sistemas de visualización y control
├─ Acceso restringido desde Nivel 4
└─ No acceso directo a internet
NIVEL 2: Real-Time Control (DCS)
├─ Distributed Control Systems
├─ Control loops de tiempo real
├─ Latencia crítica (<100ms típicamente)
└─ Muy sensitivo a cambios
NIVEL 1: Intelligent Devices
├─ PLCs (Programmable Logic Controllers)
├─ RTUs (Remote Terminal Units)
├─ Smart sensors
└─ Protocolos industriales (Modbus, DNP3)
NIVEL 0: Physical Process
├─ Bombas, válvulas, motores
├─ Equipamiento físico
└─ Monitoreado por Level 1
4.2 Implementación Práctica en Chile
Ejemplo: Planta de Tratamiento de Agua (SISS Regulado)
Estado Actual (Sin segmentación):
Internet
↓
Corporate Network (RH, finanzas)
↓
SCADA Server (directamente en red corporativa)
↓
PLCs en planta
↓
Bombas de agua a Santiago
PROBLEMA: Malware en email corporativo → SCADA → apagón de agua
Estado Seguro (Modelo Purdue Implementado):
Internet
↓
Corporate Network (RH, finanzas)
↓
FIREWALL PRINCIPAL
↓
NIVEL 3.5: DMZ (Buffer Zone)
├─ Data historian (recopila datos de SCADA)
├─ Proxy server (restringe acceso)
├─ IDS/IPS (monitorea tráfico anómalo)
└─ Firewall stateful (reglas específicas OT)
↓
FIREWALL SECUNDARIO (ICS-aware)
↓
NIVEL 3: Supervisory Control
├─ SCADA server (acceso solo desde DMZ)
├─ HMI (only local or from bastion host)
└─ Network segmentation (VLAN específica)
↓
FIREWALL NIVEL 2-1
↓
NIVEL 2-1: Real-Time Control
├─ PLCs (acceso solo de SCADA server)
├─ RTUs (comunicación punto-a-punto)
└─ Network monitoring (detección anomalía)
↓
Bombas de agua
BENEFICIO: Si malware en corporativo → Bloqueado en DMZ → Sin acceso a SCADA
4.3 Reglas de Firewall OT (Ejemplo Práctico)
Configuración de Level 3.5 DMZ Firewall (pseudocódigo):
INBOUND (desde IT corporativo hacia OT):
ALLOW HTTP/HTTPS to Data Historian (puerto 80, 443)
- Source: 10.0.4.0/24 (Business Planning Level 4)
- Destination: 10.0.3.1 (DMZ Data Historian)
- Estado: Stateful (solo responses permitidas)
ALLOW SSH to Bastion Host (puerto 22)
- Source: 10.0.4.100 (Jump server IT)
- Destination: 10.0.3.10 (DMZ Bastion)
- MFA requerida (validado antes de firewall)
DENY todo lo demás (default deny)
OUTBOUND (desde OT hacia IT):
ALLOW HTTPS to Data Warehouse (puerto 443)
- Source: 10.0.3.1 (Data Historian)
- Destination: 10.0.4.50 (Enterprise Data Warehouse)
- Protocolo: HTTPS solo, no HTTP
- Frecuencia: 1x por hora (no en tiempo real)
DENY todo lo demás
INBOUND (desde Nivel 3 SCADA a DMZ):
ALLOW Modbus TCP (puerto 502)
- Source: 10.0.2.0/24 (SCADA Level 3)
- Destination: 10.0.3.1 (Data Historian)
- Validación: Checksum validation, no data modification
ALLOW SNMP (puerto 161)
- Source: 10.0.2.0/24 (SCADA monitoring)
- Para: Network monitoring solo
5. Pilares de Seguridad OT/ICS
5.1 PILAR 1: Visibilidad y Asset Discovery
Desafío Único OT: No sabes qué tienes. Muchas plantas tienen equipos olvidados de hace 20 años.
Solución: Descubrimiento Pasivo
A diferencia de IT (donde escaneo activo es normal), OT requiere passive discovery para no romper equipos legacy:
Método 1: Passive Network Monitoring
├─ Capturar tráfico de red sin enviar packets
├─ Análisis de protocolos industriales (Modbus, DNP3)
├─ Fingerprinting de dispositivos sin activo scanning
└─ Herramientas: Nessus Network Monitor, Claroty CTD, CytoMX
Método 2: Protocol-Aware Discovery
├─ Escuchar protocolos específicos OT
├─ Documentar comandos SCADA observados
├─ Identificar anomalías (comandos no esperados)
└─ Herramientas: Cisco Cyber Vision, Fortinet ICS Discovery
Método 3: Hybrid Approach (Moderno)
├─ Passive baseline building (3 meses de observación)
├─ Controlled active scanning SOLO en horas bajas
├─ RFC-compliant traffic únicamente
├─ Throttled scanning (<100 packets/seg por dispositivo)
└─ Herramientas: runZero (OT-safe active scanning)
Salida esperada (Asset Inventory):
Device ID: PLC-WTP-001
├─ Location: Planta Tratamiento Ñuble, Sector Bombeo
├─ Type: Programmable Logic Controller (Siemens S7-300)
├─ OS: Proprietary RTOS (no Windows/Linux)
├─ Firmware: Ver 5.2.1 (End-of-Life desde 2015, sin patches disponibles)
├─ IP Address: 10.0.1.45
├─ MAC Address: 00:0a:95:42:c4:01
├─ Functions: Controla 6 bombas de agua, capacidad 5,000 L/min
├─ Criticality: CRITICAL (sin redundancia)
├─ Protocols: Modbus TCP/IP (puerto 502), Ethernet
├─ Vendors with Access: Siemens (para mantenimiento), Agua Corp interno
├─ Patch Status: 0 patches aplicables (sistema legacy)
├─ Redundancy: NINGUNA (single point of failure)
├─ Last Modified: 2023-11-15 (firmware update, causó 4 horas downtime)
└─ Risk Assessment: High (legacy + no redundancy + critical function)
5.2 PILAR 2: Network Segmentation & Micro-segmentation
Principio: Reduce blast radius mediante isolation.
Implementación en Niveles:
Macro-Segmentation (Purdue Model – Firewall Level):
Firewall entre Level 3.5 (DMZ) y Level 3 (SCADA)
├─ Hardware: ICS-aware firewalls (Fortinet FortiGate ICS, Palo Alto ICS)
├─ Función: Bloquear ALL traffic except explicitly whitelisted
├─ Protocols Entendidos: Modbus, DNP3, OPC UA, Profibus
└─ Monitoreo: Tráfico anómalo logeado para SIEM
Micro-Segmentation (VLAN/Virtual Network – Switch Level):
Mismo Level 3, pero isolate grupos de PLCs por función
Existing (plano):
├─ All PLCs en 10.0.1.0/24
├─ Cualquier PLC puede hablar con cualquier otro
└─ Malware en PLC-001 → Spread a todos
Micro-segmented:
├─ VLAN 100: PLCs de Sector Bombeo (10.0.1.0/26)
├─ VLAN 101: PLCs de Sector Tratamiento (10.0.1.64/26)
├─ VLAN 102: PLCs de Sector Distribución (10.0.1.128/26)
├─ VACLs (VLAN ACLs) entre VLANs: Muy restrictivo
└─ Malware en PLC-001 (Bombeo) → Bloqueado en VLAN boundary
5.3 PILAR 3: Access Control & Authentication
Desafío OT: Muchos sistemas heredados no soportan MFA, cuentas de administrador compartidas, sin logging.
Solución Faseada:
Fase 1 (Inmediata): Cuentas de Servicio Segregadas
ANTES:
├─ Todos usan "admin" con password "12345"
├─ O comparten cuentas entre 5 personas
└─ Sin saber quién hizo qué cambio
DESPUÉS:
├─ Usuario: dba_scada_sqlserver_prod
├─ Contraseña: 40+ caracteres, rotada cada 90 días
├─ MFA: Si el sistema lo soporta (SCADA Server soporta, PLCs no)
├─ Auditoría: CADA login registrado (IP, hora, duración)
└─ Least Privilege: Solo permisos necesarios para rol
Fase 2 (3-6 meses): MFA donde sea viable
Dispositivos que PUEDEN tener MFA:
├─ SCADA servers (Windows/Linux)
├─ HMI systems (web-based)
├─ ICS data historians
└─ Jump servers/bastion hosts
Dispositivos que NO pueden:
├─ PLCs legacy (sin soporte criptográfico)
├─ RTUs viejos
├─ Alguns sensores
└─ Equipamiento >15 años
SOLUCIÓN: MFA en "entry point" (bastion) permite acceso a devices legacy
├─ Usuario solicita acceso a PLC-001
├─ Bastion Host valida MFA
├─ Si OK: Sesión establecida
├─ PLC-001 no necesita saber de MFA
Fase 3 (6-12 meses): Just-In-Time (JIT) Privileged Access
PARA: Acceso administrativo a cualquier control system
Flujo:
1. Ingeniero necesita cambiar parámetro en PLC
2. Request en portal: "Acceso a PLC-WTP-001, 2 horas, para cambio de setpoint"
3. Sistema valida:
- ¿Usuario autorizado? Sí
- ¿Cambio documentado? Sí (ticket #12345)
- ¿Supervisor aprueba? Sí
- ¿Es horario permitido? Sí (no en producción pico)
4. JIT session creada: 2 horas exactas
5. Acceso revocado automáticamente después
6. TODA sesión grabada (video + comandos)
7. Logs archivados por 7 años (auditaría ANCI)
5.4 PILAR 4: Vulnerability Management (Pasivo, Sin Disruption)
Pasivo scanning (la única opción viable en OT):
Herramientas:
├─ Tenable Nessus Network Monitor (passive)
├─ Claroty Team82 (passive protocol analysis)
├─ Fortinet ICS vulnerability assessment
├─ Shodan (para descubrir exposiciones en internet)
└─ Censys ICS/OT Intelligence
Proceso:
1. Capturar tráfico red OT (mirror port / SPAN port)
2. Análisis offline (no afecta dispositivos)
3. Identificar:
- Dispositivos corriendo software conocido vulnerable
- Puertos innecesarios abiertos
- Protocolos débiles (sin encriptación)
- Firmware viejos (sin patches)
4. Priorizar por:
- CVSS score
- Criticality del dispositivo
- Exploitabilidad actual (threat intelligence)
- Impacto operacional de parchar
Ejemplo: Vulnerability Encontrada
CVE-2024-XXXXX: Siemens S7 PLC Buffer Overflow
├─ Criticidad: HIGH (CVSS 8.1)
├─ Afectado: PLC-WTP-001 (nuestra planta)
├─ Impacto: Atacante remoto puede crashear PLC
├─ Fix: Firmware update v5.2.5
├─ Problema: Firmware requiere 30 min downtime + 2h validación
DECISIÓN:
├─ Riesgo de downtime: Alto (bomba de agua down)
├─ Riesgo de explotación: Bajo (PLC en red aislada, sin acceso internet)
├─ DECISIÓN: Parchear en mantenimiento programado (próximo mes), no urgente
└─ Mitigación temporal: Monitoreo intensivo en SIEM
ALTERNATIVA (si riesgo alto):
├─ Compensating control: Aislamiento de red más estricto
├─ O: Redundancia rápida (segunda PLC idéntica como backup)
└─ Luego: Parchear durante downtime planeado
5.5 PILAR 5: Monitoring & Detection (SIEM/SOC para OT)
Desafío: SIEM tradicional genera 1000s de false positives en OT → SOC quema los sueños.
Solución: OT-Aware SIEM
Herramientas recomendadas:
├─ Microsoft Sentinel + OT plugins
├─ Splunk con OT add-ons
├─ Datadog Security para OT
├─ Dedicated: TXOne, Fortinet FortiSOC OT, Claroty
└─ Open source: ELK Stack + custom rules OT
Fuentes de logs a conectar:
├─ ICS-aware firewall (reporte tráfico Modbus anómalo)
├─ Network TAP/SPAN (captura tráfico OT)
├─ SCADA server logs (cambios de configuration)
├─ PLC event logs (si capacidad)
├─ Bastion host logs (acceso administrativo)
└─ EDR en sistemas IT que acceden OT (lateral movement detection)
Reglas de detección críticas:
1. "Unexpected Modbus Write"
├─ Trigger: Comando Modbus WRITE desde dispositivo no esperado
├─ Norma: Solo SCADA server escribe a PLCs
├─ Si otro: ALERTAR (malware intentando manipular)
└─ Acción: Bloquear en firewall, notificar OT lead
2. "PLC Parameter Change Outside Change Window"
├─ Trigger: Setpoint de bomba cambiado a las 02:00 (fuera horario laboral)
├─ Baseline: Cambios permitidos 08:00-17:00 lunes-viernes
├─ Si fuera: ALERTAR (posible sabotaje)
└─ Acción: Verificar manualmente, posible rollback
3. "New Device on OT Network"
├─ Trigger: Dirección IP nueva en red Level 2-1
├─ Baseline: Asset inventory conocido
├─ Si nueva: ALERTAR (rogue device?)
└─ Acción: Investigar, cuarentena si desconocida
4. "Multiple Failed Authentication Attempts"
├─ Trigger: >5 failed logins en 10 min a SCADA server
├─ Baseline: Errores típicos = 1-2 (contraseña olvidada)
├─ Si múltiple: ALERTAR (brute force?)
└─ Acción: Lock account temporalmente, MFA re-validación
5.6 PILAR 6: Incident Response (OT-Specific)
Diferencia Crítica vs IT: En IT, puedes “turn it off and turn it back on”. En OT, eso mata gente.
Fases de IR Específicas OT:
1. PREPARATION
└─ Pre-established playbooks, trained team, 24/7 contact list
2. IDENTIFICATION & ALERTING
└─ SIEM detecta anomalía, paging alertas a OT incident commander
3. SAFETY FIRST ASSESSMENT
├─ ¿Hay riesgo inmediato a personas? (e.g., control de seguridad comprometido)
├─ Si SÍ: PARAR OPERACIONES, evacuate, manual shutdown
├─ Si NO: Continuar a siguiente fase
└─ *This differentiates OT from IT IR*
4. CONTAINMENT
├─ Objetivo: Aislar sistema comprometido SIN romper operaciones
├─ Técnicas:
│ ├─ Cambiar firewall rules (rechazar tráfico malicioso)
│ ├─ Cambiar routing (redirigir tráfico limpio)
│ ├─ Isolate red(split brain network)
│ └─ Last resort: Cortar power (solo si safety risk)
└─ Timing: Target <30 minutos
5. INVESTIGATION & ERADICATION
├─ Forense: ¿Qué sucedió? ¿Cuándo comenzó?
├─ Remediation: Parchear vulnerabilidad, cambiar credenciales
├─ Validation: Confirmar malware eliminado
└─ Timing: 2-24 horas (depende complejidad)
6. RECOVERY
├─ Restaurar operaciones gradualmente
├─ Validar: Bombas operan correctamente, presión normal, etc.
├─ Monitoreo intensivo: SIEM con alertas amplificadas
└─ Timing: 1-48 horas
7. LESSONS LEARNED
├─ Post-mortem: ¿Qué funcionó en IR? ¿Qué falló?
├─ Updater: Incident response plan, firewall rules, baselines
├─ Training: Debrief de equipo
└─ Timing: Dentro de 1 semana post-incident
Ejemplo de Plan: Ransomware en SCADA Server
Scenario: Ransomware detectado en servidor SCADA (Level 3)
Timeline:
T+00min: SIEM alerta "Unusual Modbus traffic from SCADA server"
T+02min: SOC valida alerta, página incident commander
T+05min: INC commander declara "SEV2 Incident: SCADA Server"
T+10min: Assessment de safety: ¿Control systems aún operacionales? Sí
Containment:
T+15min: Firewall rule: Negar tráfico desde SCADA server a PLCs
T+15min: PLCs continúan bajo "manual mode" (operadores locales)
T+15min: Lateral movement bloqueado (SCADA server aislado)
T+20min: Backup de SCADA server iniciado
T+30min: IT equipo restaura SCADA desde backup (T-30 min antes infección)
Result:
├─ Operations: 20 minutos de degraded service (manual operation)
├─ Ransom: NO pagado (backup disponible)
├─ Data: NO perdido (backup completo)
├─ Report: ANCI notificado en 2 horas (cumple requisito 24-72h)
└─ Lessons: "Test restore backups monthly"
6. Presupuesto y Timeline Realista
6.1 Empresa Mediana (500 empleados, 1 planta OT)
| Componente | Año 1 | Año 2 | Total 18m |
|---|---|---|---|
| Network segmentation/DMZ | $80K | – | $80K |
| Firewall OT-aware | $50K | – | $50K |
| Passive scanning tools | $30K | $15K | $45K |
| SIEM/SOC OT | $60K | $40K | $100K |
| Personnel (2 FTE) | $120K | $120K | $180K |
| Training | $20K | $10K | $30K |
| Incident response / DR | $40K | – | $40K |
| TOTAL | $400K | $185K | $525K |
6.2 Timeline 24 Meses
MONTHS 1-3: Discovery & Assessment
├─ Inventario asset completo
├─ Risk assessment
├─ Regulatory compliance baseline
└─ Budget & sponsor approval
MONTHS 4-6: Foundation
├─ Deploy Purdue Model DMZ (Nivel 3.5)
├─ Configure ICS-aware firewall
├─ Setup passive scanning
└─ Establish baselines
MONTHS 7-12: Monitoring & Response
├─ Deploy SIEM con OT plugins
├─ Create incident response playbooks
├─ Training de equipo
└─ First tabletop exercise
MONTHS 13-18: Optimization
├─ Tune SIEM (reducir false positives)
├─ Implement MFA donde viable
├─ Test disaster recovery
└─ Annual tabletop exercise
MONTHS 19-24: Continuous Improvement
├─ Vulnerability management program
├─ Patch management (faseado)
├─ Redundancy where critical
└─ Compliance audits (ANCI)
7. Checklist de Implementación
Immediate (Próximas 4 semanas)
- Designar OT Security Officer (responsable ejecutivo)
- Inventario de PLCs/SCADA/RTUs críticos (¿cuántos? ¿dónde?)
- Documentar arquitectura de red actual
- Identificar air-gapped vs connected systems
- Revisar incidentes de seguridad previos (¿ha habido?)
- Mapear protocoles industriales en uso (Modbus, DNP3, etc.)
Short-term (3-6 meses)
- Implementar Purdue Model DMZ (Level 3.5)
- Deploy ICS-aware firewall
- Iniciar passive discovery
- Documentar Incident Response Plan
- Capacitación básica equipo OT en seguridad
Medium-term (6-12 meses)
- Deploy SIEM con OT plugins
- Crear alertas para anomalías
- Test incident response playbooks
- Implementar access logging/auditing
- Review compliance con Ley 21.663
Long-term (12-24 meses)
- MFA en sistemas que lo soportan
- Backup/recovery testing
- Redundancia en sistemas críticos
- Tabletop exercises trimestrales
- Preparación para auditoría ANCI
OT/ICS security en Chile es ahora requisito legal, no opcional. Ley 21.663 y ANCI representan cambio paradigmático. Las compañías que ignoren esto enfrentarán:
- Multas $345K-$690K USD
- Publicidad negativa en caso de incident
- Potencial parada operacional por orden regulatoria
- Liability si incident causa daño físico
Buena noticia: No es necesario ser perfecto. Ley 21.663 reconoce que legacy systems existen. Solo requiere “reasonable measures” proporcionales al riesgo.
Malo: Procrastinación. ANCI ya está operando (enero 2025). Comienza auditorías ahora.
Recomendación: Comenzar con Purdue Model DMZ (3-4 meses) como foundation. Luego SIEM (6 meses). Luego optimización continua. Es marathon, no sprint.
Recursos Adicionales
Estándares:
- NIST SP 800-82r3 (Guide to Operational Technology Security)
- IEC 62443 (Industrial Automation and Control Systems Security)
- ISA/IEC 62443 Secure Development Lifecycle
Regulaciones Chile:
- Ley 21.663 Marco Ciberseguridad
- Ley 21.719 Protección Datos Personales
- Resoluciones ANCI (publicadas regularmente)
Implementadores en Chile:
- NLT SECURE (especialista OT)
- NIVEL4 (crítica infraestructura)
- Assertiva (OT consulting)
- Fortinet Chile (herramientas ICS)
Community:
- ICS Cybersecurity Conference (anual)
- SANS ICS Security courses
- Industrial Control Systems Cyber Emergency Response Team (ICS-CERT)