Machine Translated by Google

I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018) 121–131

ANÁLISIS DEL SOFTWARE DINÁMICO EXISTENTE

ACTUALIZACIÓN DE TÉCNICAS PARA UNA SEGURIDAD Y PROTECCIÓN
SISTEMAS DE CONTROL INDUSTRIALES

IMANOL MUGARZA1, JORGE PARRA1 & EDUARDO JACOB2

1 Centro de Investigación Tecnológica IK4­Ikerlan, Área de Sistemas Embebidos Confiables.
2
Facultad de Ingeniería, Universidad del País Vasco UPV/EHU.

ABSTRACTO
La tendencia actual de automatización, también conocida como Internet Industrial de las Cosas (IIoT), prevé una mayor
interconectividad entre dispositivos, máquinas, la nube y humanos. Estos sistemas de control industrial, que pueden requerir alta
disponibilidad y/o capacidades relacionadas con la seguridad, ya no están aislados del entorno corporativo o de Internet. Se
necesitarán actualizaciones de software durante el ciclo de vida del producto, debido a la larga vida útil, el creciente número de
vulnerabilidades relacionadas con la seguridad descubiertas en estos sistemas de control industrial y la alta interconectividad
deseada en IIoT. Estas actualizaciones tienen como objetivo corregir todas estas debilidades, errores y vulnerabilidades de seguridad
que puedan aparecer, mientras se garantizan los niveles de integridad de seguridad requeridos. La comunidad de ingenieros de
seguridad acaba de abordar las preocupaciones relacionadas con la seguridad, debido al creciente número de ataques cibernéticos
contra sistemas críticos para la seguridad, como Stuxnet. Además, los apagados del sistema provocados por actualizaciones de
software podrían no ser plausibles cuando se requiere alta disponibilidad. Normalmente, para realizar la actualización de software,
se detiene todo el proceso industrial o la producción, para que la actualización de software se aplique de forma segura.

Sin embargo, este escenario podría no aplicarse en infraestructuras críticas, como centrales nucleares o hidroeléctricas, donde
estas interrupciones de producción y servicio no son aceptables desde el punto de vista empresarial y de servicio. Este artículo
presenta un análisis de las técnicas de actualización dinámica de software existentes, que pueden aplicarse para sistemas de control
industrial seguros. Estas técnicas tienen como objetivo actualizar el código en ejecución, sin necesidad de detenerlo y reiniciarlo,
aumentando la disponibilidad del sistema industrial.

Palabras clave: actualizaciones dinámicas de software, parches, seguridad, protección, infraestructuras críticas.

1. INTRODUCCIÓN
En la actual tendencia de automatización, también llamada Internet Industrial de las Cosas (IIoT), se requiere una
alta interconectividad. Sensores, actuadores, unidades de procesamiento y personas se conectan entre sí con el
objetivo de concebir un sistema industrial inteligente. Algunas de las funciones de seguridad las llevan a cabo
algunos de los dispositivos, de modo que se evitan accidentes e incidentes que puedan afectar a la salud. Sin
embargo, debido a la alta interconectividad entre estos sistemas de control industrial, las preocupaciones por la
seguridad ganan importancia, especialmente para los sistemas críticos para la seguridad, ya que estos sistemas
ya no están aislados de los canales de comunicación abiertos.
El primer ciberataque importante que comprometió la seguridad y tuvo como objetivo los sistemas de control
industriales fue el virus informático Stuxnet. Fue identificado en 2010 y según Ralph Langen se puede suponer
que el único objetivo era la planta de enriquecimiento de uranio de Natanz en Irán [1]. Este programa malicioso
tenía como objetivo controladores lógicos programables (PLC) de uso general y de alta gama. Debido al creciente
número de ataques cibernéticos contra sistemas críticos para la seguridad, la comunidad de ingenieros de
seguridad ha comenzado a abordar esas amenazas a la seguridad cibernética, que pueden alterar el
funcionamiento adecuado de los sistemas relacionados con la seguridad [2, 3].
En este artículo, primero se describe el planteamiento del problema y luego se proporciona un análisis de las
técnicas de actualización dinámica de software (DSU) existentes aplicables a sistemas industriales. Finalmente
se presenta un caso de estudio sobre sistemas de seguridad de reactores nucleares, donde se reivindica la
necesidad y utilización de técnicas DSU.

© 2018 WIT Prensa, www.witpress.com

ISSN: 2041­9031 (formato papel), ISSN: 2041­904X (en línea), http://www.witpress.com/journals
DOI: 10.2495/SEGURO­V8­N1­121­131
Machine Translated by Google

122 I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018)

2 DECLARACIÓN DEL PROBLEMA

