IEC 62443-4-2 SL2 en la práctica: checklist para integrador

Resumen ejecutivo

La IEC 62443 pasó en pocos años del papel de norma de nicho a requisito explícito en pliegos públicos brasileños, especificaciones de operadora y contratos de utility. El integrador que arma tableros SCADA, comisiona PLCs y entrega malla Modbus para subestaciones o telecom hoy recibe pedidos directos de Security Level 2 (SL2) que no venían hasta hace dos años. Este whitepaper desmenuza qué significa SL2 de la parte 4-2 en términos prácticos, sin repetir el overview que ya existe en cualquier presentación de fabricante. Los siete Foundational Requirements se explican en voz de integrador, seguidos de un checklist objetivo de veinticinco ítems para aceptación de componente, preguntas concretas para evaluación de proveedores y una evaluación honesta — ítem por ítem — del AEM-60DC8 contra ese mismo checklist, con lo que cubre, lo que está en curso (objetivo de certificación SL2, aún no certificado) y lo que debe cubrirse en el resto de la arquitectura. El texto cierra con el límite real de SL2 y el criterio de decisión para escalar a SL3.

A quién va dirigido este whitepaper — integrador, no auditor

Este texto está escrito para el integrador de sistemas de automatización industrial, tablerista, proyectista SCADA e ingeniero de comisionamiento. El recorte es deliberado. El auditor de ciberseguridad industrial trabaja con la IEC 62443 entera, en particular las partes 3-2 (evaluación de riesgo del sistema) y 4-1 (proceso de desarrollo del fabricante). El integrador trabaja con lo que está dentro del tablero, y el documento de referencia es la parte 4-2 ("Technical security requirements for IACS components").

El integrador rara vez está en posición de exigir cambios en el firmware de un PLC comercial. Está en posición de elegir componentes, configurar el sistema, segmentar redes, definir contraseñas y procedimientos, y entregar evidencia de aceptación. SL2 en ese nivel es una decisión de compra y de configuración más que de desarrollo. El objetivo de este whitepaper es dar al integrador un instrumento práctico para tomar esa decisión sin volverse especialista en norma.

Un supuesto importante: SL2 de la parte 4-2 es un nivel de componente. La IEC 62443-3-3 trata el nivel de sistema, que es un ejercicio diferente. Un sistema SL2 no se construye necesariamente solo con componentes SL2 — puede ser un sistema con componentes más fuertes en zonas críticas y más débiles en zonas aisladas. El integrador debe entender ambas dimensiones, pero en el día a día elige componentes individualmente.

Qué cambia entre SL1, SL2, SL3 y SL4

La IEC 62443 define cuatro Security Levels que describen al adversario contra el cual el componente (o sistema) puede defenderse. Los niveles son acumulativos: SL3 incluye SL2, SL2 incluye SL1.

Nivel	Adversario típico	Medios	Recursos	Habilidades	Motivación
SL1	Accidente, error casual	Bajos	Bajos	Genéricas	Sin motivación maliciosa
SL2	Atacante oportunista	Bajos	Bajos	Genéricas	Baja
SL3	Atacante deliberado IACS	Sofisticados	Moderados	Específicas de IACS	Moderada
SL4	Atacante estatal o avanzado	Sofisticados	Extensos	Específicas de IACS	Alta

Lectura práctica: SL1 protege contra la ingeniera que aprieta el botón equivocado. SL2 protege contra el adolescente con Metasploit y el script de pentest comercial. SL3 protege contra el atacante que estudió IEC 61850 y sabe exactamente qué hacer con un IED comprometido. SL4 protege contra el adversario que monta cadenas de suministro y backdoors coordinados.

La inmensa mayoría de los proyectos industriales brasileños — banco de baterías telecom, supervisión de subestación de distribución, manufactura discreta, utility de tratamiento de agua — tiene un perfil de riesgo que justifica SL2 para componentes de medición y comunicación. SL3 entra en activos cuyo compromiso causa daño físico directo: relés de protección en transmisión de alta tensión, control de turbina en generación, controladores de reactor en proceso nuclear. SL4 es raro fuera de defensa e infraestructura crítica nacional designada explícitamente.

