Buenas prácticas de desarrollo seguro en control industrial
Entre las prioridades de los estándares y regulaciones de ciberseguridad industrial más extendidos, se puede apreciar un nuevo enfoque más completo de los equipos de control industrial. Estándares como el IEC 62443, ponen cada vez más énfasis en la gestión del riesgo de ciberseguridad a lo largo del ciclo de vida y de la cadena de suministro de los equipos industriales. Esto presenta varias ventajas para quienes siguen los estándares:
- Prevenir vulnerabilidades de ciberseguridad. Estos problemas habitualmente se corregían retroactivamente, necesitando más recursos y soluciones menos efectivas.
- Transferir responsabilidades del cliente final que utiliza al producto, a los proveedores con mayor conocimiento y capacidad de actuación sobre los equipos que suministran.
- Crear oportunidades de colaboración entre clientes y proveedores en materia de ciberseguridad.
- Destacar las capacidades de ciberseguridad de equipos industriales como ventajas de producto, convirtiéndolas en cualidades atractivas que puedan incluirse en el marketing del producto, a la vez que fomentan la concienciación de ciberseguridad en el mercado.
Sin embargo, pese a las ventajas de incorporar la ciberseguridad desde el inicio del ciclo de vida y los requisitos de nuevas regulaciones, se observa que la gran mayoría de fabricantes todavía desconocen cómo abordar estas nuevas medidas. Sobre todo, en una de las etapas más críticas del proceso, la etapa de desarrollo del producto, donde se pasa del diseño al producto real, se desarrolla el código, se construye el hardware y se establecen las conexiones entre componentes necesarias para el funcionamiento del mismo.
Para ayudar en esta etapa crítica, en este artículo se pretende ayudar a solucionar esta discrepancia entre criticidad y falta de concienciación, aportando información y consejos sobre buenas prácticas de desarrollo seguro y su aplicación a equipos de control industrial.
Riesgos de ciberseguridad durante el desarrollo
El primer paso en el proceso de desarrollo seguro de equipos industriales es responder a la pregunta: ¿Frente a qué debemos protegernos durante el desarrollo de equipos industriales?
Se pueden diferenciar dos tipos de riesgos durante la etapa de desarrollo:
- Riesgos de la organización: aquellos que afectan a los procesos de desarrollo de la organización.
- Riesgos del producto en desarrollo: riesgos contra los que el equipo en desarrollo deberá defenderse durante toda su vida útil.
Los riesgos de la organización se gestionan mediante los procedimientos de ciberseguridad habituales que una organización debe establecer internamente y no deben olvidarse durante la etapa de desarrollo.
Por otro lado, los riesgos del producto son el foco principal de las buenas prácticas de desarrollo. Afrontar estos riesgos durante el desarrollo del producto, cuando sus características aún pueden alterarse y afinarse, es mucho más eficaz y eficiente que hacerlo de manera retroactiva.
Estos riesgos deben ser identificados y modelados por la empresa antes del inicio del proceso de desarrollo. Este ejercicio genera la fuente de información principal que alimentará la definición de medidas de seguridad del nuevo producto.
Buenas prácticas para el ciberdesarrollo seguro
El siguiente apartado recoge prácticas de seguridad recomendables, seleccionadas y comentadas por su relevancia y aportación al nivel de madurez de seguridad del desarrollo de equipos industriales. Para una mayor legibilidad, se han clasificado por orden cronológico (aproximado) en las que su aplicación debería tenerse en cuenta durante el desarrollo.
Ecosistema del producto
El producto debe contar, desde el inicio, con una arquitectura interna que cumpla los principios de:
- Seguridad por diseño: los propios elementos pasivos de la arquitectura deben aportar a la seguridad del producto.
- Desde el momento de ideación del producto se debe tener en cuenta la seguridad como factor fundamental.
- Se deben reducir la cantidad de elementos diferentes necesarios, dejando solo los imprescindibles. Esto se aplica al hardware, al software y a las conexiones que intervengan.
- Si se van a usar componentes existentes en el mercado, merece la pena buscar componentes con certificados de seguridad, o al menos, con medidas de seguridad relevantes para los riesgos identificados.
- Si los componentes son de desarrollo propio, los requisitos de seguridad deben definirse e incluirse desde el inicio, no como parches a posterior.
- Seguridad en profundidad: creando una arquitectura con varios niveles que dificulte el acceso a los elementos críticos.
- Los puntos de entrada al producto (servicios web, canales de comunicación, puertos de conexión…) tienen que estar identificados y protegidos.
- No debería haber caminos directos entre los puntos de entrada y los elementos críticos.
- Si el producto tiene varios componentes, los componentes críticos deberían estar segmentados.
- Si el producto es un único equipo, la segmentación debería estar definida en la lógica interna o en el propio hardware del equipo (privilegios de ejecución, interfaces de conexión diferentes, etc.).
- Mínimos privilegios: los equipos utilizados deben permitir la restricción de acceso a las funciones e información, según las necesidades y el rol de los usuarios.
- Se deben incluir las capacidades de gestión de roles y privilegios en todos los productos que requieran interacción con usuarios.
- Por la naturaleza de los equipos industriales, es probable que no tengamos las capacidades técnicas para una gestión completa. Pero estas limitaciones inherentes deben identificarse para buscar soluciones alternativas.
Funcionamiento y lógica del producto
Las medidas a aplicar en este apartado dependerán en gran medida del tipo de producto, pero pueden identificarse principios generales de aplicación para todos los casos:
- Definir las capacidades del producto. En entornos industriales es esencial poder confiar en que los equipos se comporten de la manera esperada. El operario de un brazo robótico tiene que estar seguro del movimiento que va a hacer el robot antes de iniciarlo, de lo contrario podría causar accidentes y daños físicos. Por lo tanto, conviene responder a qué capacidades tiene el producto y cuáles son sus limitaciones.
- Aplicar límites de seguridad. Hay productos que tendrán límites que, por seguridad o funcionalidad, no deberían sobrepasarse en ningún caso, como pueden ser la velocidad de movimiento, las temperaturas extremas, etc. Estos casos deben implementarse en el producto de manera que no puedan alterarse o manipularse.
- Asegurar acciones deterministas. Para aquellas variables o funciones que sí deban poder ser manipuladas, es importante garantizar al usuario que cada producto es conocido para cada acción concreta. Una orden de movimiento a un robot debería posicionar al robot en las coordenadas adecuadas, fijar la temperatura en un horno debería calentarlo a la temperatura deseada, etc. En este sentido, no solo debería estar definido el resultado final, sino también cómo se llega a este (velocidad, trayectoria…). Las salidas deberían ser siempre deterministas (dentro de sus rangos de tolerancia definidos), las fuentes de ambigüedad, casos frontera o entradas inesperadas deberían tenerse en cuenta durante el desarrollo y solucionarse antes de la puesta en producción.
- Interrupción y parada. La ejecución del producto debería poder detenerse manualmente, o por elementos de safety, en cualquier momento. No es suficiente con que está parada se ejecute debidamente (el equipo no debe reanudarse por su cuenta, ninguna función debe tener más autoridad de ejecución que la parada, etc.), también debe de ser completamente seguro. Los elementos móviles deben desacelerar de manera segura, mientras que la parada en elementos de sujeción (bombas de vacío, tenazas, ganchos…) o de control de temperatura, la actuación segura dependerá de su estado. Por ejemplo, un puente grúa moviendo una carga, en caso de parada, no debería soltar la carga sin control.
- Firmado y control de versiones. Debe mantenerse un registro de las versiones desarrolladas y desplegadas. Especialmente en el caso del software, ya que este experimenta muchas modificaciones a lo largo de su vida útil. Además, el software debe contar con firmas de autoría y registros de cambios. Por último, es recomendable contar con controles de integridad (p.ej. chequeos de hashes de código), tanto periódicos, como durante los cambios o actualizaciones de software, para evitar manipulaciones.
Validación de los datos de entrada
Una vez se ha definido cómo va a operar un producto, es necesario controlar cómo los usuarios van a interactuar con él. Además de los aspectos ya introducidos previamente, como el principio de mínimos privilegios y la necesidad de actuaciones deterministas, la validación de entradas de usuarios se considera una prioridad esencial para la interacción con usuarios.
Este proceso consiste en verificar cada uno de los datos introducidos, por usuarios o por otros equipos. El producto debe comprobar que el dato tiene el formato y la información esperada, es decir, si se da un valor a una variable numérica, el valor tiene que ser un número dentro del rango definido; si se programa una fecha para finalizar una ejecución, está tendrá que ser válida y cumplir con todo lo definido en la especificación.
Estos controles deben aplicarse para todas las variables modificables y todos los campos donde un usuario pueda introducir datos, desde los campos de login y password de una aplicación web, hasta la carga de nuevas lógicas a un PLC.
Registros
El producto debe contar con capacidades internas de recogida de información sobre su estado, actuación e interacción con otros equipos. En general, todos aquellos aspectos que puedan ser relevantes durante la revisión de un equipo, tras un incidente de ciberseguridad.
Se ha de definir dónde se van a almacenar estos registros, qué tipos e información van a recoger y cómo van a etiquetarse con la fecha y tiempo adecuado. También se debería tener en cuenta que se puede requerir la extracción o monitorización de dichos registros, por lo que se recomienda compatibilizar el equipo con tecnologías que lo permitan, como buses de datos o herramientas de monitorización.
Pruebas y verificación
La verificación de las funciones de seguridad, no puede postergarse a la finalización del desarrollo, se deberían definir puntos de prueba periódicos a lo largo de todo el desarrollo.
Un buen punto de partida para definir un plan de pruebas durante el desarrollo es probar las medidas según se van aplicando. Por otro lado, deberían hacerse pruebas para cada una de las amenazas y riesgos identificados durante el desarrollo. Deberían definirse también qué pruebas validan la actuación del producto para cada amenaza modelada durante el análisis de riesgo y ejecutarlas antes del fin del desarrollo.
Otra buena práctica sería la definición de etapas de prueba durante el desarrollo para realizar pruebas y simulacros generales. Estas deberían incluir ejercicios de pentesting y simulacros de ataques reales para obtener una visión completa de la seguridad del producto.
En general, todas las medidas y principios de desarrollo incluidos deberían probarse a lo largo del proceso de desarrollo y una vez finalizado este. Para definir qué pruebas hay que realizar para cada una, es recomendable acudir a herramientas reconocidas, como la base de datos de Mitre ATT&CK , que pueden informar de las técnicas de ataques contra las que las medidas deberían ser eficaces.
Conclusiones
En general, a la hora de crear nuevos equipos industriales, es una buena idea pensar en ellos como elementos individuales que, en la medida de lo posible, deben ser capaces de protegerse por sí mismos.
Tradicionalmente los usuarios industriales, en el mejor de los casos, confiaban en medidas de seguridad a nivel de red; mientras que, en los peores, la ciberseguridad no se consideraba relevante. Sin embargo, a medida que los atacantes ganan conocimiento y experiencia a la hora de afectar entornos industriales y, en respuesta, las regulaciones se vuelven más exigentes; considerar la seguridad a nivel de componente para aquellos entornos más exigentes es cada vez más relevante.
Un ejemplo claro de estas exigencias se puede observar en la normativa IEC 62443, donde se dedica un documento completo (IEC62443-4-1) a requisitos de desarrollo seguro.
El desarrollo seguro de equipos industriales es la herramienta más eficaz para hacer frente a estas nuevas necesidades. Asegurar que los equipos son seguros desde el inicio y durante todo su ciclo de vida útil, garantiza un mayor nivel de seguridad con un mínimo gasto de recursos y pérdidas de eficiencia.
