Foto: Gentileza de Pilz GmbH & Co. KG
Al analizar uno por uno los 47 requisitos de la IEC 62443-4-1, la implantación puede parecer sumamente laboriosa, sobre todo si el desarrollo del producto seguía hasta ahora un enfoque más directo, en lugar de basarse en los procesos pertinentes. En este caso, se debe implementar en primer lugar el requisito SM-1 “Development process”, que establece la necesidad de documentar y aplicar un proceso general de ciclo de vida útil. En cambio, si existe un proceso de estas características que considere además los requisitos de seguridad funcional según IEC 61508 o de alguna de las normas relacionadas específicas del sector, es posible identificar requisitos parecidos o iguales y aplicarlos de antemano.
El requisito SM-5 “Process scoping” define que el proceso debe adecuarse mediante un análisis de la Security al proyecto de desarrollo en curso. De este modo, no hay que considerar requisitos particulares o parciales cuando un sistema no dispone, por ejemplo, de interfaces externos o si en el marco de un proyecto de modificación se actualizan solo catálogos de idiomas o incluso componentes descontinuados.
Similitudes y sinergias entre las normas IEC 61508 e IEC 62443-4-1
Ejemplo 1: Formación de los trabajadores
El requisito SM-4 “Security Expertise” establece que debe existir un proceso para la identificación de las necesidades de formación y para la formación de los trabajadores, de manera que estos puedan llevar a cabo correctamente sus funciones y responsabilidades en el proceso de Security. En los apartados 6.2.12 a 6.2.15 del capítulo 6 “Management of functional safety” de la norma IEC 61508-1, se formulan requisitos comparables (aunque más detallados).
Aunque los conocimientos específicos que deban impartirse en relación con Safety y Security son diferentes, temas como “Defensive Programming” (programación defensiva) o la aplicación del estándar de programación MISRA (Motor Industry Software Reliability Association), procedente del sector automotriz, tendrán la misma importancia para los dos ámbitos, de modo que favorecerán incluso sinergias de contenido.
Ejemplo 2: Codificación
El grupo Practice 4 – “Secure Implementation” de la norma IEC-62443-4-1 define dos requisitos:
1) El requisito SI-1 “Security implementation review” exige la aplicación de un proceso de ejecución de revisiones de códigos para poder analizar diferentes aspectos a nivel de codificación. Generalmente consiste en la revisión del código fuente por parte de una o más personas. Paralelamente se exige la realización de un análisis estático de códigos con herramientas de software específicas.
Pueden encontrarse requisitos similares en la norma IEC 61508-3. En el apartado 7.4.6 “Requirements for code implementation”, se establece la necesidad de analizar todos los módulos de software. En este sentido se hace referencia a los apartados C.5.14 “Formal inspections” y C.5.15 “Walk-through (software)” de la IEC 61508-7. Quienes hayan implementado estos requisitos para alcanzar la seguridad funcional en su proceso de desarrollo no tienen que preocuparse de saber cómo se organizan y documentan estas revisiones o cómo se gestionan las eventuales divergencias detectadas. Naturalmente seguirá siendo imprescindible que en la revisión participen personas con conocimientos sobre Security.
Foto: Gentileza de Pilz GmbH & Co. KG
En la tabla A.9 “Software verification” de la IEC 61508-3, se recomienda asimismo el análisis estático como recurso, en tanto que en el apartado B.6.4 de la IEC 61508-7 se señala la ejecución informática como posible opción.
2) El requisito SI-2 “Secure coding standards” establece la necesidad de definir reglas de programación para evitar errores de Security y la comprobación y actualización periódica de estas reglas. De nuevo encontramos un requisito comparable en la IEC 61508-3. En el apartado 7.4.4.12 se establece que deben utilizarse lenguajes de programación conforme a directrices adecuadas. Por lo que respecta al contenido de estas reglas, se hace referencia a la norma IEC 61508-7. Las instrucciones correspondientes pueden consultarse en el apartado C.2.6 “Design and coding standards” de la misma.
Uno de los fines de este conjunto de reglas es evitar errores de programación, ya que representan un problema general de calidad y pueden llegar a repercutir gravemente tanto en la Safety como en la Security. Los errores de programación típicos, como el desbordamiento de la memoria y la ausencia de verificación de los datos de entrada, constituyen un riesgo para la Safety. No obstante, figuran también entre los errores “clásicos” a la hora de programar la Security. En consecuencia, la existencia de un conjunto de reglas concebidas para alcanzar la seguridad funcional representa también un buen comienzo para la Security.
Ejemplo 3: Gestión de problemas
En Practice 6 – “Management of security-related issues” se describen diferentes requisitos para gestionar los problemas de Security identificados. Se exige la existencia de procesos para la recepción de mensajes de Security (por ejemplo, de clientes o investigadores de Security), la notificación de usuarios afectados, el análisis de los problemas comunicados y la prevención futura de errores comparables. Volvemos a encontrar requisitos equivalentes en el capítulo 6 “Management of functional safety” de la norma IEC 61508-1, de manera que una empresa que haya implementado los requisitos dispondrá de procesos adecuados que posiblemente podrán trasladarse sin grandes cambios a la gestión de problemas con la Security.
Los ejemplos citados han puesto de manifiesto que los procesos adecuados para el cumplimiento de los requisitos de la IEC 61508 lo son también para la implementación de los requisitos de la IEC 62443-4-1, ya sea directamente o con ampliaciones mínimas. El reto del desarrollo seguro de productos no está tanto en la definición de los procesos adecuados sino en el ámbito técnico. Todo fabricante que quiera profundizar en el tema Security deberá velar porque todas las personas implicadas en el proceso de desarrollo dispongan de los conocimientos técnicos adecuados.
Foto: Gentileza de Pilz GmbH & Co. KG
La Security es una tarea que abarca el ciclo de vida completo del producto
Otro de los grandes retos es que la Security es un “objetivo en movimiento”: los componentes de automatización (por ejemplo, un PLC) pueden tener en un momento determinado la clasificación de “seguro”, pero al día siguiente la situación de riesgo puede cambiar y, con ello, la seguridad contra ataques al dispositivo. Es decir, es preciso actualizar continuamente las medidas contra ciberamenazas.
En este sentido, la responsabilidad recae primero en los operadores de instalaciones, para quienes la seguridad de datos es sinónimo de protección de la inversión. Por otro lado, los constructores de máquinas y los fabricantes de componentes tienen el deber de informar inmediatamente sobre nuevos problemas de seguridad a los operadores y de proporcionar actualizaciones del software de sus equipos que permitan subsanar las brechas de seguridad. Esto requiere, no obstante, que ambas partes colaboren estrechamente a lo largo del ciclo de vida completo de los productos.
Cualquier fabricante responsable cuyos productos vayan a utilizarse en un mundo digitalizado debería preocuparse por el tema Security, sobre todo si estos productos tienen la finalidad de velar por la seguridad en términos de Safety. En otras palabras, aunque estas dos facetas de la automatización sigan cubriendo áreas independientes, es necesario que estén estrechamente coordinadas. La buena noticia es que quien ya esté familiarizado con Safety lo tendrá más fácil con Security, debido a la similitud entre ambos procedimientos.
Por Frank Eberle, Desarrollo de Productos Pilz GmbH & Co. KG. / Artículo gentileza de Pilz. / www.pilz.com