Cada día se descubren nuevos fallos de seguridad. Como informa el laboratorio Kaspersky, el número de
vulnerabilidades en los sistemas de control industrial sigue creciendo. En 2015 se publicaron 189 vulnerabilidades,
donde el 42% de ellas tenían gravedad media y el 49% eran críticas [4]. Asimismo, el número de incidentes de
ciberseguridad reportados por el Equipo de Respuesta a Emergencias Cibernéticas de Sistemas de Control
Industrial (ICS­CERT) ha crecido desde la inauguración del equipo en 2009. La Figura 1 muestra el número total
de incidentes registrados por año, mientras que También se ilustra la cantidad de incidentes reportados en
algunos de los sectores críticos de infraestructura.

Para mantener el nivel de seguridad durante la vida útil del producto, el software dentro del sistema debe
actualizarse periódicamente, al mismo tiempo que se descubren fallas de seguridad.
Sin embargo, un apagado del sistema debido a una actualización de software podría no ser posible cuando se
exige alta disponibilidad. Ejemplos de este tipo de escenarios son una línea de producción compleja y exigente,
una central hidroeléctrica o un sistema de control y protección de un reactor nuclear. En estos casos, detener
los sistemas de control debido a una actualización de software puede comprometer las propiedades de
seguridad del proceso. Este enfoque puede no ser práctico desde la perspectiva empresarial. Además, si el
proceso de apagado no es inmediato, el sistema sigue siendo vulnerable hasta que se alcanza un estado de
apagado seguro. Este es el caso cuando el sistema relacionado con la seguridad necesita mantener activamente
los servicios de seguridad esenciales. Ejemplos de tales escenarios son los sistemas críticos para la seguridad
de aeronaves y reactores nucleares. Estos servicios también se suspenderán en caso de un ciberataque, ya que
la falta de control de procesos puede provocar eventos peligrosos y accidentes.

Figura 1: Incidentes de ciberseguridad reportados en infraestructuras críticas por ICS­CERT.

Machine Translated by Google

I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018) 123

3 ACTUALIZACIÓN DINÁMICA DE SOFTWARE

La Actualización Dinámica de Software (DSU) consiste en actualizar un programa informático
mientras se está ejecutando sin necesidad de detenerlo y reiniciarlo. A menudo se utiliza hardware
redundante como alternativa a este enfoque para modificar un sistema en ejecución sobre la
marcha. Para ello se utiliza una máquina secundaria. Cuando se desea una actualización del
sistema, la nueva versión del código se carga en el sistema secundario y el estado o la información
necesaria se pasa desde el sistema primario. Después de eso, se realiza un cambio de rol entre
estas máquinas, donde la máquina primaria se convierte en secundaria y la secundaria en primaria [5].
La ejecución de un programa de computadora se puede considerar como una tupla ( ,) P, donde P es
código del programa ydpuede
el estado actual
incluir del programa.
el estado mantenidoElpor
estado actualoperativo
el sistema para dd
del programa. el programa P (como
descriptores de archivos o conexiones de red abiertas), el montón, marcos de pila y contadores de programas.
Por el contrario, el código de programa P incluye un conjunto de instrucciones ejecutables por el sistema. El
mecanismo de actualización dinámica del software transforma el programa en ejecución real () P. Para esto,
d el aestado
primero se actualiza el código del programa y luego se transforma real del
una nueva programa
versión . que sea
( ) P′, d′para
coherente con el nuevo código del programa P′ [5, 6]. d d ',

Un proceso dinámico de actualización de software consta de tres aspectos, que son: transformación
de código, transformación de estado y punto de actualización. La transformación de código se refiere al
proceso de actualización del código ejecutable, mientras que la transformación de estado representa el
procedimiento de transformar el estado real del programa, para que sea comprensible para el nuevo
programa. Finalmente, el punto de actualización se refiere a la instancia de ejecución donde ocurre la
actualización del software. También se emplea el término tiempo de actualización, que denota el momento
en el que se realiza la actualización. Ambos se refieren al mismo suceso de ejecución/tiempo. La Figura
2 muestra la línea de tiempo del proceso de actualización de software dinámico:
En caso de que la aplicación sea multiproceso, el proceso se vuelve más desafiante.
En primer lugar, es necesario transformar el código ejecutable y el estado del programa de cada hilo.
En segundo lugar, se requiere que todos los hilos lleguen a un punto de actualización y esperen a los
demás. Sin embargo, la posibilidad de retrasos ilimitados de esos hilos al llegar a un punto de actualización
podría provocar una interrupción del servicio de la aplicación. Además, puede producirse un punto muerto
cuando un subproceso determinado está esperando acceder a un recurso determinado antes de alcanzar
un punto de actualización, mientras que otro ya lo ha alcanzado sin liberar el recurso. En ese caso se
suspendería la aplicación [6, 7].

