Por “Security” se entiende el aseguramiento de los objetivos de protección de confidencialidad, integridad y disponibilidad. Los requisitos de Security en los ámbitos de la TI y de la automatización son claramente diferentes. Mientras que en la oficina tiene máxima prioridad la confidencialidad de la información, a nivel de producción lo importante son la disponibilidad y la integridad de los datos. Por un lado, se trata de un requisito crucial para procesos de fabricación eficientes y, por otro lado, debemos tener en cuenta que un ataque a la integridad de un sistema de Safety puede provocar graves accidentes. Por esta razón, se incluyó un suplemento en el capítulo 7.4 “Hazard and risk analysis” de la edición 2.0 de la IEC 61508-1. Según este texto, debe realizarse un análisis si se considera probable “de manera razonada” la existencia de una amenaza para la Security.
En consecuencia, sobre todo los fabricantes de sistemas de Safety deben estar al día en cuestiones sobre Security. No obstante, también los fabricantes de sistemas que no implementan funciones relativas a la seguridad deberían estar familiarizados con el tema Security, a fin de evitar ataques a los procesos de producción.
Es necesaria una Security optimizada
La Security actual de las instalaciones de producción se realiza a menudo con componentes como firewalls y gateways de VPN. Industry 4.0 e IoT harán aumentar las relaciones de comunicación entre los componentes de automatización y con sistemas externos. Como consecuencia, los costos para la administración de soluciones Security externas serán mayores. Por otra parte, el uso de tecnologías inalámbricas condiciona la eficacia de la protección ofrecida por los cortafuegos debido a la posibilidad de que los ataques tengan lugar directamente a través del interface de radiocomunicación y las capas de protocolo inferiores. Para atajar estos problemas es preciso implantar las medidas de Security directamente en los sistemas.
¿Qué significa “Security by Design”?
El concepto “Security by Design” o “Secure by Design” describe un enfoque de desarrollo en el que las características de la Security de un sistema se tienen en consideración desde la misma fase de diseño. Es decir, la necesidad o no de implantar funciones de Security en un sistema y el alcance de estas no son fruto de la improvisación o del criterio de determinados desarrolladores. En lugar de ello, se emplean modelos de amenazas (“Threat Modelling”) para determinar las amenazas a las que está expuesto un sistema. De aquí se derivan medidas selectivas para minimizar el riesgo en términos de Security.
En un sentido más amplio, “Security by Design” puede entenderse también como un enfoque que considera la Security de un producto a lo largo de su ciclo de vida completo. Un ejemplo bien documentado de este enfoque, y del que se ha hecho amplia referencia, es el proceso “Security Development Lifecycle (SDL)” desarrollado por Microsoft.
Las normas como punto de partida
Por tanto, hace tiempo que la Security juega un papel central en la TI clásica. Sin embargo, las distintas prioridades en materia de confidencialidad y disponibilidad impiden extender los requisitos sin más al ámbito de la automatización.
Gracias a la publicación de la IEC 62443 “Redes de comunicación industrial. Seguridad de la TI para redes y sistemas”, se dispone ahora de una serie de normas internacionales parcialmente aprobadas en las que se aborda exhaustivamente la seguridad de la TI en la automatización. El abanico de temas va desde el análisis de riesgos y mejores prácticas hasta el desarrollo seguro de productos (Security by Design). Esto la convierte en la mejor guía de la actualidad para la implementación eficiente de la Security por parte de operadores de instalaciones y fabricantes de equipos.
La IEC 62443 fue definida originariamente por el comité ISA99 “Industrial Automation and Control Systems Security” y adoptada posteriormente por el organismo de normalización IEC. Los requisitos concretos se clasifican en grupos, denominados “Practices”, que se describen a continuación de forma resumida:
Practice 1 – Security management:
Este “Practice” recoge varios requisitos para la gestión del proceso de desarrollo. Esto incluye, entre otros, la existencia de un proceso general de ciclo de vida del producto, la designación de personas responsables y la necesidad de formar a los trabajadores en lo que respecta a su función en el proceso y sus conocimientos sobre Security. Asimismo, se formulan requisitos sobre la Security del entorno de desarrollo y el manejo de componentes individuales de otros fabricantes.
Practice 2 – Specification of security requirements:
Este “Practice” describe reglas de especificación de requisitos de Security. El “Product security context”, por ejemplo, establece la necesidad de definir desde la perspectiva de la Security el contexto del sistema que se va a desarrollar. El contexto describe las características físicas de Security del entorno (por ejemplo, el sistema debe operar en un armario de distribución cerrado) y las características del entorno de red (por ejemplo, el sistema debe estar protegido por un cortafuegos). El contexto de Security es una magnitud inicial relevante para el modelado de las amenazas, que es otro de los criterios exigidos.
Practice 3 – Secure by design:
En este apartado se establecen los requisitos de diseño del sistema. Así deben usarse, por ejemplo, las técnicas reconocidas de Security y los patrones de diseño como “Security by Design”. A través de estas especificaciones se implementa la primera interpretación del concepto “Security by Design”.
Practice 4 – Secure implementation:
Los requisitos del grupo Practice “Secure implementation” tienen por objeto garantizar que no aparecerán brechas de Security por errores en la implementación. Esto incluye el cumplimiento de normas de codificación reconocidas y la realización de un análisis estático del código y de una revisión del código.
Practice 5 – Security verification and validation testing:
En este “Practice” se establece el tipo de pruebas de Security que se realizarán. Asimismo, contiene requisitos relativos a la independencia de los analizadores.
Practice 6 – Management of securityrelated issues:
El grupo Practice “Management of security-related issues” describe requisitos de manejo de problemas con la Security del producto. Además de requisitos de análisis de problemas, abarca igualmente la recepción de mensajes (por ejemplo, de clientes o investigadores de Security) y la notifi- cación a los usuarios sobre problemas de Security detectados.
Practice 7 – Security update management:
Aquí se formulan requisitos de gestión de actualizaciones de la Security. Comprende, entre otros, el proceso de aseguramiento de que la actualización servirá realmente para subsanar una brecha y que no ocasionará nuevos problemas. Se establece asimismo el deber del fabricante de informar al usuario acerca de la posibilidad o no de instalar sin reacciones las actualizaciones de Security de componentes dependientes (como el sistema operativo con el que funciona el producto).
Practice 8 – Security guidelines:
En este “Practice” se definen requisitos relativos al contenido de la documentación de usuario. Se exige, por ejemplo, la inclusión de indicaciones sobre las medidas requeridas para el blindaje del sistema y lo que debe tenerse en cuenta a la hora de desenergizar el equipo o dispositivo.
En la siguiente parte de este artículo, veremos cómo usar las sinergias para reducir el trabajo en la implementación de los requisitos de la IEC 62443-4-1.
Por Frank Eberle, Desarrollo de Productos Pilz GmbH & Co. KG.
Artículo gentileza de Pilz. www.pilz.com