IEC 62443-4-1: el ciclo de desarrollo seguro para productos industriales

¿Qué es IEC 62443-4-1?

IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, se publicó en enero de 2018. Según su propio alcance, especifica requisitos de proceso para el desarrollo seguro de productos utilizados en sistemas de automatización y control industrial. El ciclo de vida que define abarca la definición de los requisitos de seguridad, el diseño seguro, la implementación segura, la verificación y validación, la gestión de defectos, la gestión de parches y el fin de vida del producto.

Se aplica a quien desarrolla y mantiene un producto: el proveedor del producto que fabrica controladores, dispositivos embebidos, equipos de red, software de host o aplicaciones. No se aplica al integrador ni al usuario del producto, que tienen sus propias partes de la serie. ISA publica la serie como ISA/IEC 62443.

La norma describe requisitos de proceso, políticas y procedimientos, y no funciones técnicas de seguridad. Los requisitos técnicos para componentes están en IEC 62443-4-2.

Las ocho prácticas de IEC 62443-4-1

Los requisitos se agrupan en ocho prácticas, cada una con una abreviatura corta que sirve de prefijo a los ID de sus requisitos. La ISA Global Cybersecurity Alliance enumera 47 requisitos en total:

Práctica	Requisitos	Qué cubre
1. Gestión de la seguridad (SM)	SM-1 a SM-13	Planificar y gestionar el proceso de seguridad: responsabilidades, conocimientos, seguridad del entorno de desarrollo, claves privadas, componentes externos y de terceros, verificación del proceso, mejora continua
2. Especificación de los requisitos de seguridad (SR)	SR-1 a SR-5	Contexto de seguridad del producto, modelo de amenazas, requisitos de seguridad del producto y su revisión
3. Seguridad desde el diseño (SD)	SD-1 a SD-4	Principios de diseño seguro, diseño de defensa en profundidad, revisión del diseño, buenas prácticas de diseño
4. Implementación segura (SI)	SI-1 a SI-2	Revisión de la implementación de seguridad y estándares de codificación segura
5. Pruebas de verificación y validación de seguridad (SVV)	SVV-1 a SVV-5	Pruebas de requisitos, de mitigación de amenazas, de vulnerabilidades y de penetración, independencia de quienes prueban
6. Gestión de problemas relacionados con la seguridad (DM)	DM-1 a DM-6	Recibir, revisar, evaluar, abordar y divulgar los problemas de seguridad del producto
7. Gestión de actualizaciones de seguridad (SUM)	SUM-1 a SUM-5	Cualificar, documentar y entregar a tiempo las actualizaciones de seguridad
8. Directrices de seguridad (SG)	SG-1 a SG-7	Documentación para usuarios sobre defensa en profundidad, bastionado, operación segura, gestión de cuentas y eliminación

Práctica 6: gestión de problemas relacionados con la seguridad (DM)

DM es la práctica que un PSIRT reconoce como propia. Según la ISAGCA, sus procesos se utilizan para gestionar los problemas de seguridad de un producto configurado conforme a su estrategia de defensa en profundidad. Sus seis requisitos siguen un problema desde la notificación hasta el cierre:

• DM-1: Recepción de notificaciones de problemas relacionados con la seguridad
• DM-2: Revisión de problemas relacionados con la seguridad
• DM-3: Evaluación de problemas relacionados con la seguridad
• DM-4: Tratamiento de problemas relacionados con la seguridad
• DM-5: Divulgación de problemas relacionados con la seguridad
• DM-6: Revisión periódica de la práctica de gestión de defectos de seguridad

En pocas palabras: recibir las notificaciones, comprobarlas, evaluarlas, corregirlas, informar a los usuarios y revisar el propio proceso.

Esa secuencia es el ciclo de vida de la gestión de vulnerabilidades con otro nombre, y DM-1 y DM-5 son los puntos en los que entra la divulgación coordinada de vulnerabilidades. La divulgación puede publicarse como un aviso CSAF, con una declaración VEX para las versiones que no están afectadas.

Práctica 7: gestión de actualizaciones de seguridad (SUM)

SUM toma el relevo cuando DM decide una corrección. Sus procesos, según el resumen de la ISAGCA, garantizan que las actualizaciones de seguridad del hardware, el software o el firmware del producto se prueben para detectar regresiones y se pongan a disposición de los usuarios a tiempo. Los cinco requisitos son:

• SUM-1: Cualificación de las actualizaciones de seguridad
• SUM-2: Documentación de las actualizaciones de seguridad
• SUM-3: Documentación de las actualizaciones de seguridad de componentes dependientes o del sistema operativo
• SUM-4: Entrega de las actualizaciones de seguridad
• SUM-5: Entrega a tiempo de los parches de seguridad

SUM-3 es el que llega a su cadena de suministro: las actualizaciones de los componentes y sistemas operativos de los que depende su producto. En un producto embebido basado en una distribución de Linux, pueden ser la mayoría de los parches que distribuye.

Niveles de madurez

IEC 62443-4-1 no pregunta si existe un proceso; pregunta cuán maduro es. Utiliza cuatro niveles de madurez, basados en CMMI for Development:

Nivel	Significado
ML1 Inicial	Los procesos se realizan de forma improvisada o sin documentar
ML2 Gestionado	Los procesos están documentados y describen cómo se realiza y se gestiona la actividad
ML3 Definido (practicado)	Los procesos están documentados, se ejecutan y son repetibles
ML4 En mejora	Los procesos mejoran con el tiempo mediante métricas de rendimiento y eficacia

La diferencia entre ML2 y ML3 es la práctica. Un proceso DM por escrito puede ser ML2. ML3 significa que el proceso se ha ejecutado y repetido: problemas recibidos, evaluados y cerrados, actualizaciones entregadas, con los registros que lo demuestran.

Certificación

• ISASecure SDLA. El programa Security Development Lifecycle Assurance certifica el proceso de ciclo de vida de una organización de desarrollo conforme a IEC 62443-4-1. Las evaluaciones las realizan laboratorios SDLA autorizados y acreditados como organismos de evaluación de la conformidad.
• Organismos de certificación y el IECEE CB Scheme. Organismos de ensayo y certificación como Applus+ y TÜV Rheinland evalúan a los proveedores frente a 62443-4-1 e indican el nivel de madurez alcanzado, también en el marco del IECEE CB Scheme, aplicable en más de 50 países.

Un certificado 62443-4-1 cubre el proceso de desarrollo del proveedor, no un producto concreto. Los productos se evalúan por separado frente a 62443-4-2.

Cómo se relaciona 62443-4-1 con el resto de la serie

• IEC 62443-4-2, requisitos técnicos de seguridad para componentes de IACS: lo que el producto debe ser capaz de hacer. 4-1 es cómo se construye y se mantiene.
• IEC 62443-3-3, requisitos de seguridad del sistema y niveles de seguridad: los requisitos técnicos equivalentes a nivel de sistema.
• IEC 62443-2-4, requisitos del programa de seguridad para proveedores de servicios de IACS: los integradores y proveedores de mantenimiento que instalan y mantienen su producto en las instalaciones del propietario de los activos, y que dependen de sus actualizaciones y directrices de seguridad.

Correspondencia entre IEC 62443-4-1 y el trabajo de un PSIRT

Actividad del PSIRT	Dónde encaja en 62443-4-1
Recepción de informes de vulnerabilidades	DM-1
Triaje y análisis	DM-2, DM-3
Remediación	DM-4, SUM-1
Avisos y divulgación	DM-5, SUM-2
Parches para componentes de terceros	SUM-3, con SM-9 y SM-10 sobre componentes externos y de terceros
Lanzamiento de la corrección	SUM-4, SUM-5
Métricas y revisión del proceso	DM-6, SM-13

Esta correspondencia es nuestra, según el título de cada requisito. La norma no menciona a los PSIRT por su nombre; el mismo trabajo se describe en el PSIRT Services Framework de FIRST y en ISO/IEC 30111.

Las SBOM como evidencia para DM y SUM

Los títulos de los requisitos de 2018 no mencionan las SBOM. Pero muchos de los problemas de seguridad de un producto industrial están en componentes que su proveedor no escribió: el kernel de Linux, OpenSSL, BusyBox, una pila de protocolos. Responder a DM-2 y DM-3 ante un nuevo aviso significa saber qué productos y versiones contienen el componente afectado. Documentar las actualizaciones de SUM-3 significa saber con qué versiones de componentes se distribuyó cada lanzamiento. En ML3, esas respuestas necesitan registros que las respalden.