Figura 2: Cronograma del proceso de actualización dinámica de software.

Machine Translated by Google

124 I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018)

4 ANÁLISIS DE SISTEMAS EXISTENTES

A lo largo de los años, se han propuesto muchos sistemas DSU. Estos sistemas se dirigen a muchos tipos de
aplicaciones, desde fines de control en tiempo real hasta servidores y bases de datos [8, 9]. Además, también
se han propuesto enfoques formales en los que se investiga el soporte de DSU a nivel del lenguaje de
programación. Stoyle [10] presenta una teoría subyacente para los lenguajes de programación que ofrecen
características DSU denominada Proteus . Esta teoría es un programa de cálculo y se aplicó al diseño e
implementación de programas C actualizables. Los desafíos más importantes residen en cómo abordar las
características inseguras del lenguaje de programación C y cómo diseñar una característica DSU eficiente.

Algunos de los lenguajes de programación actuales ya brindan soporte DSU. De Pina [11] analizó cuatro
lenguajes de programación , que son: Common LISP, Smalltalk, Erlang y UpgradeJ. Incluso si estos lenguajes
de programación proporcionan características DSU de alto nivel; el desarrollador debe escribir las aplicaciones
de destino en esos idiomas. En consecuencia, el uso de estos enfoques está restringido para aquellas
aplicaciones desarrolladas desde cero en estos lenguajes. También pueden surgir problemas de incompatibilidad
al integrar bibliotecas ya existentes con la aplicación de destino escrita en dicho lenguaje de programación.

P. Hosek y C. Cadar [12, 13] siguieron otro enfoque . En este caso, aprovechando las tecnologías de
virtualización, la nueva versión del programa se ejecuta en paralelo con la anterior, donde se sincronizan sus
ejecuciones. El objetivo de esta técnica es mantener la estabilidad de la versión anterior mientras también se
ofrecen nuevas funciones y correcciones de errores de la nueva versión. Se implementó un prototipo llamado
MX, donde se ejecutaron varias aplicaciones en modo multiversión. El sistema se compone de tres
componentes principales. El primero es el Static Executable Analyzer (SEA), que realiza un análisis estático en
ambas versiones binarias. El segundo es el Monitor de ejecución múltiple (MXM), donde ambas versiones se
ejecutan simultáneamente. Finalmente, Runtime Execution Manipulator (REM) selecciona entre los
comportamientos disponibles y resincroniza ambas versiones en caso de divergencia.

Normalmente, los sistemas DSU proporcionan un sistema de creación de parches dinámicos que genera un
parche dinámico. Cabe señalar que, como afirma Hicks [5], el concepto de parche dinámico difiere del parche
estático normal (comandos diff y patch en UNIX), donde se describe como las diferencias entre las fuentes de
dos versiones del programa. Un parche dinámico puede consistir en un nuevo código ejecutable actualizado,
nuevas variables globales, transformadores de tipo/estado y metadatos adicionales. Esta información luego se
transfiere al sistema de ejecución de DSU, donde después de recibir una solicitud de DSU, se lleva a cabo el
proceso de DSU [14]. Estos sistemas suelen proporcionar un conjunto de herramientas, como compiladores
personalizados, generadores de parches de fuente a fuente o analizadores de fuente para crear parches
dinámicos. Comúnmente se utilizan herramientas de compilación, análisis de código fuente y transformación
CIL [15] y LLVM [16] [11].
Para generar un parche dinámico, el sistema de creación de parches dinámicos debe realizar varias tareas
[5, 11]. Estas actividades a menudo son supervisadas y/o ayudadas por el desarrollador. Estas tareas son:

1. Identificación y comparación sintáctica de la nueva versión del programa con la antigua.

unos).
2. Adaptación del programa (fuente y/u objeto) para que sea actualizable.
3. Construya las funciones del transformador de tipo/estado (siempre que sea posible).
4. Generación de metadatos DSU, donde se detalla la información sobre la versión actual del programa.
multado.
Machine Translated by Google

I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018) 125

Ya se ha proporcionado una revisión de técnicas, métricas de evaluación y un estudio de los sistemas DSU
existentes [8, 9]. Estos sistemas se clasifican según las técnicas y atributos de transformación de código,
transformación de estado y puntos de actualización utilizados o caracterizados. Los mecanismos del ESD también
se evalúan y discuten en comparación con las métricas de evaluación definidas. En esta sección, se analizan los
sistemas DSU que podrían ser factibles para aplicaciones de control industrial seguras. Se han dividido en tres
categorías, como lo hicieron de manera similar De Pina [11] y Seifzadeh et al. [8], que son:

• Sistemas DSU compilados orientados a aplicaciones que apuntan a aplicaciones compiladas en un binario
ejecutable. Luego, estos objetos se ejecutan de forma nativa.
• Sistemas DSU orientados al kernel que apuntan al núcleo de un sistema operativo.
• Sistemas DSU orientados en tiempo real , que han sido creados específicamente para em­
sistemas de control industriales o de cama.

En el análisis realizado sobre las técnicas DSU por de Pina [11], los grupos de aplicación compilada y kernel se
fusionaron en uno solo, ya que el núcleo de un sistema operativo puede considerarse una aplicación compilada de
propósito especial. Normalmente se utiliza el lenguaje de programación C para este fin. Este lenguaje de
programación generalmente también se considera en sistemas DSU compilados orientados a aplicaciones. La
siguiente Tabla 1 presenta los sistemas DSU analizados. Tenga en cuenta que los sistemas DSU no están
ordenados según la fecha dentro de cada categoría.
Una disposición similar utilizada por De Pina [11] y Seifzadeh et al. [8] ha sido empleado.

Tabla 1: Sistemas DSU analizados.

Nombre Objetivo Fecha

dpop 2001

Dynsec 2005
MEDIO 2013

DynSec 2007
Solicitud compilada 2009
mirando hacia arriba

Ginseng 2008
Ekiden 2011
Kitsune 2012
lucos 2006

DinAMOS 2007
Núcleo 2009
KSplice
K42 2006
PROTEOS 2013
DURTOS 2004
InsertarDSU 2011
Gracioli 2014
EcoDSU Tiempo real 2008
Seif­real 2009
votantes 2009
FASE 2014
Machine Translated by Google

126 I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018)

Al momento de escribir este artículo, y hasta donde sabemos, KSplice y sus sucesores, los mecanismos
KPatch y KGraft, son solo los sistemas DSU, que se aplican y se ofrecen comercialmente para el kernel de
Linux. Los servicios de parcheo en vivo son proporcionados a través de estas técnicas, respectivamente, por
Oracle Linux Premier Support, Red Hat y SUSE. El sistema livepatch fue creado en 2014 por Red Hat,
unificando los enfoques KGraft y KPatch, que en realidad está disponible en el kernel principal. En estos
sistemas DSU, sólo se realizan transformaciones de código a nivel de función [17].

Todos los sistemas DSU destinados a aplicaciones compiladas realizan actualizaciones dinámicas sobre
un sistema operativo tipo UNIX, generalmente GNU/Linux que se ejecuta en una computadora x86. Además,
UpStare se ha probado en Linux 2.4–2.6 ejecutándose en una computadora con arquitectura i386, Solaris
5.10 ejecutándose en una computadora SPARC y MAC OSX ejecutándose en una computadora PowerPC
[6, 18, 19]. Sin embargo, ninguno de estos sistemas DSU proporciona funciones en tiempo real, que pueden
ser necesarias para una aplicación de control industrial. Excepto DynSec, todos los sistemas DSU dirigidos
a aplicaciones compiladas presentan una cadena de herramientas dinámica de creación de parches. En el
caso de sistemas DSU diseñados para núcleos de sistema operativo, LUCOS [20], DynAMOS [21] y KSplice [17, 22]
(y sus sucesores KGraph y KPatch) apuntan al kernel de Linux, mientras que K42 es el kernel del sistema
operativo en sí, diseñado para proporcionar personalización, escalabilidad y mantenibilidad [23–
26]. PROTEOS [27, 28] está diseñado para el sistema operativo MINIX 3, que es compatible con la interfaz
POSIX [29]. En este sistema DSU, donde se realizan actualizaciones a nivel de proceso, se proporcionan
transferencias de estado automáticas. PROTEOS se ejecuta en computadoras x86 y según el autor, la
técnica propuesta se puede aplicar fácilmente a otros sistemas operativos, por ejemplo: L4, Integrity o QNX.