Los siete Foundational Requirements

La IEC 62443-4-2 organiza sus requisitos en siete Foundational Requirements (FR), heredados de la parte 1-1 de la norma. Cada FR agrupa un conjunto de Component Requirements (CR) que aplican de forma diferente a cuatro tipos de componente: Software Application, Embedded Device, Host Device y Network Device. Los párrafos siguientes describen cada FR en voz de integrador.

FR 1 — Identification and Authentication Control (IAC). El componente debe saber quién accede y cómo. En la práctica esto se traduce a usuarios nominales (no "admin/admin" universal), soporte de políticas de contraseña, autenticación de máquina donde aplique y, en SL2, alguna forma de identificación única para servicios y dispositivos. PLC con login compartido de "ingeniero" es falla; PLC con usuarios nominales y log de quién hizo qué es el camino.

FR 2 — Use Control (UC). Después de saber quién es, el componente decide qué puede hacer esa persona. Permisos granulares, roles distintos (operador, mantenimiento, administrador), separación entre configuración y operación. Para CR 2.1, el componente debe imponer control de uso basado en identidad autenticada — lo que descarta la práctica común de contraseña única que da acceso total.

FR 3 — System Integrity (SI). El componente se protege de modificación no autorizada. Verificación de integridad de código (firma de firmware), protección contra software malicioso (cuando aplique), validación de input en interfaces de comunicación. Para device embarcado, el ítem central de SL2 es firma criptográfica de firmware con verificación en el boot — sin eso, el componente es vulnerable a malicious update.

FR 4 — Data Confidentiality (DC). Datos sensibles en tránsito y en reposo se protegen. En IACS, "datos sensibles" incluye credenciales, claves, parámetros críticos de configuración y, en algunos casos, telemetría operativa. Para un monitor de tensión DC, la telemetría en sí raras veces es sensible, pero las credenciales y claves usadas para autenticar actualizaciones sí.

FR 5 — Restricted Data Flow (RDF). El componente respeta la segmentación de red. No atraviesa zonas sin necesidad, no hace conexiones espontáneas hacia afuera de la zona, soporta separación de tráfico. Para el integrador esto se traduce en elegir equipo que acepta firewall por delante, configuración de ruteo explícita y ausencia de "llamada a casa" embarcada.

FR 6 — Timely Response to Events (TRE). El componente genera eventos auditables y los disponibiliza al sistema central de eventos. Logs de seguridad en formato consumible (Syslog, registros Modbus dedicados, OPC UA Alarms), timestamp confiable, retención mínima. Componente que no loguea es ciego para el SOC.

FR 7 — Resource Availability (RA). El componente sigue funcionando bajo estrés. Resistencia a denial of service en interfaces de comunicación, gestión de recursos, recuperación tras falla. En SL2 el requisito es razonable — sobrevivir a escaneo agresivo sin trabarse, no exactamente resistir ataque de saturación distribuido.

Componentes a verificar en su proyecto

La parte 4-2 categoriza componentes en cuatro tipos, y cada tipo recibe un subconjunto específico de CRs derivado de los siete FRs. El mapeo simplificado abajo orienta la lectura:

Tipo de componente	Ejemplos típicos en proyecto industrial	CRs aplicables
Software Application	SCADA, historiador, MES	SAR (Software App Requirements) bajo cada FR
Embedded Device	PLC, IED, monitor de magnitud, BMS, AEM-60DC8	EDR (Embedded Device Requirements) bajo cada FR
Host Device	Engineering workstation, servidor OPC	HDR (Host Device Requirements) bajo cada FR
Network Device	Switch industrial, firewall, gateway IIoT	NDR (Network Device Requirements) bajo cada FR