Una lista de componentes escrita a mano, o un escaneo del árbol de código fuente, se queda desactualizada. Una SBOM del build que generó la versión no, siempre que el propio build quede registrado.

Dónde encaja CRACI

CRACI no certifica nada conforme a IEC 62443 ni gestiona su proceso de desarrollo. Sus registros pueden servir como evidencia de partes de él: el inventario de componentes de cada versión y la monitorización de los builds distribuidos en busca de nuevas vulnerabilidades.

CRACI ejecuta builds de GitHub Actions, incluidos los builds de Yocto, en sus propios runners y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas, los paquetes restaurados desde cachés y las dependencias que ningún lockfile recoge. Cada SBOM incluye un estado de completitud y se exporta en CycloneDX o SPDX. Las SBOM monitorizadas se reevalúan continuamente, el historial de builds muestra qué builds anteriores contenían una dependencia vulnerable y la vista de inventario muestra qué versiones están desplegadas en qué productos. Las SBOM de proveedores para componentes adquiridos se monitorizan junto con sus propios builds. Consulte el seguimiento de vulnerabilidades y CRACI para PSIRT.

IEC 62443-4-1: preguntas frecuentes

¿Qué es IEC 62443-4-1?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, es la parte de la serie IEC 62443 que establece requisitos de proceso para los proveedores que desarrollan productos utilizados en sistemas de automatización y control industrial. Abarca los requisitos de seguridad, el diseño seguro, la implementación, la verificación y validación, la gestión de defectos, la gestión de parches y el fin de vida del producto.

¿Cuáles son las ocho prácticas de IEC 62443-4-1?

Gestión de la seguridad (SM), especificación de los requisitos de seguridad (SR), seguridad desde el diseño (SD), implementación segura (SI), pruebas de verificación y validación de seguridad (SVV), gestión de problemas relacionados con la seguridad (DM), gestión de actualizaciones de seguridad (SUM) y directrices de seguridad (SG). En conjunto contienen 47 requisitos.

¿Cuál es la diferencia entre IEC 62443-4-1 y 62443-4-2?

4-1 trata del proceso que utiliza un proveedor para desarrollar y mantener productos. 4-2 establece requisitos técnicos de seguridad para los propios componentes, como dispositivos embebidos, dispositivos de red, dispositivos host y aplicaciones de software. Un proveedor suele evaluarse frente a 4-1 por su proceso de desarrollo y frente a 4-2 por un producto concreto.

¿Qué prácticas de IEC 62443-4-1 cubren la gestión de vulnerabilidades?

Principalmente la práctica 6, gestión de problemas relacionados con la seguridad (DM-1 a DM-6), que cubre la recepción, revisión, evaluación, tratamiento y divulgación de los problemas de seguridad, y la práctica 7, gestión de actualizaciones de seguridad (SUM-1 a SUM-5), que cubre la cualificación, documentación y entrega a tiempo de las actualizaciones de seguridad. Este es el trabajo que hace un PSIRT.

¿Cuáles son los niveles de madurez de IEC 62443-4-1?

Cuatro niveles, basados en CMMI for Development: ML1 Inicial (improvisado o sin documentar), ML2 Gestionado (procesos documentados), ML3 Definido o practicado (documentado, ejecutado y repetible) y ML4 En mejora (procesos que mejoran con el tiempo mediante métricas de rendimiento).

¿Cómo se obtiene la certificación IEC 62443-4-1?

A través de un organismo de certificación acreditado. El programa SDLA de ISASecure certifica a organizaciones de desarrollo conforme a IEC 62443-4-1 mediante laboratorios autorizados, y organismos de certificación como TÜV Rheinland y Applus+ emiten certificados 62443-4-1 que indican el nivel de madurez alcanzado, también en el marco del IECEE CB Scheme.

¿IEC 62443-4-1 exige una SBOM?

Los títulos de los requisitos de 2018 no mencionan las SBOM. Varios requisitos tratan de los componentes externos y de las actualizaciones de componentes dependientes y sistemas operativos, y una lista fiable de los componentes de cada versión es la forma práctica de demostrar cómo los gestiona.