DURTS [30] es la única DSU en tiempo real dirigida a un sistema operativo tipo UNIX, específicamente,
el sistema operativo RT­Mach. Se utilizaron otros sistemas operativos específicos en EmbedDSU [31] y
Gracioli [32]. Mientras que EcoDSU [33] funciona exclusivamente sobre metal, sin el soporte de un sistema
operativo, Wahler [34] y FASA (Future Automation System Architecture) [35–38] son independientes del
sistema operativo. Esto significa que se puede utilizar cualquier sistema operativo. Sin embargo, deberán ser
compatibles con POSIX.
Ninguno de los sistemas DSU analizados proporciona una solución que cumpla con las normas de
seguridad. Como afirman Wahler et al. [39], el mayor desafío para actualizar el software de los sistemas en
tiempo real es que a menudo necesitan estar certificados de acuerdo con estándares como el IEC 61508
[40]. Si se actualiza el software de dicho sistema, el sistema en su totalidad debe volver a certificarse antes
de poder usarse en el campo. La mayoría de los sistemas DSU realizan actualizaciones de software sobre
sistemas operativos tipo UNIX, lo que no se recomienda para sistemas relacionados con la seguridad, incluso
si existen iniciativas para evaluar y valorar el kernel de Linux según los estándares de seguridad [41, 42].
Los sistemas Wahler, FASA y PROTEOS son las soluciones propuestas más cercanas a una técnica
DSU compatible con la seguridad, ya que, según afirman los autores, las técnicas descritas son compatibles
con cualquier sistema operativo compatible con POSIX, donde se podría elegir uno certificado en seguridad.
En el caso de PROTEOS, es necesario modificar el núcleo del sistema operativo. En consecuencia, después
de los cambios, deberá ser recertificado. Sin embargo, Wahler y FASA aprovechan las utilidades del sistema
operativo, por lo que la DSU es transparente para el sistema operativo subyacente. A continuación se
certificarán la aplicación, las bibliotecas y el mecanismo de actualización dinámica que se ejecuta sobre el
sistema operativo.
Uno de los requisitos para la evaluación de la seguridad es el análisis de programabilidad, donde se
garantiza que las tareas se ejecuten y completen de acuerdo con sus requisitos de tiempo. Esta propiedad
fue examinada desde la perspectiva del ESD en DURTS [30] y Seif­Real [43]. Solo la idea principal se
presentó en Seif­Real, sin especificar ninguno de los aspectos de transformación de código, transformación
de estado y punto de actualización .
Machine Translated by Google

I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018) 127

5 ESTUDIO DE CASO

En 2010, el virus Stuxnet demostró que las instalaciones nucleares también están expuestas a amenazas a la ciberseguridad [44]. Como se

muestra en la figura 1, el año pasado el Equipo de Respuesta a Emergencias Cibernéticas de Sistemas de Control Industrial (ICS­CERT)

registró un notorio aumento de incidentes de ciberseguridad en el sector nuclear (de 7 a 63). Así, debido al creciente número de

vulnerabilidades en los sistemas de control industrial y a la larga vida operativa de estas instalaciones, son necesarias actualizaciones de

software, con las que se solucionan los puntos débiles, bugs y vulnerabilidades de seguridad. En este estudio de caso, los sistemas de

seguridad de reactores nucleares se evalúan en lo que respecta a las actualizaciones de software de seguridad. Afirmamos que debido a la

complejidad y criticidad de los procesos nucleares, las actualizaciones dinámicas de software son necesarias.

5.1 Sistemas de seguridad de los reactores nucleares

Cuando se detecte un comportamiento anómalo o condiciones inseguras del reactor, el Sistema de Protección del Reactor (SPR) efectuará

una parada de emergencia. A continuación se rompe la cadena de reacción nuclear mediante la inserción de barras de control. En caso de

falla del RPS, se utiliza un mecanismo de apagado secundario, como la inyección de boro. En este punto, aunque el reactor nuclear esté

apagado, todavía se produce calor de desintegración como efecto de la radiación [45]. En el momento en que se apaga el reactor, el calor de

desintegración es aproximadamente el 6,5% de la potencia del reactor anterior, suponiendo que se haya logrado un historial de energía largo

y estable. La siguiente Fig. 3 muestra la disminución del calor de desintegración después de un año de funcionamiento del reactor desde el

momento en que fue desmantelado [46].

Aunque el reactor nuclear esté parado, debido al calor de desintegración, es necesario llevar a cabo funciones de seguridad esenciales

para enfriar el reactor. Si no se elimina el calor de desintegración, se pueden alcanzar condiciones inseguras en el reactor, lo que podría
provocar un desastre nuclear [44, 45]. Por ejemplo, se produjo una fusión parcial de la unidad 2 en Three­Mile Island después del cierre del

reactor debido a fallas en el equipo y fallas del operador. Por el contrario, en Fukushima, incluso después del terremoto se apagaron los

reactores, el tsunami incapacitó todas las operaciones de emergencia.

Figura 3: Calor de desintegración del reactor nuclear después de 12 meses de funcionamiento

Machine Translated by Google

128 I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018)

Generadores de suministro de energía necesarios para los sistemas de refrigeración del reactor. En consecuencia, las
Unidades 1, 2 y 3 se fusionaron [47].

5.2 Actualizaciones de seguridad