La norma usa esta matriz para no exigir TLS a un sensor que no tiene stack TCP — el requisito de confidencialidad del FR4 se convierte en algo apropiado al embarcado (protección de la configuración que viaja por Modbus dentro de la zona, por ejemplo). El integrador debe mapear cada componente del proyecto a un tipo y luego confrontarlo con los CRs aplicables.

Checklist de aceptación SL2 — 25 ítems objetivos

Los veinticinco ítems abajo son una destilación práctica de las CRs de SL2 de IEC 62443-4-2 traducidas en verificaciones concretas que el integrador puede hacer durante FAT (Factory Acceptance Test) y SAT (Site Acceptance Test) de un componente individual. La lista no sustituye leer la norma, pero cubre los puntos cuya ausencia se señala con más frecuencia en auditoría.

#	Ítem	FR	Cómo verificar
1	Identificadores únicos por usuario humano	FR1	Documentación del fabricante; prueba de creación de usuario
2	Identificadores únicos para servicios/dispositivos	FR1	Documentación; configuración del componente
3	Bloqueo tras N intentos fallidos	FR1	Prueba controlada de fuerza bruta
4	Notificación de uso o banner de aviso	FR1	Pantalla/banner en el login
5	Sesión con timeout configurable	FR1	Configuración y prueba empírica
6	Política de contraseña mínima impuesta por el componente	FR1	Intento de contraseña débil rechazado
7	Permisos granulares por rol	FR2	Matriz rol × función en documentación
8	Separación configuración/operación	FR2	Prueba con usuario solo de operación
9	Bloqueo de comandos no autorizados	FR2	Prueba con usuario sin permiso
10	Auditoría de intentos fallidos de uso	FR2 / FR6	Verificar log tras la prueba
11	Verificación de integridad en el boot	FR3	Intento de firmware modificado debe fallar
12	Firma criptográfica de firmware	FR3	Documentación del esquema; prueba de carga sin firma
13	Anti-rollback de firmware	FR3	Intento de instalar versión anterior debe fallar
14	Validación de input en interfaces de comunicación	FR3	Fuzz controlado de Modbus/SNMP/MQTT
15	Protección de información confidencial en reposo	FR4	Contraseñas y claves no en claro en el firmware
16	Confidencialidad en tránsito cuando aplique	FR4	TLS/HTTPS/SNMPv3 donde la arquitectura lo prevea
17	Soporte de segmentación de red	FR5	Configuración de IP/firewall del componente
18	Ausencia de puertos y servicios innecesarios	FR5	Nmap del componente en red de prueba
19	Ausencia de "phone home" no documentado	FR5	Captura de tráfico en estado idle
20	Generación de log de eventos de seguridad	FR6	Disparar evento y verificar log
21	Timestamps en logs y soporte NTP	FR6	Sincronización y correlación de logs
22	Exportación de log en formato consumible	FR6	Syslog, registros dedicados, OPC UA Alarms
23	Operación bajo carga elevada de comunicación	FR7	Prueba de estrés de polling
24	Recuperación automática tras falla de comunicación	FR7	Cortar y restablecer canal
25	Documentación de hardening publicada por el fabricante	Cross	Hardening guide existe y es accesible

Cada ítem entra como una línea del FAT/SAT con evidencia documental o de prueba adjunta. En proyectos con exigencia contractual de SL2, la ausencia de evidencia en un ítem específico se convierte en una no conformidad gestionable — pero la ausencia del hardening guide del ítem 25, por ejemplo, típicamente indica un proveedor que no sigue la norma y debería ser una preocupación mayor.

Cómo evaluar proveedores — preguntas que hacer para BMS, PLC y HMI

La mayoría de los catálogos de proveedor no responden al integrador en el nivel de detalle que SL2 exige. Las preguntas siguientes, dirigidas al ingeniero de aplicaciones del proveedor (no al representante comercial), separan proveedores serios de los que estampan "Cybersecurity Ready" en el datasheet sin evidencia.