Si se descubren debilidades de seguridad, errores o vulnerabilidades en los sistemas de seguridad del reactor, se
debe tomar la decisión de actualizar o no el equipo afectado. Por un lado, si se decide actualizar el sistema de
protección, primero se debe detener todo el proceso nuclear, para que la actualización del software se aplique de
forma segura. Esto quizá no sea concebible desde el punto de vista empresarial y de servicios. Por el contrario, el nivel
de integridad de la seguridad se vería comprometido si la actualización se aplica mientras el reactor nuclear está en
funcionamiento, porque se requiere el apagado del sistema de seguridad. Por otro lado, si se toma la decisión de no
actualizar el sistema, el sistema seguiría siendo atacable. Como el sistema ya no es seguro, tampoco lo es. Por tanto,
el único enfoque que no compromete la seguridad es detener todo el proceso, lo que puede no ser aceptable desde la
perspectiva del servicio y del negocio. Tenga en cuenta que los reactores nucleares suelen funcionar sin interrupción
durante uno o dos años una vez que se asigna el combustible.

El escenario empeora en caso de que se detecte un ciberataque mientras los sistemas de seguridad del reactor
siguen siendo vulnerables. Si el ciberataque compromete los sistemas de protección de los reactores, un accidente
nuclear podría ser inevitable. En el supuesto de que el ataque se identifique a tiempo o se detecten anomalías
provocadas, el reactor nuclear sería apagado gracias a los sistemas de protección del reactor. Para evitar cualquier
tipo de infección de software u otras consecuencias similares, estos sistemas también podrían detenerse
posteriormente. Sin embargo, incluso si el reactor nuclear está parado, otros sistemas de seguridad deberán mantener
los servicios esenciales, como la refrigeración del reactor o el suministro de energía de respaldo. Estos sistemas de
seguridad quedan entonces totalmente a merced del ciberataque, ya que es necesario un funcionamiento adecuado
de estos sistemas para tener bajo control el reactor. Sin control, un desastre nuclear podría ser inminente. Los
atacantes también podrían destruir deliberadamente estos sistemas críticos para la seguridad. Sólo aquellos sistemas
habilitados con funciones de actualización dinámica podrían actualizarse in situ, de modo que se pudieran mitigar las
consecuencias del ciberataque. Estas técnicas brindan la posibilidad de resolver estos problemas de ciberseguridad
sin la interrupción del servicio y las propiedades de seguridad.

6. CONCLUSIONES

Debido al creciente número de vulnerabilidades en los sistemas de control industrial, se necesitan actualizaciones de
software. Sin embargo, un apagado del sistema debido a una actualización de software no es aceptable para aquellas
aplicaciones en las que no se requiere tiempo de inactividad, por ejemplo sistemas aeronáuticos, hidroeléctricos o
nucleares críticos para la seguridad. En este artículo, se ofrece un análisis de las técnicas de actualización dinámica
de software existentes para sistemas de control industrial seguros. Estos mecanismos tienen como objetivo actualizar
el programa en ejecución mientras se ejecuta sin necesidad de detenerlo y reiniciarlo.
Como afirman Wahler et al. [39], el software dentro de los sistemas críticos para la seguridad generalmente debe
estar certificado de acuerdo con estándares de seguridad. También se requiere un alto nivel de confianza en la
seguridad para el desarrollo de software y las herramientas de soporte. Hasta donde sabemos, no existe ningún
mecanismo DSU aplicable que cumpla con las normas de seguridad, pero los sistemas Wahler, FASA y PROTEOS
son las soluciones propuestas más cercanas a una que cumpla con las normas de seguridad. Sin embargo, es
necesario seguir trabajando, especialmente para garantizar y validar la integridad y corrección de esas actualizaciones
de software. En consecuencia, al momento de escribir este artículo, el único método para actualizar sobre la marcha
los sistemas críticos para la seguridad es la redundancia.
Machine Translated by Google

I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018) 129