1. ¿Cuál es el esquema de firma de firmware? ¿RSA, ECDSA, Ed25519? ¿Tamaño de clave?
2. ¿El bootloader verifica la firma antes de cada arranque, o solo durante la actualización?
3. ¿Hay anti-rollback de firmware? ¿Cómo se implementa?
4. ¿El componente fue evaluado por laboratorio acreditado contra IEC 62443-4-2? ¿En qué SL? ¿Número de certificado?
5. Si aún no está certificado, ¿cuál es el cronograma de certificación y qué laboratorio?
6. ¿Hay credencial por defecto de fábrica? ¿Cómo se cambia en el comisionamiento?
7. ¿Qué interfaces siguen activas en producción? ¿Hay "modo de desarrollo" que debe deshabilitarse?
8. ¿Hay documento de hardening publicado? ¿Puedo ver la versión actual?
9. ¿Cuál es el ciclo de divulgación de vulnerabilidades del fabricante? ¿Hay canal PSIRT (Product Security Incident Response Team)?
10. ¿Qué CVEs se han publicado contra este producto y cuándo se corrigieron?
11. ¿El fabricante publica SBOM (Software Bill of Materials)?
12. ¿Cuál es el ciclo de vida del producto y hasta cuándo hay compromiso de parches de seguridad?

Una respuesta evasiva en cualquiera de estas doce preguntas es dato relevante para el integrador. Un proveedor que no publica SBOM en 2026 está atrasado tres o cuatro años respecto a las mejores prácticas y casi seguro también está atrasado en otras dimensiones.

Ejemplo concreto — evaluación del AEM-60DC8 contra el checklist

Aplicar el checklist a un componente real vuelve el ejercicio menos abstracto. La evaluación abajo es del AEM-60DC8 con firmware v1.03 contra los veinticinco ítems del checklist. La intención es honestidad: el AEM-60DC8 trabaja contra el objetivo IEC 62443-4-2 SL2, pero el certificado formal de laboratorio acreditado está en planificación y aún no fue emitido. La postura Secure by Design se refiere a la arquitectura del producto, no a una certificación.

#	Ítem	Estado en AEM-60DC8 v1.03
1	Identificadores únicos por usuario humano	No aplica de forma directa — el componente no tiene usuarios humanos locales; el acceso es vía Modbus RTU autenticado a nivel de arquitectura por el gateway IIoT. El integrador implementa identidades en el gateway.
2	Identificadores únicos para servicios/dispositivos	Dirección Modbus única por bus; verificación cruzada por número de serie en registro dedicado.
3	Bloqueo tras N intentos	No aplica a Modbus RTU; mitigación por aislamiento físico del bus y por el gateway.
4	Banner de aviso	No aplica (sin interfaz humana embarcada).
5	Sesión con timeout	Modbus RTU es sin estado; el timeout lo maneja el cliente Modbus.
6	Política de contraseña mínima	No aplica directamente; configuraciones sensibles requieren comando autenticado documentado.
7	Permisos granulares	Separación entre registros de lectura (telemetría) y registros de configuración (write-protect).
8	Separación configuración/operación	Sí, vía tipos de registro distintos.
9	Bloqueo de comandos no autorizados	Las escrituras en registros críticos requieren precondición explícita de modo de configuración.
10	Auditoría de intentos fallidos	Registros Modbus dedicados a eventos (incluida falla de autenticación de comando).
11	Verificación de integridad en el boot	Sí — el bootloader verifica firma Ed25519 antes de cada arranque.
12	Firma criptográfica de firmware	Sí — Ed25519, clave pública embebida en el bootloader.
13	Anti-rollback	Sí — versión mínima persistida en memoria no volátil; intento de instalar v1.02 sobre v1.03 falla.
14	Validación de input	Validación de function code, rango de dirección, tamaño de payload en el parser Modbus.
15	Protección de info confidencial en reposo	Sin credenciales hardcoded en el firmware; la clave pública de verificación es pública por diseño.
16	Confidencialidad en tránsito	Modbus RTU no cifra; la arquitectura asume zona segura o cifrado en el gateway, alineado con el modelo de zonas de IEC 62443-3-3.
17	Soporte de segmentación	Sí — bus RS-485 aislado por diseño de capa física.
18	Sin puertos/servicios innecesarios	Solo Modbus RTU en producción; sin servidor web, sin SSH, sin Telnet, sin MQTT.
19	Sin phone home	Sí — el componente no inicia comunicación espontánea a ningún destino externo.
20	Log de eventos de seguridad	Sí — registros Modbus dedicados, mantenidos en memoria no volátil.
21	Timestamps en logs	Contador interno; sincronización externa por comando Modbus de set-time.
22	Exportación en formato consumible	Lectura Modbus estándar de los registros de log; el gateway traduce a Syslog cuando se configura.
23	Operación bajo carga elevada	Validado en FAT con polling agresivo (10 Hz en bus de tres AEMs sin pérdida de paquete).
24	Recuperación tras falla de comunicación	Recupera estado en menos de 100 ms tras restablecimiento del bus.
25	Hardening guide publicado	Sí — hardening guide publicado en aem.lri.com.br/docs/hardening (referencia arquitectónica).

La evaluación muestra un componente que cubre la mayoría de los ítems directamente aplicables a un device embarcado SL2 (FR3, FR5, FR6, FR7 quedan bien cubiertos) y delega los ítems de identidad humana (FR1, FR2) al gateway IIoT, que es el punto correcto de la arquitectura para implementarlos. La postura "decir no al bloat" — sin servidor web, sin stack TCP/IP, sin MQTT embarcado, sin firmware experimental — reduce drásticamente la superficie de ataque y vuelve más sustentable la defensa en profundidad a largo plazo.

Lo que SL2 no le da

SL2 es un nivel de defensa contra adversario oportunista. No cubre escenarios comunes en el resto de la arquitectura. El integrador debe cubrir los puntos abajo independientemente del nivel de los componentes.

La seguridad del gateway IIoT es responsabilidad del integrador. Un gateway con Linux desactualizado, SSH con contraseña débil o interfaz WAN sin firewall anula la ganancia de cualquier componente SL2 detrás de él. Regla práctica: el gateway es la pieza más expuesta y merece el tratamiento más estricto.

La seguridad de la workstation de ingeniería es invisible desde el componente. Notebook del integrador con clave privada de firma o con credencial SCADA sin protección de hardware (TPM, smart card) es vector frecuente de compromiso.

La seguridad de la cadena de suministro de software complementario (Python, libmodbus, MQTT broker, herramientas de configuración) entra por SBOM y proceso. Los componentes SL2 no eliminan la necesidad de monitorear CVEs de dependencias.

La seguridad física del tablero — llave física del gabinete, control de acceso al sitio, vídeo, alarma de apertura — está cubierta por otros frameworks (NBR ISO/IEC 27002, normas sectoriales) y no por la 62443-4-2.

La seguridad organizativa — política de contraseña, segregación de funciones, proceso de revisión de cambios — viene del programa 62443-2-1 (cybersecurity management system) y no de los requisitos técnicos de componente.

Camino hacia SL3 — cuándo tiene sentido escalar

Mover componentes individuales de SL2 a SL3 es decisión de riesgo, no de marketing. El criterio práctico: el componente en cuestión, si se compromete, ¿causa daño físico inmediato? Si sí, SL3 empieza a tener sentido. Si no, la inversión adicional en SL3 frecuentemente compite con inversiones con mayor retorno en defensa en profundidad.