REFERENCIAS
[1] Langner, R., Stuxnet: Diseccionando un arma de guerra cibernética. Privacidad de seguridad de IEEE, 9(3),
págs. 49–51, 2011.
https://doi.org/10.1109/msp.2011.67
[2] Paul, S. & Rioux, L., Más de 20 años de investigación en ciberseguridad e ingeniería de seguridad: una breve
bibliografía. Ingeniería de Seguridad y Vigilancia VI.
https://doi.org/10.2495/safe150291
[3] Paul, S., Sobre el significado de seguridad para la seguridad (S4S). Transacciones WIT sobre el entorno
construido, 151, págs. 379–389, 2015.
[4] KS Intelligence, “Panorama de amenazas a la ciberseguridad industrial”, ed, 2016.
[5] Hicks, M., Moore, JT & Nettles, S., Actualización dinámica de software. MCA, 36(5),
págs. 13 a 23, 2001.
[6] Makris, K., Actualización dinámica de software de todo el programa. Universidad Estatal de Arizona, Tempe, AZ,
2009.
[7] Hayden, CM, Actualizaciones de software dinámicas claras, correctas y eficientes, 2012.
[8] Seifzadeh, H., Abolhassani, H. y Moshkenani, MS, Un estudio sobre la actualización dinámica de software.
Journal of Software: Evolution and Process, 25(5), págs. 535–568, 2013. https://doi.org/10.1002/
smr.1556
[9] Miedes, E. & Muñoz­Escoi, FD, Actualización de software dinámica, Informe técnico ITI­
SIDI­2012/0042012.
[10] Stoyle, G., Una teoría de las actualizaciones dinámicas de software, 2007.
[11] de Pina, LGG, Actualización práctica de software dinámico. INSTITUTO SUPERIOR TECNICO, Lisboa, Portugal,
2016.
[12] Cadar, C. y Hosek, P., Actualizaciones de software de versiones múltiples. En Actas del Cuarto Taller
Internacional sobre Temas Candentes en Actualizaciones de Software, págs. 36–40, 2012.
[13] Hosek, P. y Cadar, C., Actualizaciones de software seguras mediante ejecución de múltiples versiones. Actas de
la Conferencia Internacional sobre Ingeniería de Software de 2013, págs. 612–621, 2013.
[14] Neamtiu, I., Hicks, M., Stoyle, G. y Oriol, M., Actualización práctica de software dinámico para C. Actas de la 27ª
Conferencia ACM SIGPLAN sobre diseño e implementación de lenguajes de programación, Nueva York, NY,
págs. (72–83, 2006).
[15] Necula, GC, McPeak, S., Rahul, SP & Weimer, W., CIL: Lenguaje intermedio y herramientas para el análisis y
transformación de programas en C. Conferencia internacional sobre construcción de compiladores, págs.
213–228, 2002.
[16] Lattner, C. & Adve, V., LLVM: Un marco de compilación para el análisis y la transformación de programas de por
vida. Actas del Simposio internacional sobre generación y optimización de código: optimización en tiempo de
ejecución y dirigida por comentarios, p. 75, 2004.
[17] Binnie, C., Linux con tiempo de inactividad cero. En temas prácticos de Linux: Springer, págs. 33–39, 2016.
[18] Makris, K. y Bazzi, RA, Actualizaciones inmediatas de software dinámicas de subprocesos múltiples mediante
reconstrucción de pila. Conferencia técnica anual de USENIX, San Diego, CA, 2009.
[19] Makris, K., manual Upstare”, ed, 2012.
[20] Chen, H., Chen, R., Zhang, F., Zang, B. & Yew, P.­C., Actualización en vivo de sistemas operativos mediante
virtualización. Actas de la segunda conferencia internacional sobre entornos de ejecución virtual, Ottawa,
Ontario, págs. 35–44, 2006.
[21] Makris, K. & Ryu, KD, Actualizaciones dinámicas y adaptativas de subsistemas no inactivos en núcleos de
sistemas operativos básicos. Revisión de los sistemas operativos ACM SIGOPS, 41 (3), págs. 327–340, 2007.

https://doi.org/10.1145/1272998.1273031
Machine Translated by Google

130 I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018)

[22] Arnold, J. & Kaashoek, MF, Ksplice: Actualizaciones automáticas del kernel sin reinicio. Actas de la
cuarta conferencia europea ACM sobre sistemas informáticos, Nuremberg, Alemania, págs. 187­198,
2009.
[23] Krieger, O., Mergen, M., Waterland, A., Uhlig, V., Auslander, M., Rosenburg, B., Wisniewski, RW,
Xenidis, J., Da Silva, D., Ostrowski, M., Appavoo, J. & Butrico, M., K42: Construcción de un sistema
operativo completo. Revisión de los sistemas operativos ACM SIGOPS, 40 (4), págs. 133–145, 2006.

https://doi.org/10.1145/1218063.1217949
[24] Baumann, A., Appavoo, J., Da Silva, D., Krieger, O. y Wisniewski, RW, Mejora de la disponibilidad del
sistema operativo con actualización dinámica. Actas del primer taller sobre sistemas operativos y
soporte arquitectónico para la infraestructura de TI bajo demanda, Boston, MA, págs. 21 a 27, 2004.

[25] Baumann, A., Actualización dinámica para sistemas operativos. Doctor en Filosofía, Facultad de
Ingeniería y Ciencias de la Computación, Universidad de Nueva Gales del Sur, vol. 112, 2007.
[26] Baumann, A., et al., Proporcionar actualización dinámica en un sistema operativo. Conferencia técnica
anual de USENIX, vía general, págs. 279–291, 2005.
[27] Giuffrida, C., Kuijsten, A. y Tanenbaum, AS, Actualización en vivo segura y automática para sistemas
operativos. Noticias de arquitectura informática de ACM SIGARCH, 41, págs. 279–292, 2013.
https://doi.org/10.1145/2499368.2451147
[28] Giuffrida, C. y otros, Actualización en vivo segura y automática. Universidad VU de Ámsterdam,
2014.
[29] Tanenbaum, AS y Woodhull, AS, Diseño e implementación de sistemas operativos,
3.ª ed., Prentice­Hall, Inc.: Upper Saddle River, Nueva Jersey, 2005.
[30] Montgomery, J., Un modelo para actualizar aplicaciones en tiempo real. sistemas en tiempo real,
27 (2), págs. 169–189, 2004.
https://doi.org/10.1023/b:time.0000027932.11280.3c
[31] Noubissi, AC, Iguchi­Cartigny, J. & Lanet, JL., Actualizaciones en caliente para tarjetas inteligentes
basadas en Java. Talleres de ingeniería de datos (ICDEW), 27ª Conferencia Internacional IEEE de
2011, págs. 168­173, 2011.
[32] Gracioli, G. & Fröhlich, AA, Una infraestructura de sistema operativo para actualización remota de
código en sistemas profundamente integrados. Actas del primer taller internacional sobre temas
candentes en actualizaciones de software, Nueva York, NY, 2008, pág. 3.
[33] Kang, S., Chun, I. y Kim, W., Actualización dinámica de software para sistemas ciberfísicos. El 18.º
Simposio internacional del IEEE sobre electrónica de consumo (ISCE 2014), págs. 1–3, 2014.

[34] Wahler, M., Richter, S. y Oriol, M., Actualizaciones de software dinámicas para sistemas en tiempo real.
Actas del segundo taller internacional sobre temas candentes en actualizaciones de software, Orlando,
FL, pág. 2, 2009.
[35] M. Oriol, Wahler, M., Steiger, R., Stoeter, S., Vardar, E., Koziolek, H. & Kumar, A., FASA: un marco de
software escalable para sistemas de control distribuido. Actas del tercer simposio internacional ACM
SIGSOFT sobre arquitectura de sistemas críticos, págs. 51–60, 2012.

[36] Wahler, M., Oriol, M. & Monot, A., Componentes multinúcleo en tiempo real para sistemas ciberfísicos.
2015 18.º Simposio internacional ACM SIGSOFT sobre ingeniería de software basada en
componentes (CBSE), págs. 37–42, 2015.
Machine Translated by Google

I. Mugarza, et al., Int. J. de Seguridad y Vigilancia Eng., vol. 8, núm. 1 (2018) 131

[37] Monot, A., Oriol, M., Schneider, C. y Wahler, M., Arquitectura de software moderna para dispositivos
integrados en tiempo real: alto valor, pocos gastos generales. 2016 13.ª Conferencia de trabajo IEEE/
IFIP sobre arquitectura de software (WICSA), págs. 201–210, 2016.
[38] Wahler, M., Gamer, T., Kumar, A. y Oriol, M., FASA: Una arquitectura de software y un marco de tiempo
de ejecución para sistemas de automatización distribuidos flexibles. Journal of Systems Archi­tecture,
61 (2), págs. 82­111, 2015.
https://doi.org/10.1016/j.sysarc.2015.01.002
[39] Wahler, M., Richter, S., Kumar, S. y Oriol, M., Actualizaciones de componentes a gran escala no
disruptivas para controladores en tiempo real. Talleres de ingeniería de datos (ICDEW), 27ª Conferencia
Internacional del IEEE de 2011, págs. 174­178, 2011.
[40] Comisión IE y otros, “Seguridad funcional de sistemas eléctricos/electrónicos/electrónicos programables
relacionados con la seguridad”, IEC 61508, 2000.
[41] Pierce, RH, Evaluación preliminar de Linux para sistemas relacionados con la seguridad. libros de HSE,
2002.
[42] Mc Guire, N., Linux para sistemas críticos de seguridad en el contexto IEC 61508. Procedimientos de
el Noveno Taller de Linux en Tiempo Real en Linz, 2007.
[43] Seifzadeh, H., Kazem, AAP, Kargahi, M. y Movaghar, A., Un método para la actualización dinámica de
software en sistemas en tiempo real. 2009 Octava Conferencia Internacional IEEE/ACIS sobre
Informática y Ciencias de la Información, págs. 34–38, 2009.
[44] Kesler, B., La vulnerabilidad de las instalaciones nucleares al ciberataque. Perspectivas estratégicas, 10
(1), págs. 15 a 25, 2011.
[45] Thomson, J., Sistemas de alta integridad y gestión de seguridad en industrias peligrosas.
Butterworth­Heinemann, 2015.
[46] Garland, WJ, Estimaciones de calor de descomposición para MNR. Reactor nuclear McMaster, McMaster
Universidad, Ontario, 1999.
[47] Holt, M., Campbell, RJ y Nikitin, MB, Desastre nuclear de Fukushima. Servicio de Investigación del
Congreso, 2012.