Ejemplos donde SL3 se justifica: relés de protección en transmisión de alta tensión, control de turbina en generación térmica, SIS (Safety Instrumented System) en planta química, sistemas de gobernadores en hidroeléctricas. Para esos casos, la parte 4-2 prescribe requisitos adicionales — autenticación multifactor para operación crítica, cifrado en tránsito incluso dentro de zona segura, registros de auditoría con integridad verificable, recuperación rápida de incidente.

Ejemplos donde SL2 alcanza y SL3 no aporta ganancia proporcional: monitor de tensión DC en sitio telecom, instrumentación de tanque en utility de agua, supervisión de banco de capacitor en distribución de baja tensión, telemetría de solo lectura en manufactura discreta. En estas aplicaciones el riesgo de compromiso es principalmente operativo y financiero, no de seguridad física, y SL2 cubre lo que debe cubrir.

La decisión debería entrar formalmente en el ejercicio de evaluación de riesgo de IEC 62443-3-2, que mapea activos a zonas, zonas a SL objetivo y SL objetivo a requisitos de componente. Un integrador que recibe una especificación con "SL3 obligatorio" en todo componente sin distinguir zonas críticas de zonas secundarias debería cuestionar al ingeniero de ciberseguridad del cliente — probablemente hubo simplificación excesiva en el documento de requisitos.

FAQ

1. ¿Puedo construir un sistema SL2 con componentes SL1?

En principio no, pero la IEC 62443-3-3 admite que un sistema SL2 use componentes SL1 siempre que el gap se cubra con controles compensatorios documentados (firewall externo, aislamiento físico, monitoreo adicional). La práctica real es evitar esa ruta porque la evidencia se complica en auditoría.

2. ¿Quién certifica un componente SL2?

Laboratorios acreditados, con programas como ISCI ISASecure CSA (Component Security Assurance) o TÜV SÜD/SGS/Bureau Veritas en algunos países. El certificado es del componente en una versión específica de firmware. Cambios mayores de firmware suelen exigir reevaluación. El fabricante que dice "estamos en conformidad con SL2" sin certificado está haciendo una declaración de conformidad propia, válida pero con peso distinto en auditoría.

3. ¿Cuánto cuesta certificar un componente SL2?

Varía bastante. El rango público publicado por laboratorios para CSA ISASecure quedó entre US$ 40 mil y US$ 150 mil en 2024 dependiendo de la complejidad del componente. El proceso dura seis a dieciocho meses. Componentes muy específicos pueden usar autoevaluación documentada como paso intermedio.

4. ¿Modbus RTU puede ser SL2?

Un componente cuya única interfaz es Modbus RTU puede cumplir SL2 siempre que la confidencialidad en tránsito no sea requisito (la arquitectura asume zona segura o cifrado en el gateway) y los demás FRs se cumplan por el componente mismo. En muchos casos esto es más limpio que protocolos más complejos.

5. ¿SL2 alcanza para conformidad NIS2 o regulación brasileña de infraestructura crítica?

NIS2 (Unión Europea) y su equivalente brasileño en construcción tienden a exigir programa de ciberseguridad gerencial (más cercano a la parte 2-1 de 62443) que SL específico de componente. SL2 contribuye significativamente como prueba de buena fe técnica, pero la conformidad regulatoria incluye proceso y gobernanza que van más allá del componente.

Referencias

• IEC 62443-1-1:2009 — Industrial communication networks — Network and system security — Part 1-1: Terminology, concepts and models.
• IEC 62443-3-2:2020 — Security risk assessment for system design.
• IEC 62443-3-3:2013 — System security requirements and security levels.
• IEC 62443-4-1:2018 — Secure product development lifecycle requirements.
• IEC 62443-4-2:2019 — Technical security requirements for IACS components.
• IEC 62443-2-1:2024 — Security program requirements for IACS asset owners.
• ISASecure CSA — Component Security Assurance Certification.
• NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security.
• ANSI/ISA-62443 — versión norteamericana armonizada con IEC 62443.
• LRI — AEM-60DC8 Datasheet v1.03, Hardening Guide y Mapa de 147 holding registers.

---