Traducido del inglés al español - www.onlinedoctranslator.

com

Recibido el 22 de julio de 2019, aceptado el 22 de agosto de 2019, fecha de publicación 9 de septiembre de 2019, fecha de la versión actual 3 de octubre de 2019.

Identificador de objeto digital 10.1109/ACCESS.2019.2940039

Un enfoque sistemático para el modelado de

amenazas y el análisis de seguridad para redes
definidas por software

TAEHOON EOM1, JIN B. HONG2, SEONGMO AN1, PARQUE JONG SOU1, Y

DONG SEONG KIM3
1Departamento de Ingeniería Informática, Universidad Aeroespacial de Corea, Goyang 10540, Corea del Sur
2Departamento de Ciencias de la Computación e Ingeniería de Software, Universidad de Australia Occidental, Perth, WA 6907, Australia
3Escuela de Tecnología de la Información e Ingeniería Eléctrica, Universidad de Queensland, Brisbane, QLD 4072, Australia

Autor para correspondencia: Taehoon Eom ( eomth86@kau.ac.kr )

RESUMENLas redes definidas por software (SDN) amplían las capacidades de las redes existentes al proporcionar diversas funcionalidades, como controles de red flexibles. Sin

embargo, existen muchos vectores de amenazas a la seguridad en SDN, incluidos los existentes y emergentes que surgen de nuevas funcionalidades, que pueden dificultar el uso de

SDN. Para abordar este problema, se han desarrollado muchas contramedidas para mitigar varias amenazas que enfrenta SDN. Sin embargo, su efectividad debe analizarse y

compararse para comprender completamente cómo cambia la postura de seguridad de SDN cuando se adopta la contramedida. Además, se vuelve difícil optimizar la seguridad de

SDN sin utilizar un enfoque sistemático para evaluar la postura de seguridad de SDN. En este documento, proponemos un marco novedoso para modelar y analizar sistemáticamente

la postura de seguridad de SDN. Desarrollamos un formalismo de modelo de seguridad gráfico novedoso llamado Modelo de representación de ataque jerárquico de vector de

amenaza (TV-HARM), que proporciona un enfoque sistemático para evaluar amenazas, ataques y contramedidas para SDN. TV-HARM captura diferentes amenazas y sus

combinaciones, lo que permite la evaluación de riesgos de seguridad de SDN. Además, definimos tres nuevas métricas de seguridad para representar la seguridad de SDN. Nuestros

resultados experimentales mostraron que el marco de evaluación de seguridad propuesto puede capturar y evaluar varias amenazas de seguridad para SDN, lo que demuestra la

aplicabilidad y viabilidad del marco propuesto. permitiendo la evaluación de riesgos de seguridad de SDN. Además, definimos tres nuevas métricas de seguridad para representar la

seguridad de SDN. Nuestros resultados experimentales mostraron que el marco de evaluación de seguridad propuesto puede capturar y evaluar varias amenazas de seguridad para

SDN, lo que demuestra la aplicabilidad y viabilidad del marco propuesto. permitiendo la evaluación de riesgos de seguridad de SDN. Además, definimos tres nuevas métricas de

seguridad para representar la seguridad de SDN. Nuestros resultados experimentales mostraron que el marco de evaluación de seguridad propuesto puede capturar y evaluar varias

amenazas de seguridad para SDN, lo que demuestra la aplicabilidad y viabilidad del marco propuesto.

TÉRMINOS DEL ÍNDICEGráficos de ataque, modelos gráficos de seguridad, análisis de seguridad, redes definidas por software.

I. INTRODUCCIÓN liet al.[6] usó las características de OpenFlow usando

Las redes definidas por software (SDN) son una de las tecnologías de
red emergentes, que permiten a los administradores de sistemas
modificar las configuraciones de red en tiempo real para realizar
varias funcionalidades de optimización de red (p. ej., optimizar el
rendimiento de la red a través del equilibrio de carga [1]). Estas
nuevas funcionalidades permiten una gestión y un control de la red
más eficientes sin interrumpir las operaciones de la red. Debido a
esto, se ha utilizado como la nueva arquitectura de red para
aplicaciones prometedoras como la computación perimetral móvil,
redes rápidas e Internet táctil [2]–[4]. Por ejemplo, Wuet al.[5]
propuso un esquema de extensión de la vida útil de la teoría del
juego para Cyber-Physical Systems (CPS) basado en SDN y Network
Function Virtualization (NFV). Además,
El editor asociado que coordinó la revisión de este manuscrito y lo
aprobó para su publicación fue Vaibhav Rastogi.
dispositivos de borde con protocolo SDN. Sin embargo, si ocurre
un problema de seguridad en SDN, puede tener un impacto
catastrófico en esas aplicaciones prometedoras y otros sistemas
que dependen de las operaciones de SDN.
Desafortunadamente, SDN introduce nuevos vectores de
amenazas que deben tenerse en cuenta para una evaluación de
riesgos de seguridad en profundidad [7]. Por ejemplo, hay
nuevos tipos de componentes de red en SDN (por ejemplo, el
controlador SDN) para admitir las nuevas funcionalidades de
red. Como resultado, pueden existir vulnerabilidades que
pueden no haber sido consideradas en los métodos de
evaluación de seguridad tradicionales (es decir, la incapacidad
de capturar las propiedades de seguridad de los nuevos
componentes de red de SDN). Como resultado, se han realizado
varios trabajos para mejorar la seguridad de SDN [8]–[10]. Sin
embargo,

137432 Este trabajo tiene una licencia Creative Commons Attribution 4.0 License. Para obtener más información, consulte http://creativecommons.org/licenses/by/4.0/ VOLUMEN 7, 2019
T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad
Nuestra principal motivación es proponer un marco novedoso de
modelado de amenazas y análisis de riesgos de seguridad para SDN. En
el entorno SDN, a diferencia de la red existente, existe un controlador
SDN. Los controladores SDN tienen vulnerabilidades en las aplicaciones y
protocolos de comunicación SDN, donde las redes tradicionales no tienen
tales componentes. Un atacante puede realizar escuchas o lanzar un
ataque de escalada de privilegios. En tales casos, esas nuevas
vulnerabilidades deben considerarse el análisis de riesgos de seguridad
que los métodos tradicionales de evaluación de la seguridad pueden no
ser capaces de capturar y analizar.
Un enfoque sistemático aprovecha el poder de los modelos gráficos de
seguridad [11], [12] para evaluar la postura de seguridad y comparar la
efectividad de diferentes mecanismos de defensa. Aunque la seguridad
de SDN se ha estudiado anteriormente, los estudios existentes utilizaron
dispositivos SDN y sus atributos (por ejemplo, vulnerabilidad) para
evaluar la postura de seguridad de SDN. Hasta donde sabemos, ningún
trabajo anterior utilizó modelos gráficos de seguridad para hacer frente a
los vectores de amenazas existentes en SDN. El análisis de riesgos de
seguridad a través de los modelos gráficos de seguridad incorpora las
complejas relaciones entre las vulnerabilidades en SDN. Esto se puede
usar para evaluar los cambios en la superficie de ataque y formular la
contramedida más efectiva para implementar en entornos SDN. En este
escrito, primero, Proponemos un nuevo marco de análisis de riesgos de
seguridad para SDN mediante la incorporación de varios vectores de
amenazas. En segundo lugar, desarrollamos un nuevo modelo de
seguridad gráfica llamadovector de amenazaHARM (TV-HARM) que
amplía las capacidades de los modelos de representación de ataques
jerárquicos (HARM) [13]. TV-HARM perform puede (1) capturar cambios
dinámicos de SDN, (2) evaluar escenarios complejos de ataque y defensa,
y (3) representar la postura de seguridad utilizando varias métricas de
seguridad en SDN.
Las contribuciones de nuestro trabajo se resumen de la siguiente manera:
• Proponemos un nuevo marco de evaluación de riesgos de seguridad que
tiene en cuenta los vectores de amenazas nuevos y existentes en SDN;
• Desarrollamos un nuevo modelo gráfico de seguridad llamado
''vector de amenazaHARM (TV-HARM)'' que puede analizar
vectores de amenazas existentes y emergentes en SDN, que
incluye,
– (1) capturar cambios dinámicos de SDN;
– (2) evaluar escenarios complejos de ataque y defensa;
– (3) representar la postura de seguridad usando varias
métricas de seguridad en SDN.
• Evaluamos la seguridad de SDN utilizando tres métricas de
evaluación de seguridad que incluyen medidas de centralidad de
red, puntajes de vulnerabilidad y métricas de impacto de ataque;
• Demostramos la aplicabilidad y viabilidad de nuestro enfoque
propuesto a través del análisis experimental.
El resto del documento está organizado de la siguiente manera.
SecciónYo presenta los antecedentes y el trabajo relacionado con la
seguridad SDN. Secciónterceropresenta nuestro marco de evaluación de
riesgos de seguridad propuesto para SDN, incluido el modelado y análisis
de seguridad de SDN utilizando TV-HARM. Los experimentos y sus
resultados se presentan en la SecciónIV. Discutimos nuestros hallazgos y
las limitaciones en la SecciónV, y finalmente, concluimos nuestro artículo
en la SecciónVI.
VOLUMEN 7, 2019
II. TRABAJO RELACIONADO
A. SEGURIDAD DE LA APLICACIÓN OPENFLOW
guíaet al.[14] desarrolló un sistema operativo de red llamadoNOX
utilizando el conmutador OpenFlow. Sin embargo, el enfoque de la
investigación estaba en el rendimiento más que en la seguridad.
Casadoet al.[15] introducidoCUERDOpara controlar el flujo en el
servidor central para proteger la red empresarial. Aunque no utilizan
un interruptor OpenFlow o el controlador SDN, el comportamiento
deCUERDOes similar a SDN. El trabajo no consideró todos los
vectores de amenazas SDN. losFlujoNACes una solución para
administrar la red mediante la autorización de usuarios según el
flujo de la red [16]. Usó un método para aplicar políticas adecuadas
en SDN. Este enfoque solo se ocupa del control de acceso y no
considera todas las amenazas en SDN. Nayaky otros. [17] propuso
un sistema de control de acceso dinámico llamadoResonanciaque
utiliza información de nivel de flujo y alertas en tiempo real. El
sistema no proporciona una descripción general de seguridad de
SDN. Chengy otros. [18] propuso una plataforma de seguridad
llamadaOSCO, que admite protocolos y módulos de algoritmos
criptográficos altamente configurables, extensiones de hardware
flexibles y redes SDN virtualizadas. El protocolo OpenFlow mejorado
solo consideró mejorar la seguridad del plano de datos.
B. SEGURIDAD EN REDES VIRTUALES
espinillaet al.[19] introdujo FRESCO que proporciona un marco
para desarrollar aplicaciones de seguridad OpenFlow y módulos
de detección y mitigación disponibles en OpenFlow. Sin
embargo, solo aborda los aspectos de seguridad de las
operaciones de SDN, no toda la seguridad de la red. Es decir, no
se tiene en cuenta la seguridad de los componentes SDN (p. ej.,
controladores y enrutadores SDN). Chungy otros. [20] propuso
un marco llamado NICE que puede detectar y responder a
ataques en sistemas de red virtual. NICE proporciona detección
de vulnerabilidades, medición y selección de contramedidas.
Tiene un modelo de análisis basado en gráficos de ataque y una
contramedida basada en una red virtual reconfigurable. El
marco NICE se puede adoptar en la evaluación de seguridad de
SDN, pero los componentes específicos de SDN no se tienen en
cuenta en el marco.
C. SEGURIDAD SDN
Kreutz resume la descripción general de varias amenazas en SDNet
al.[7], presentando los siete vectores de amenazas que pueden
existir en SDN y las posibles soluciones para mitigarlos. De esas siete
amenazas SDN, tres de ellas son específicas del controlador SDN.
Esto muestra la importancia de proporcionar seguridad para los
nuevos componentes SDN, ya que la seguridad del sistema puede
degradarse significativamente cuando se explota. Los métodos de
ataque específicos de SDN se analizan en [9] y varias contramedidas
contra los ataques en SDN en [8], pero se centraron únicamente en
las amenazas específicas de los componentes de SDN. Como
resultado, no se describe la aplicabilidad de las mitigaciones junto
con las vulnerabilidades y contramedidas existentes (es decir,
componentes de seguridad que no son SDN). Ghoshy otros. [21]
propuso un marco de seguridad para
137433

FIGURA 1.Un marco para la evaluación de la seguridad en SDN.
Redes eléctricas inteligentes habilitadas para SDN. Implementaron
IDS para detectar eventos de ataque al monitorear de cerca los
comandos de control desde el controlador SDN hacia/desde
SCADAmaster. Su uso especializado del marco dificulta la
generalización del enfoque en escenarios generales de SDN.
Chowdharyy otros. [22] propuso un marco de seguridad dinámico
basado en juegos en redes en la nube habilitadas para SDN. Aunque
el marco se puede aplicar a otras arquitecturas basadas en SDN, no
se tienen en cuenta los vectores de amenazas específicos de SDN.
Del mismo modo, Shiy otros. [23] propuso un marco de seguridad
para SDN basado en el cifrado basado en atributos, que no captura
todos los vectores de amenazas de SDN identificados en [7]. Porrasy
otros. [24] propusieron mecanismos de seguridad en la capa de
control SDN. Se llama SE-Floodlight. El SE-Floodlight es una versión
con seguridad mejorada del popular OpenFlow Floodlight Controller
que extiende Floodlight a través de un núcleo de ejecución seguro.
Diseñaron la seguridad extendida para la capa de control y
propusieron la gestión de conflictos de las reglas de flujo que
ocurren cuando se distribuyen múltiples aplicaciones dentro de una
red. Sin embargo, solo se centraron en los controles de SDN sin
considerar la interacción entre las vulnerabilidades existentes y sus
efectos en SDN. Además, existen técnicas propuestas previamente
para abordar una o varias de esas amenazas identificadas en SDN
[25], [26].
tercero MARCO DE EVALUACIÓN DE SEGURIDAD PARA SDN
A. VISIÓN GENERAL DEL MARCO
Figura1traza nuestro marco de evaluación de seguridad propuesto para
SDN. Este marco tiene cinco fases: (1) recopilación de datos, (2)
generación de modelo de sistema, (3) generación de modelo de amenaza,
(4) evaluación de seguridad y (5) selección de contramedidas.
En primer lugar, la fase de recopilación de datos recopila y procesa
información "en bruto" sobre los componentes de SDN (es decir, hosts, tablas
de flujo, configuración/servicios del controlador, etc.) y la información de
vulnerabilidades de los componentes de SDN. Usamos algunas tablas de flujo
existentes e información sobre amenazas [9] para construir un modelo de
sistema (fase 1).
En segundo lugar, la fase de generación del modelo del sistema construye
Modelo del sistema SDN basado en la información procesada
recopilada en la fase (1). Describimos el modelo de sistema SDN y
presentamos un ejemplo para SDN (pág.paso 2). Basado en el flujo
mesainformación sobre es y amenazas, definimos tres escenarios de ataque
ios que cun occestas en th reety pes de operaciónns t Aplicar estos
ataques a la s sistema m Modelo.
137434
T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad
En tercer lugar, la fase de generación del modelo de amenazas identifica las
amenazas impuestas al sistema SDN en función de las vulnerabilidades dadas,
la tabla de flujo y el modelo de sistema generado. El modelo de amenaza se
divide además en modelo de amenaza de flujo de control y modelo de
amenaza de flujo de datos. El modelo de amenazas de flujo de control describe
amenazas que pueden afectar al controlador SDN o al conmutador OF, y el
modelo de amenazas de flujo de datos muestra las amenazas entre hosts SDN
en el plano de datos. El modelo de amenazas maneja las rutas de ataque y la
información de amenazas para la evaluación de seguridad. describimos
modelos de amenazas introduciendo vectores de amenazas para cada nodo
SDN (fase 3). Usamos los escenarios de ataque para describir los vectores de
amenazas del sistema.
En cuarto lugar, la fase de evaluación de seguridad evalúa e identifica
amenazas potenciales en SDN mediante la correlación del sistema y el flujo de
paquetes. Para evaluar de manera eficiente la seguridad de SDN, las medidas
de centralidad de la red se pueden utilizar para identificar nodos críticos en el
sistema [27]. En lugar de rutas de red, las rutas de enrutamiento de ataques se
utilizan para identificar nodos críticos en el sistema con respecto al ataque
evaluado. Los puntajes de vulnerabilidad pueden resaltar la gravedad de los
ataques que pueden causar un impacto significativo en SDN. Podemos usar las
puntuaciones de vulnerabilidad para calcular el riesgo del sistema para
obtener una visión general de la postura de seguridad de SDN. Podemos
evaluar la seguridad de SDN en función de las rutas de ataque y el riesgo
utilizando las métricas de impacto de ataque. Este método analiza la tasa de
ataque y el impacto, y los utiliza para determinar la seguridad del sistema,
teniendo en cuenta diferentes escenarios de ataque y capacidades. En la fase
final del marco, la contramedida se selecciona en función de los resultados de
la evaluación de seguridad en función de las medidas de centralidad de la red,
las puntuaciones de vulnerabilidad y los valores métricos del impacto del
ataque.
Finalmente, la fase de selección de contramedidas selecciona las
contramedidas óptimas y las implementa en SDN. La contramedida que
usamos en este documento se basa en el trabajo [1], [20], que son el
parche de Linux (un tipo de parche de software), la inspección profunda
de paquetes (DPI) o la creación de reglas de filtrado (CFR). Demostramos
la selección de contramedidas en base a sus comparaciones de
efectividad en la SecciónIV.
B. DETALLES DEL MARCO
1) MODELO DEL SISTEMA
Visión general:Figura2muestra un ejemplo de SDN que será tu sed para
nuestra simulación para mostrar la viabilidad de nuestra propuesta
marco de evaluación de seguridad para SDN. Este SDN de ejemplo
VOLUMEN 7, 2019
T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad

FIGURA 2.Un modelo de sistema y vectores de ataque para una SDN.

se usa para demostrar las operaciones de SDN y llevamos a cabo TABLA 1.Tabla de flujo inicial.

simulaciones extendiendo esta red SDN de ejemplo. El SDN de ejemplo

que hemos configurado consta de un controlador y tres conmutadores
OpenFlow (indicados comoOFSi). Cada OFS está conectado a un servidor
físico. El servidor conectado a laOFS1ejecuta dos máquinas virtuales (VM)
y actúa como un servidor web en la red SDN. Por supuesto, los hosts
individuales se pueden conectar directamente a los conmutadores OF y
proporcionar servicios. En cualquier entorno, el escenario de ataque es el
mismo. OFS1tiene tres puertos habilitados; el puerto 1 está conectado al
enrutador, el puerto 2 está conectado al servidor web y el puerto 3 está
conectado al segundo OFS (es decir,OFS2) y se utiliza para intercambiar
paquetes conOFS2. El servidor de aplicaciones (App) conectado aOFS2
contiene dos máquinas virtuales y actúa como un servidor de
aplicaciones en la red SDN. Similar aOFS1,OFS2tiene tres puertos
habilitados; el puerto 1 está conectado aOFS1, el puerto 2 está conectado base de datos para enviar una solicitud, yOFS2, que recibe el
al servidor de aplicaciones y el puerto 3 está conectado aOFS3, paquete del servidor de aplicaciones, lo reenvía al puerto 3.OFS3
respectivamente. El servidor de base de datos conectado aOFS3ejecuta , que recibe el paquete, lo reenvía a la base de datos y,
una máquina virtual y actúa como una base de datos.OFS3tiene dos finalmente, la base de datos procesa la solicitud.
puertos habilitados; el puerto 1 está conectado aOFS2y el puerto 2 se
utiliza para intercambiar paquetes con la base de datos. 2) INFORMACIÓN DE AMENAZA
Una parte de la fase 2 en el marco trata sobre el procesamiento de la
Tabla de flujo:según la fase 1 en el marcotercero, el marco información de amenazas dentro del modelo del sistema y la usó para
recopila información de accesibilidad (es decir, cómo se conectan las construir modelos de amenazas a través de modelos gráficos de
máquinas virtuales) primero. La información de accesibilidad se seguridad (consulte la fase 3 del marco). Mesa2muestra los sistemas
deriva de la(s) tabla(s) de flujo. Mesa1muestra un ejemplo de una operativos que se ejecutan en cada máquina virtual. Por ejemplo,
tabla de flujo. máquina virtual1en el servidor web está ejecutando Windows 7 como
Cuando una tabla de flujo como Table1se aplica en una configuración sistema operativo. El controlador SDN (indicado comoCTL1) puede
SDN como se muestra en la Figura2, el sistema funciona como ejecutar OpenDayLight (ODL) o sistema operativo de red abierta (ONOS).
sigue. Cuando un usuario intenta realizar una solicitud Todos los OFS ejecutan OpenFlow Spec 1.3.0. La información de
(enviando un paquete) al sistema, el enrutador recibe el paquete vulnerabilidades de software se puede recopilar en función de los
y lo envía aOFS1.OFS1envía el paquete al servidor web por el sistemas operativos y las aplicaciones. La información de vulnerabilidades
regla de flujo especificada, y th mi
servidor web ch ecks el paquete y de software en VM y CTL en la red SDN se resume en la Tabla3.
proceder siente el fuego búsqueda. los n, el servidor web ver envía una solicitud Solo se asignó una vulnerabilidad a cada VM por simplicidad, pero
hacia r para su posterior procesamiento. SiOFS1recibe
servicio de aplicación todo el conjunto de vulnerabilidades en aplicaciones y sistemas
paquete de esto un servidor web, el conmutador lo reenvía al operativos se pueden incorporar, modelar y evaluar en el modelado
Cuando puerto 3. el paquete ded llega aOFS2,OFS2lo envía a
una guerra delantera gráfico de seguridad de la misma forma que lo hicimos en [28] y
la A pags p servidor a según la regla de flujo y la búsqueda del servidor [29]. Esas vulnerabilidades se pueden encontrar usando varios
ds un paquete al
proceder siente el fuego de aplicaciones. El servidor envía
aplicación métodos y herramientas de escaneo de vulnerabilidades como

VOLUMEN 7, 2019 137435


TABLA 2.Sistemas de operación en VMs y OFS.
TABLA 3.Vulnerabilidades en hosts.
como NESSO [30]. Utilizamos el Sistema de Puntuación de Vulnerabilidad
Común (CVSS) [31] Puntuación Base (BS) en la base de datos de
Vulnerabilidades y Exposiciones Comunes (CVE). Las vulnerabilidades
específicas de SDN (es decir, flujos, controladores, etc.) también se
pueden detectar utilizando métodos de detección de vulnerabilidades en
el trabajo [9], [32]–[34]. El controlador SDN puede tener diferentes
vulnerabilidades según las aplicaciones SDN; el controlador SDN usando
ODLposeev6mientras que está usandoONOSposeev7.
Especificamos tres amenazas diferentes para el SDN de ejemplo.
Las tres amenazas están marcadas con las líneas continuas rojas en
la figura.2: (1) amenaza directa a la VM, (2) amenaza directa al
controlador SDN y (3) amenaza al controlador SDN a través de la VM.
En particular, la amenaza (2) y (3) son específicas del entorno SDN
donde tales ataques no son posibles en otras redes típicas. Los
detalles son los siguientes:
(1) Amenaza a la máquina virtual.Un atacante puede explotar una
vulnerabilidad en la máquina virtual para atacar un servidor web
conectado a Internet. Luego, el atacante apunta a otros servidores en el
sistema a través del servidor web. En este caso, existe la amenaza de que
un atacante pueda explotar directamente las vulnerabilidades de las
máquinas virtuales existentes en el sistema. Esta amenaza también está
presente en las redes existentes (es decir, los modelos existentes también
pueden evaluar esto). Si un atacante tiene éxito en explotar esta
vulnerabilidad, puede interferir con la operación de la VM o adquirir
información existente en la VM y el atacante también puede obtener el
privilegio de administrador de la VM.
(2) Amenaza al Controlador SDN.El flujo de la red SDN está
determinado por la aplicación SDN utilizada en el controlador
SDN. Sin embargo, si un atacante adquiere privilegios de
administrador del controlador SDN o administra el mensaje
usando la aplicación SDN maliciosa, el flujo de red
puede modificarse según la intención del atacante.
El r Antes, hay un amenaza que t el atacante puede directamente
ataque k SDN cont rollo más
. el ataque k métodos utilizados sonción Interna
a ataque
almacenamiento de mal uso de ge k, Aplicar Ataque de desalojo, Evento
137436
T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad
Ataque de cancelación de suscripción del oyente, ataque de caída de
mensaje de control,yMensaje de control Ataque de bucle infinito.Ataque
de uso indebido de almacenamiento interno, ataque de desalojo de
aplicaciones, yAtaque de cancelación de suscripción del detector de
eventosson posibles ataques en las Operaciones de Flujo de Control Intra
de SDN.Ataque de caída de mensaje de control yMensaje de control
Ataque de bucle infinitoson ataques que pueden ocurrir enOperaciones
de flujo de control asimétrico[9]. Si un atacante tiene éxito usando estos
métodos de ataque, el controlador SDN puede desactivarse o
manipularse según la intención del atacante.
(3) Amenaza al controlador SDN a través de VM.Si un atacante
obtiene el privilegio de administrador de VM, el atacante puede enviar
paquetes al controlador SDN a través del conmutador OF conectado con
la VM. Luego, el atacante puede atacar el controlador SDN enviando un
paquete malicioso. Enflujo abierto1.3.0, el conmutador puede filtrar
paquetes mediante un cortafuegos. Por lo tanto, si se bloquean todos los
paquetes que no sean las reglas de flujo definidas, es imposible que el
atacante envíe un paquete al controlador SDN a través del conmutador.
Por otro lado, si un conmutador solicita a un controlador que determine
una regla de flujo para un paquete indefinido, un atacante puede atacar
al controlador SDN a través del conmutador. En este caso, existe la
amenaza de que la VM pueda atacar el controlador SDN. Los métodos de
ataque utilizados en este caso sonPAQUETE EN Ataque de inundación,
Ataque de escucha, y Ataque de hombre en el medio.PAQUETE EN Ataque
de inundacióny Ataque de espionajepuede ocurrir enOperaciones de flujo
de control asimétrico, yAtaque de hombre en el mediono puede ocurrir
solamente enOperaciones de flujo de control asimétrico, pero también
ocurren en Operaciones de flujo de control simétrico[9]. Esta amenaza
difiere de la amenaza de atacar directamente el controlador SDN usando
la aplicación SDN maliciosa. Los ataques que utilizan aplicaciones SDN
maliciosas tienen como objetivo principal manipular el comportamiento
del controlador SDN. Por otro lado, la amenaza de atacar el controlador
SDN en la VM está engañando principalmente al controlador SDN.
3) MODELO DE AMENAZA MEDIANTE MODELOS DE SEGURIDAD GRÁFICOS
Usamos dos capasModelo de representación de ataques jerárquicos de
vectores de amenazas (TV-HARM)para el modelado y análisis de
amenazas [35], [36], una extensión novedosa de HARM para capturar
"ataques basados en amenazas" en lugar de ataques individuales
teniendo en cuenta los vectores de amenazas en SDN. TV-HARM puede
variar según la combinación de vectores de amenazas utilizados en la
configuración del modelo, que es diferente del HARM que modela todos
los componentes del sistema (es decir, no podemos usar el HARM tal
cual). Por lo tanto, definimos TV-HARM teniendo en cuenta los vectores
de amenazas de la siguiente manera.
Primero, la combinación de vectores de amenaza (TV) se puede definir de la
siguiente manera:
Definición 1:Una combinación de vectores de amenazas.Ci= {televisión1, televisión2,televisión3, . . . ,
televisióni},televisióni∈2TELEVISOR.televisiónies miembro de un conjunto de poder de todos los vectores
de amenazasTELEVISOR.
Creamos un TV-HARM utilizando las combinaciones definidas
de vectores de amenazas. Más específicamente, un TV-HARM es
un modelo de dos capas, donde la capa superior captura el
mapeo de los componentes SDN y su accesibilidad usando
VOLUMEN 7, 2019
T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad

el gráfico de ataque (AG). La capa inferior captura la información

de vulnerabilidad usando el Árbol de Ataque (AT) [13]. La
definición de TV-HARM es la siguiente.
Definición 2:El TV-HARM se define como una tupla de 3 TVHCi=
(tuCi, LCi, mCi), dónde,METROCies el mapeo entre los
componentes de la capa superior e inferior.
METROCi:tuCi→LCi.dóndetuCies el AG yLCies el AT para cada
Cirespectivamente.
Definición 3:Un AG se define como una tupla de 2tuCi= (ÉL), dóndeHes
un conjunto finito de hosts en SDN.mi⊆H× Hes un conjunto de aristas
donde un par de anfitriones.
Definición 4:UnAse define como una tupla de 5LCi= (un, b,
c, g, raíz), dóndeAes un conjunto finito de vulnerabilidades, yBes un
conjunto de puertas que son los nodos internos dea∈A,A∩B=∅, yraíz
∈A ∪ B.
FunciónC:B→PAGS(A∪B) describe los hijos de cada
nodo en un AT.
Funcióngramo:B→ {Y, O}describe el tipo de cada
puerta.
la representación deahasociado al anfitriónh∈Hes como
sigue:
• LhCi:A⊆hvuls
Dadas las definiciones de TV-HARM, el SDN de ejemplo en
forma de TV-HARM se puede representar de la siguiente
manera. Para representar un TV-HARM, se debe definir la
capa superior, la capa inferior y el mapeo entre las dos
capas. Por lo tanto, definimos los ejemplos 1, 2 y 3 para el
TELEVISOR- DAÑO mostrado en la Figura 3(c). e 1 muestra la capa
El ejemplo entre la capa superior y el ejemplo 2mapower. Examen-
muestra la capa superior que representa entreentra en la conexión
los nodos del sistema. Finalmente, ex capa El ejemplo 3 muestra
inferior que representa la relación en un nodo las vulnerabilidades
por AT.
Ejemplo 1: el superior y el inferior Mapeo de capas: FIGURA 3.Modelo de amenazas de flujo de control para todos los dispositivos.

La Figura 3(c) muestra TV-HARM de SDN. La combinación de

Vectores de amenazasC4estelevisión123.televisión vectores de amenaza 1,
Por ejemplo, asumimos que el objetivo de un atacante es lanzar un
123incluye y 3. El TV-HARM paraC4esTVHC4 2, = (tuC4,LC4,METROC4),
ataque de adquisición de información o un ataque de denegación de
dóndetuC4yLC4son el AG y el conjunto de AT en la capa servicio en la base de datos, el atacante puede intentar atacar la máquina
superior e inferior enC4, respectivamente, yMETROC4:tuC4→ virtual en el plano de datos utilizando el método de ataque disponible en
LC4es un mapeo uno a uno de la capa inferior ejemtuC4hacia
la red existente. Pero, si un sistema como el de la Figura2funciona
correspondiente de capa superiorLC4.
normalmente, los paquetes maliciosos no pueden ir a la red interna
Ejemplo 2: La capa superior:El AG Figura 3(c), es un gráfico se muestra en la
porque el servidor web verifica los paquetes. Sin embargo, un atacante
dirigidotuC4= (HC4, HC4= {A,máquina virtual1,máquina virtual2, miC4), dónde
puede atacar el controlador SDN a través detelevisión123y atacar el
máquina virtual3,máquina virtual4,máquina virtual5,CTL1, OFS3OFS1,OFS2,
conmutador conectado utilizando la autoridad del controlador SDN
}, ymiC4= {(A,máquina virtual1), (A,máquina virtual2), (A, CTL1), (máquina virtual1,
después de que el ataque tenga éxito. Si el atacante puede modificar con
3 1 4 1 1 2
máquina virtual), (máquina virtual,máquina virtual), (máquina virtual,CTL), (máquina virtual,máquina
3(máquina
virtual
virtual
), 2,máquina virtual4),
éxito la tabla de flujo atacando el interruptor OF conectado al controlador
(máquina virtual2,CTL1), (máquina virtual3,CTL1), (máquina virtual4,CTL1), ( CTL1,OFS1), SDN, el atacante puede establecer la ruta de ataque deseada. Luego, el
(CTL1,OFS2), (CTL1,OFS3)}. atacante puede enviar los paquetes al servidor de aplicaciones sin
Ejemplo 3: La capa inferior:Los AT en la capa inferior verificarlos en el servidor web. Esto hace que el sistema sea más
se muestra en la Figura 3(c). El conjunto de condiciones requeridas.
peligroso. La forma en que un atacante puede atacar un controlador o
comprometersemáquina virtual1es dado porLmáquina virtual1C4 = C ,
(Amáquina virtual1
C4 ,Bmáquina virtual14
conmutador SDN se analiza en [9]. Por lo tanto, en el entorno SDN, no
Cmáquina virtual1 virtual1
C4 ,gramomáquina C41
C4 ,raízmáquina virtual ), dóndeAmáquinaC4virtual1= {v1}es un conjunto de solo los hosts presentes en el plano de datos, sino también el controlador
pagscomponentes que son la licencia s (vulnerabilidadi es), C4 virtual1= ø,
Bmáquina SDN y los switches necesitan la evaluación de seguridad. Para resolver
Cmáquina virtual1
C 4 ( 1raízmáquina virtual1) = ø, yraízmáquina virtual
C4virtual
=ø,gramomáquina C4 1= raíz,raíz∈ este problema, clasificamos los modelos en el Modelo de amenaza de
Amáquina virtual1
C C4.
4 ∪ Bmáquina virtual1 flujo de control

VOLUMEN 7, 2019 137437

 T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad

y Modelo de amenazas de flujo de datos. Construimos cuatro escenarios

de ataque basados en el propósito y el método de ataque.

• Escenario de ataque 1:El atacante explota la amenaza al

controlador SDN directamente. El objetivo del atacante es modificar
la tabla de flujo deOFS1. El atacante ataca el controlador SDN
usando la aplicación maliciosa (televisión1). Los posibles métodos
de ataque son el ataque de uso indebido del almacenamiento
interno, el ataque de desalojo de aplicaciones y el ataque de
cancelación de suscripción del detector de eventos. Luego, ataque
el interruptor OF conectado usando la autoridad del controlador
SDN. Hay ataque de modificación de la regla de flujo, uso indebido
de firmware y ataque de eliminación de la tabla de flujo para atacar
el interruptor OF. El modelo se puede ver en la Figura 3(a).
• Escenario de ataque 2:El atacante aprovecha la amenaza para
el controlador SDN a través de VM. El objetivo del atacante es
modificar la tabla de flujo deOFS1. Un atacante ataca una VM
conectada a Internet externa utilizando una vulnerabilidad en
la VM (televisión2). Luego ataque el controlador SDN usando la
VM atacada (televisión3). Los posibles métodos de ataque son
PAQUETE EN Ataque de inundacióny el ataque Man In The FIGURA 4.Modelo de amenaza de flujo de datos para VM.

Middle. Finalmente, el atacante ataca el interruptor OF

conectado usando la autoridad del controlador SDN. El modelo TABLA 4.Tabla de flujo modificada por el atacante.

se puede ver en la Figura 3(b).

• Escenario de ataque 3:El atacante explota la amenaza al
controlador SDN directamente y a través de VM. El objetivo del
atacante es modificar la tabla de flujo deOFS1. El atacante ataca el
controlador SDN usando la aplicación maliciosa (televisión1) o
máquina virtual atacada (televisión23). Los métodos de ataque
incluyen todos los métodos de ataque deEscenarios de ataque 1 y
2. Luego, ataque el interruptor OF conectado usando la autoridad
del controlador SDN. El modelo se puede ver en la Figura 3(c).
• Escenario de ataque 4:El atacante explota la amenaza a la máquina
virtual. El objetivo del atacante es obtener la información almacenada en
4) EVALUACIÓN DE SEGURIDAD MEDIANTE MEDIDAS DE SEGURIDAD
máquina virtual5. Un atacante ataca una VM conectada a Internet
Realizamos evaluaciones de seguridad utilizando tres métodos (fase 3 del
externa utilizando una vulnerabilidad en la VM (televisión2). Luego, el
marco propuesto). Primero, usamos la Medida de centralidad de la red
atacante intenta atacar usando las máquinas virtuales conectadas hasta
para considerar la importancia de cada nodo que constituye el modelo de
que el atacante logra atacar elmáquina virtual5. El modelo se puede ver
amenaza. El segundo es la evaluación de la seguridad utilizando puntajes
en la Figura 4(a).
de vulnerabilidad. Evaluamos la seguridad del sistema utilizando

máquina virtual1ymáquina virtual2proteger la red interna de ataques vulnerabilidades conocidas. Finalmente, usamos las métricas de impacto

externos. YOFS1envía todos los paquetes desde la red externa de ataque para evaluar la seguridad.

amáquina virtual1ymáquina virtual2. Sin embargo, si un esessfully com-

atacante tiene éxito promete la SDN contra troller usandoescenarios 1, 2, a: MEDIDA DE CENTRALIDAD DE LA RED
el ataque s o 3, el atacante obtiene permiso para él tabla de flujo. Usando la Medida de centralidad de la red en el modelo gráfico, podemos
modificar t El atacante puede intentar conectarse soy el externo considerar la importancia de cada nodo y encontrar los nodos
directamente desde la red a la red interna modificando t la mesa de flujo importantes. Una descripción detallada de la Medida de Centralidad de la
deOFScomo
1 se muestra en la Tabla4. Entonces todo el pa boletos llegando Red se puede encontrar en [27]. Entre ellas, utilizamos las medidas de
aOFS1será enviado aOFS2. En este punto, puede s el atacante centralidad de grado y centralidad de intermediación. La centralidad de
final packets ala app se rveringenio fuera revisando el grado está determinada por el número de aristas conectadas a otros
paquetes en el servidor web. En este caso, el Modelo de amenazas de nodos. Por ejemplo, en la Figura 3(a), el grado de centralidad deC1es 4.
flujo de datos cambia como en la Figura 4(b). ya hemos discutido Cuanto mayor sea el grado de centralidad de un nodo, más conexiones
un modelo similar en [37]. Sin embargo, si una atacante compromisos tiene con otros nodos. Por lo tanto, es probable que el nodo sea
el controlador SDN y cambia maliciosamente la red importante en el sistema.
flujo, el sistema podría volverse más vulnerable Erabl mi. Por lo tanto,
norte La centralidad de intermediación está determinada por la proporción en que el iel
seCurity evaluar isobre el Control SDN r y El interruptor OF es host está incluido en la ruta de ataque. En general, la centralidad de intermediación
importar tant en para el SDN e medio ambiente establece todos los nodos como nodos de inicio o nodos de destino y

137438 VOLUMEN 7, 2019

T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad

analiza cada camino. Y solo considera el camino más corto. Sin embargo, en
este documento, el atacante y el objetivo están definidos, por lo que
analizamos solo la ruta. La evaluación de seguridad también debe considerar
todas las posibles rutas de ataque. Entonces, calculamos la centralidad de
intermediación para todas las rutas de ataque. Por ejemplo, en la Figura 4(a), el
número de rutas de ataque es 4. Y hay dos rutas de ataque que incluyen
máquina virtual1. Por lo tanto, la centralidad de intermediación demáquina
virtual1es 0.5. Si el atacante ataca con éxito OFS1y el modelo de amenaza de
flujo de datos cambia como se muestra en la Figura 4 (b), el número de rutas
de ataque es 6. Sin embargo, dado que todavía hay dos rutas de ataque que
involucranmáquina virtual1, la centralidad de intermediación demáquina virtual
FIGURA 5.Métricas de impacto de ataques para la evaluación de la seguridad.
1es 0,33.

Finalmente, la probabilidad total y el riesgo total del sistema en el

b: PUNTAJE DE VULNERABILIDAD
modelo utilizando el vector de amenazasCise puede expresar como
Al evaluar la seguridad de un sistema en red, podemos utilizar vulnerabilidades
pagsCiyrCi,respectivamente. La fórmula para calcular es como
conocidas y sus métricas asociadas (por ejemplo, el sistema común de
sigue.
calificación de vulnerabilidades). Utilizamos las vulnerabilidades enumeradas ∏
en la Tabla3para demostrar la fase de evaluación de seguridad de nuestro pagsCi=1 - ( i)
1 - pagsap
C (7)
modelo de amenazas propuesto. Para hacerlo, calculamos la probabilidad de ap∈punto de accesoci

∑
éxito del ataque y el riesgo utilizando la puntuación base CVSS y la puntuación
rCi= rap (8)
Ci
de impacto para cada vulnerabilidad. Los detalles de las vulnerabilidades CVSS
ap∈punto de accesoci

se pueden encontrar en [31].

Primero, calculamos la probabilidad de éxito del ataque y el
riesgo de una sola vulnerabilidad,vi. La probabilidad de éxito del
ataque de la vulnerabilidad.vise puede expresar comopagsvi,y la
fórmula para calcular es la ecuación1. Una de las métricas CVSS
representa una explotabilidad que va de 0 a 10, que usamos en
nuestro trabajo como la probabilidad del ataque escalando entre 0 y
1. El riesgo se puede expresar comorvi,y se calcula como ecuación2.
El valor de impacto también se utiliza de la métrica de impacto de
CVSS para la vulnerabilidad conocida. Tratar las vulnerabilidades sin
los detalles de CVSS está fuera del alcance de este documento.
Sin embargo, puede haber vulnerabilidades desconocidas (p. ej.,
vulnerabilidades en los controladores SDN comoLuz de inundacióny
VIRUELAno se conocen). Por lo tanto, la evaluación de seguridad
mediante vulnerabilidades puede no ser aplicable en todas las
configuraciones de SDN. Además, si el atacante obtiene privilegios de
administrador del controlador SDN, la tabla de flujo se puede modificar
sin explotar la vulnerabilidad de OpenFlow Switch. Debido a que este
método de ataque no conoce la puntuación de vulnerabilidad exacta,
llevamos a cabo un análisis de sensibilidad para investigar los cambios en
la seguridad con respecto a las distintas métricas asociadas a la
vulnerabilidad.

Licenciatura en CVSSvi
pagsvi= (1) c: MÉTRICAS DEL IMPACTO DEL ATAQUE
10
La evaluación de seguridad utilizando las métricas de impacto de ataque
rvi=Impactovi× pagsvi (2)
es un método que puede mostrar la seguridad integral del sistema.
A continuación, calculamos la métrica de seguridad del host. Si Figura5muestra las métricas de impacto de ataque que usamos. Las
conocemos la métrica de seguridad de la vulnerabilidad que tiene el host, columnas representan la probabilidad de éxito del ataque y las filas
podemos calcular la métrica de seguridad del host. La probabilidad de representan el impacto. Analizamos la tasa de ataque en todas las
éxito del ataque y el riesgo de un host se puede expresar como posibles rutas de ataque en un modelo de amenaza determinado. Aquí,
pagshyrh, y la ecuación es la siguiente. asumimos que un atacante atacará por igual a los posibles nodos de
∏ ataque. Si un atacante apenas puede atacar al objetivo (menos del 20%),
pagsh=1 - pagsv,h∈H (3)
se define como 'Raro'. Por otro lado, si un ataque ocurre con frecuencia y
∑v∈h es más probable que el objetivo sea atacado (más
rh= rv,h∈H (4) superior al 80%), se define como 'Casi Cierto'. Y analizamos el
v∈h impacto del ataque según la medida en que el servicio
El siguiente paso es el cálculo de la métrica de seguridad de la ruta de interfiere en el éxito del ataque. El servicio se basó en el
ataque. Una ruta de ataque está representada porap. La métrica de servicio web, que es la función del sistema. Si un atacante
seguridad para unoapen el modelo usando el vector de amenazaCies ha atacado con éxito el sistema y la función del sistema
ap
Ci yrCi. Puedes mostrar th mi fórmula a en igualdad ción5y6.
pags ap

rara vez funciona, se define como 'Crítico'. Por otro lado,

∏ si un atacante tiene éxito en un ataque pero no afecta la
ap
pags = C, ap∈ punto de acceso
pags (5)
funcionalidad del sistema, se define como 'Insignificante'.
h Ci
Ci i
h∈ap
∑
rap = rChi, ap∈ (6) Por ejemplo, el sistema de la figura2es como sigue. Primero,
Ci punto de accesoCi

h∈ap asumimos que el tiempo de procesamiento del servidor web es

VOLUMEN METRO
7 de mayo de 2019 137439
 T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad

2 segundos, el tiempo de procesamiento del servidor de aplicaciones es de 2 TABLA 5.Evaluación de la seguridad utilizando la métrica de centralidad de grado.

segundos y el tiempo de procesamiento de la base de datos es de 1 segundo. Y

calculamos el tiempo total de procesamiento cuando se realizaron un total de 100
solicitudes del usuario una vez por segundo. Si el sistema está en un estado normal,
se necesitan 104 segundos para que se procesen todas las solicitudes. Sin embargo,
si una de las dos máquinas virtuales en el servidor web o una de las dos máquinas
virtuales en el servidor de aplicaciones falla, el tiempo de procesamiento aumenta a
203 segundos. Sin embargo, dado que tanto el servidor web como el servidor de
aplicaciones tienen dos máquinas virtuales, el servicio no es imposible. Por lo tanto, si
solo se ataca una de las máquinas virtuales en el servidor web o el servidor de
aplicaciones, el impacto es moderado.

IV. EXPERIMENTOS Y ANÁLISIS

Hay una falta de investigación que utilice modelos gráficos de seguridad
(p. ej., un gráfico de ataque) para evaluar la seguridad de SDN teniendo
en cuenta las amenazas de los datos y del plano de control [20], [38]. Pero
hasta donde sabemos, nuestro trabajo es el primero en evaluar la
postura de seguridad de SDN, incluidos los datos y los planos de control,
utilizando un modelo de seguridad gráfico. En nuestro trabajo, utilizamos
TV-HARM para evaluar la postura de seguridad.
En esta sección, usamos las tres métricas de seguridad
TABLA 6.Evaluación de la seguridad utilizando la métrica de centralidad de intermediación.
presentadas en la SecciónIII-B.4. A través del análisis
experimental, mostraremos cómo varían las métricas de
seguridad cuando se aplican contramedidas en SDN. En
particular, nos enfocamos en un subconjunto de
amenazas, donde el objetivo del ataque es comprometer
la base de datos en SDN. Para mitigar estos ataques,
consideramos tres contramedidas que incluyen (a)
parche Enterprise Linux, (b) inspección profunda de
paquetes (DPI) o (c) creación de reglas de filtrado (CFR) y
parche de software SDN. El parche Enterprise Linux
previene una vulnerabilidad en una máquina virtual que
usa Enterprise Linux. DPI o CFR permite el bloqueo de
paquetes maliciosos al examinar los paquetes enviados
desde la VM al controlador SDN. El parche del software
SDN evita que un atacante utilice la aplicación SDN
maliciosa. Por supuesto, también se pueden utilizar otras
contramedidas en el marco para evaluar su eficacia.IV-A,
IV-B, yIV-C, respectivamente.

A. MEDIDAS DE CENTRALIDAD DE LA RED

Primero evaluamos la importancia de cada nodo SDN usando
las medidas de centralidad de la red. Los resultados se muestran en estado, el grado de centralidad de todos los nodos es igual. Sin embargo, si el
mesas5 y6 tusing
de Cmiintralit y y centro de intermediación
verde atacante modifica la tabla de flujo atacandoOFS1, el grado de centralidad de
tralidad fácil mi
metro mi y. Mesa 5muestra que cuando nosotros
s, respectivamente
nivel activo máquina virtual3ymáquina virtual4aumenta, porque el atacante puede cambiar
aplicar d iferre t contar mi
norte rmeas tu mieficacia varía
descansarsu la dirección del flujo y, en consecuencia, atacarmáquina virtual3ymáquina
tan alto li lucha d por dif Fmi alquilar yo porta nce valor de cada SDN
metro virtual4directamente. Aplicación de Enterprise Linux
nodo. T hes es mi esperar como d iFdiferente las contramedidas afectan
educar Patch reduce el grado de centralidad porque los caminos que
el sistema mi m depagsfin Ci fealquilado (por ejemplo, una ruta de ataque en
es diferente ataquemáquina virtual2ymáquina virtual4están bloqueados (es decir, aunque el
SDN co tu sería remov n/A Larhabilidad está parcheada). Para
educarquién y dónde vulnerable atacante puede llegar a esas máquinas virtuales, la vulnerabilidad se ha eliminado).
ejemplo mi , para allá sues de tel thr mi
metro mi co Amenaza de flujo de control Por supuesto, podría haber otras vulnerabilidades que podrían ser explotadas.
Modelos scómo non tabla mi 5(a), wpuedo se miqueCTL1es lo mas Todavía podemos observar la importancia demáquina virtual1y máquina virtual3
importa no dmi
norte hifantasma avedad valor de centralidad de grado
(es decir aumentando relativamente como resultado de la aplicación de Enterprise Linux Patch.
a través de all thr mia
t vector o s), para adeudado bymáquina virtual ymáquina virtual . los
todos 1 2

Los resultados del Modelo de amenazas de flujo de datos pueden variar Mesa6muestra los resultados utilizando la centralidad de intermediación.
significativamente según las reglas especificadas en la tabla de flujo. en la inicial En el Modelo de amenazas de flujo de control, configuramos el nodo inicial

137440 VOLUMEN 7, 2019

T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad

aA(es decir, el nodo atacante en el modelo) y el nodo de destino paraOFS1(es

decir, un nodo objetivo potencial). También consideramos todas las rutas de
ataque, no las rutas más cortas. Los resultados muestran que la centralidad de
intermediación del nodoCTL1es el más alto en el Modelo de amenazas de flujo
de control (es decir, el valor promedio entre otros nodos). Además, dentro de
las puntuaciones de cada contramedida,CTL1
tiene la puntuación de intermediación más alta. Esto implica queCTL1
El nodo se encuentra entre gran parte de las rutas de ataque en el SDN
experimental, según lo capturado por TV-HARM. En el Modelo de amenazas de
flujo de control,CTL1tiene el valor de centralidad de intermediación más alto.

Aunque estos resultados muestran que no hay una diferencia

significativa cuando se utilizan las medidas de centralidad de grado y de
intermediación para la evaluación de la seguridad, otros entornos de SDN
con un escenario de ataque más complejo pueden descubrir lo contrario.
Sin embargo, ambosenfoques resaltaría nodos importantes
en el en tachuela capitán de cenarios urado porTV-DAÑO, s los resultados
¿lo harías? probable conflicto. Por lo tanto, es recomendado d para usar ambos
puntuación sistemas para tomar decisiones de seguridad significativas cuando
seleccionando la contramedida a implementar.

B. MÉTRICA DE PUNTUACIÓN DE VULNERABILIDAD

A continuación, evaluamos la seguridad de SDN b basado en t el vulner-

información de habilidad reunida como se muestra en la Tabla3. También
consideramos algunas de las acciones del atacante: asumimos que si el
agresor compromete el controlador SDN, entonces el atacante también
puede modificar la tabla de flujo configurando incorrectamente los
conmutadores OF. Ental caso, la prueba habilidad o f un ataque exitoso
para compromiso, el interruptor OF es uno. Además, la tabla de flujo
yo canto

se puede configurar de tal manera que beneficie al atacante el most,

por lo que la i Se asigna un valor de impacto de 10.
Nosotros también asumir e que todo att patadahs son igualmente probable que sea
explotar d por el atacante, y cada evento de ataque soy yo independiente
de otro s. Sin embargo, estos supuestos podrían relajarse si
también introducimos la probabilidad de selección de ruta, que
podría modelarse usando el TV-HARM. Sin embargo, requiere un análisis
empírico para asignar v apropiadovalores, w Esto está fuera del alcance
de este documento.
Figura6muestra el análisis de seguridad basado en puntajes de vulnerabilidad
utilizando el Modelo de amenazas de flujo de control que se muestra
en figura mi3. La Tabla 7(b) muestra los resultados detallados.No. de
caminoses el número de caminos quet un en tacker puede atacar a un
objetivo en el model.Sh ruta de prueba Longitudhmuestra la distancia
de los mas cortos ataque camino, yLongitud de ruta mediamedio
la distancia media de todas las rutas de ataque.Probabilidad máxima
FIGURA 6.Evaluación de seguridad del modelo de amenazas de flujo de control mediante puntuación
representa elmayor probabilidad capacidad de éxito de ataque entre los de vulnerabilidad.

ataque p ates, un Dakota del NortePR totalobabilidadysignifica el su m de ataque

éxito probabilidad de todos los ataques p aths usando el lógico
suma.METRO riesgo de hacharepresenta el riesgo de la ruta de mayor riesgo
entre las rutas de ataque, yRiesgo totalsignifica la suma del riesgo
valor de todas las rutas de ataque. El modelo usando eltelevisión1solo tiene una
ruta de ataque que explota el controlador SDN(trivial c Plaza bursátil norteamericana).
Este ataque se puede mitigar simplemente aplicando como SDN parche. Para
el modelo contelevisión23, hay seis rutas de ataque diferentes para
el atacante para explotar el controlador SDN. Al aplicar Linux
parche, un toda la ruta de ataque, incluidas las rutas a travésmáquina virtual2ymáquina virtual4
puede ser mitigado. Como resultado, solo quedan dos rutas de ataque, el
enrutamiento a través demáquina virtual1y/omáquina virtual3. Por otro
lado, la aplicación de DPI/CFR mitiga todas las rutas de ataque. Por lo
tanto, si el costo de aplicar esas contramedidas es el mismo, entonces
aplicar DPI/CFR es más efectivo. En casotelevisión123, la aplicación de DPI/
CFR reduce más la cantidad de rutas de ataque en comparación con otras
contramedidas.
Solo el parche SDN es efectivo contratelevisión1. En otros escenarios,
observamos que la longitud de ruta media se reduce cuando diferentes

VOLUMEN 7, 2019 137441

 T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad

TABLA 7.Evaluación de la seguridad mediante puntuación de vulnerabilidad.

se aplican contramedidas. Sin embargo, es difícil relacionar la

reducción de la longitud media del camino con la seguridad del
sistema.
La probabilidad máxima se calcula en función de la máxima
valor dado porpagsapCipara las rutas de ataque. El escenario del ataque
donde el atacante explota el controlador SDN y el OF
Civalor. Por lo tanto, sin desplegar
Switch tuvo el más altopagsap
Parche SDN en el escenario de ataque dado, la probabilidad máxima no
se redujo. En el caso del modelo contelevisión23, la probabilidad máxima
se redujo marginalmente cuando se aplicó el parche de Linux, pero, por
el contrario, la implementación de DPI/CFR eliminó todas las rutas de
ataque posibles. Por lo tanto, para el análisis de probabilidad máxima, es
fundamental eliminar las rutas de ataque que conducen a la explotación
del controlador SDN. FIGURA 7.Evaluación de la seguridad del modelo de amenazas de flujo de datos utilizando la

La métrica de Riesgo Total acumula el riesgo asociado con puntuación de vulnerabilidad.

cada nodo en todas las posibles rutas de ataque dadas porrap Ci.Este
proporciona una descripción general de cuánto riesgo tiene SDN y puede
comparar la reducción de riesgo utilizando diferentes contramedidas.
Tener más rutas de ataque aumentaría el valor de riesgo total de SDN.
Cuando se implementan contramedidas que reducen el número de rutas
de ataque, el valor del riesgo total se reduce relativamente.
Además de lo anterior, también realizamos un análisis similar
utilizandoONOSen el sistema en red. Sin embargo, el resultado
Probabilidad y los valores de Probabilidad Total. Concluimos que la
implementación de contramedidas que afectan a tantas rutas de
ataque es lo que más reduce la postura de seguridad. Si tal solución
no es factible, concluimos que mitigar los ataques que explotan el
interruptor OF disminuye la postura de seguridad que otras
contramedidas.
C. MÉTRICAS DEL IMPACTO DEL ATAQUE

no mostró diferencia con el análisis del sistema usando elODL. Utilizamos las métricas de impacto de ataque como se muestra en la
Figura5 para evaluar la seguridad del sistema. Mesa8muestra la
Figura7muestra el análisis de seguridad utilizando el modelo de evaluación de seguridad de los modelos de amenazas de control y flujo
amenaza de flujo de datos. Si el atacante compromete con éxito de datos. Sitelevisión1se considera, como en la Tabla 8(a), el atacante
OFS1, el atacante puede cambiar la tabla de flujo. Como consecuencia, puede explotar el controlador SDN directamente con relativamente alto
la atacante ca nortetambién miXtramamáquina virtual
3und máquina virtual
directo y, cual h
4 probabilidad de éxito del ataque, por lo que la tasa se considera alta.
no es posibilidadi b le before chanorte
Washington envejeciendo h
t e Flo w Tabla mi. Como a Si el atacante compromete con éxito el controlador SDN,
he número ber de en tachuela pa esto aliviado,
último, t
resolución aumentar quedejar he número - el impacto resultante se valora significativamente. combinados juntos,
berde shortest aataque p aesto es rojo acertado F más allá, el PRO bebé y la calificación general esExtremo. Para mitigar este ataque, SDN
de un en tack su acceda a un s bienaes la s sistema riesgo en Creasentado , se puede implementar un parche para reducir la calificación general aMini-
shoala en Cme motivo n seguro claro si t el atta Ckerca
publicación de la ciudad mamá, mostrando una mejora significativa en la calificación. los
norte

compromesaO FS 1. rey en
Ejército de reservahasta el y Linu X Parche
para acomodar , valoración global del modelo teniendo en cuentatelevisión23es también
puede reducir el nu
nosotros ber o ataque f k caminos y T hy Tota yo
metro Extremo, pero se puede reducir aBajomediante la implementación de Linux
Arriesgar significativamente, pero solo marginalmente reduciendo el Max Parche o DPI/CFR. Esto contrasta contelevisión1escenario, mostrando

137442 VOLUMEN 7, 2019

T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad
TABLA 8.Evaluación de la seguridad mediante métricas de impacto de ataques.
que se seleccionan diferentes contramedidas dependiendo de los
vectores de amenaza considerados en el análisis.
La Tabla 8(b) muestra que inicialmente, la calificación general es
relativamente baja, pero aumentó significativamente cuando el atacante
puede comprometer con éxitoOFS1a medida que aumentaba la postura
de seguridad. Para la contramedida, observamos que la implementación
del parche de Linux disminuyó más la postura de seguridad, ya que
redujo la mayoría de las rutas de ataque en comparación con otras
contramedidas que consideramos.
Utilizamos tres métodos diferentes de evaluación de la seguridad
y observamos los efectos de diferentes contramedidas. Network
Centrality Measure (NCM) evalúa la importancia de los nodos que
forman el sistema en red. Los nodos con valores altos de NCM
contribuyen de manera más significativa a la evaluación de la
seguridad, ya que es más probable que se usen que otros nodos en
diferentes rutas de ataque. Por lo tanto, asumimos que una
contramedida es más efectiva si reduce la varianza de los valores
NCM de cada nodo. En segundo lugar, evaluamos la seguridad
utilizando el puntaje de vulnerabilidad, particularmente el número
de rutas, la longitud de la ruta, la probabilidad de éxito del ataque y
el riesgo del sistema. Esta evaluación de seguridad se centra en la
gravedad de cada vulnerabilidad y evalúa sus efectos combinados
cuando se considera un conjunto de vulnerabilidades para un
ataque. Por eso, una contramedida que minimice el puntaje de
vulnerabilidad es la más efectiva. Por último, las métricas de impacto
de ataque consideran un plano 2D teniendo en cuenta la tasa de
ataque y el impacto. La efectividad de las contramedidas se evalúa
en función de la cantidad de tasa de ataque reducida y el impacto.
En nuestra evaluación, observamos que implementar el DPI/CFR
es el mas e conteo efectivo mi
medir licenciado en Letrass ed en lo anterior
tres de seguridad evaluación étodos
metro como entero. En detalle,
ying th miDPI/CFR r mi
implementar ducedido el numero de ataque
caminos la mo st, atenuante metro escenarios de ataque ble
cualquier posibilidad
para nuestra experiencia rsistema mental . esta hora como condujo a la alta-
metro
est pr obebé y de ataque y d riesgo rojo ución también. Sim-
Ilaramente, otros SDN y su s mi
la seguridad puede ser evaluado usando
la TV-HAR METRO .
VOLUMEN 7, 2019
V. DISCUSIÓN Y TRABAJO FUTURO
SDN es vulnerable a varias amenazas, tanto nuevas como existentes, que
pueden reducir el nivel de seguridad de SDN. Para evaluar el impacto de
diferentes amenazas en SDN, propusimos un marco de evaluación de
seguridad para SDN. Nuestro enfoque único adopta modelos de
seguridad gráficos denominados TV-HARM, que modelan y evalúan la
postura de seguridad de SDN con respecto a los vectores de amenazas
identificados. Evaluamos la seguridad de SDN a través del modelado y
análisis de amenazas y evaluamos la efectividad de diferentes
contramedidas en nuestro análisis experimental. En esta sección,
analizamos las limitaciones y el trabajo futuro relacionado con la
evaluación de seguridad de SDN.
A. IMPLEMENTACIÓN DEL MARCO
El marco se puede implementar en el plano de control sin ninguna
entrada operativa de otros componentes de SDN. Este marco
funcionará de forma pasiva sin interferir con las operaciones de SDN
y no depende de los componentes de SDN. Esto garantiza que el
marco sea transparente para las operaciones de SDN, así como la
protección del marco contra manipulaciones. Esta es una ventaja
para integrar la función de evaluación de seguridad en la tecnología
SDN. Sin embargo, la implementación debe considerar que el
atacante no puede explotar los datos recopilados, y el acceso al
módulo del marco está restringido desde el plano de datos para
limitar también el acceso a los resultados de la evaluación de
seguridad por parte de personas no autorizadas.
El marco también se puede implementar como una herramienta de
software independiente, con interfaces adecuadas para recopilar los datos
necesarios de SDN (p. ej., recopilar el control y los flujos de datos para evaluar
las amenazas descritas en las secciones anteriores). Luego, la herramienta
puede ser un complemento del plano de control como un servicio para evaluar
la postura de seguridad de SDN. Esto proporcionará la portabilidad de la
herramienta y la capacidad de ampliar sus funciones para incorporar otras
tecnologías de red. Para minimizar el riesgo de que se altere el marco, la
interacción con la entrada y salida del marco debe estar restringida solo a
entidades confiables (por ejemplo, administradores de seguridad). Además, las
interfaces deben diseñarse cuidadosamente para garantizar que los atacantes
no puedan obtener acceso a los resultados de la evaluación de seguridad de
SDN al explotar las vulnerabilidades de la interfaz.
B. GESTIÓN DE SEGURIDAD SDN
El marco proporciona un enfoque para evaluar la seguridad de SDN
teniendo en cuenta varios componentes de SDN y vectores de amenazas.
Sin embargo, para mejorar la seguridad de SDN, también se pueden
incorporar varias técnicas y herramientas. Por ejemplo, Nayaky otros. [17]
propuso un sistema de seguridad llamado Resonancia, que puede
actualizar las políticas de control de acceso de forma dinámica mediante
el nivel de flujo y la información de alerta en tiempo real. El marco
propuesto puede beneficiarse y proporcionar una mejor selección de
contramedidas al combinar las características de esas técnicas y
herramientas. Además, la capacidad de explotación de las
vulnerabilidades que puedan existir en el controlador SDN se puede
considerar para la priorización de la métrica, que se investigará en
nuestro trabajo futuro.
137443

C. DISTINTOS CONTROLADORES SDN
Nos fijamos en el usoODLyONOSpara el controlador SDN, pero
no tuvimos en cuenta su diferencia funcional en el análisis de
seguridad, lo que puede afectar la evaluación de seguridad y la
selección de contramedidas. Además, existen varios otros
controladores SDN con diversas funcionalidades y capacidades
[39], [40]. Diferentes controladores SDN tienen diferentes
funciones de control de seguridad, que también pueden afectar
el análisis de seguridad. Investigaremos diferentes
funcionalidades SDN y sus efectos en la evaluación de seguridad
en nuestro trabajo futuro.
D. GESTIÓN DE LA ESCALABILIDAD
Debido a la capacidad de SDN para admitir una gestión de redes
eficiente, SDN puede escalar mucho más que las redes tradicionales.
Por lo tanto, también es importante que el modelo de seguridad
utilizado también pueda escalar y capturar una gran cantidad de
usuarios, dispositivos y componentes de SDN para proporcionar una
evaluación de seguridad completa. Aunque el modelo base HARM
proporciona escalabilidad [13], no consideramos cómo TV-HARM
podría escalar con respecto al tamaño de SDN, especialmente
cuando se vuelve grande. Investigaremos la evaluación de la
escalabilidad y la aplicabilidad de TV-HARM para SDN de gran
tamaño en nuestro trabajo futuro.
VI. CONCLUSIÓN
En este documento, hemos resumido las posibles nuevas amenazas
en SDN. Hemos llevado a cabo un modelado de amenazas y una
evaluación de seguridad para evaluar la seguridad de SDN. Hemos
utilizado tres métricas de seguridad, incluida la Medida de
centralidad de red, la puntuación de vulnerabilidad y las métricas de
impacto de ataque utilizando el modelo de amenaza con TV-HARM.
Para nuestro análisis experimental, hemos observado diferentes
contramedidas y su efectividad, demostrando la aplicabilidad del
marco y TV-HARM para capturar varios vectores de amenazas en
SDN. Por lo tanto, el marco propuesto se puede utilizar para evaluar
de manera efectiva la seguridad de SDN teniendo en cuenta varios
vectores de amenazas de SDN.
REFERENCIAS
[1] D. Kreutz, FMV Ramos, PE Veríssimo, CE Rothenberg,
S. Azodolmolky y S. Uhlig, ''Redes definidas por software: un estudio
exhaustivo''proc. IEEE, vol. 103, núm. 1, págs. 14 a 76, enero de 2015.
[2] X. Sun y N. Ansari, ''EdgeIoT: computación perimetral móvil para Internet de las
cosas''Común IEEE. revista, vol. 54, núm. 12, págs. 22 a 29, diciembre de 2016.
[3] S. Achleitner, N. Bartolini, T. He, T. La Porta y DZ Tootaghaj, ''Configuración de red
rápida en redes definidas por software''IEEE Trans. Neto. Gestión de servicios.,
vol. 15, núm. 4, págs. 1249–1263, diciembre de 2018.
[4] M. Maier, M. Chowdhury, BP Rimal y DP Van, "La Internet táctil: visión,
avances recientes y desafíos pendientes",Común IEEE. revista, vol. 54,
núm. 5, págs. 138–145, mayo de 2016.
[5] J. Wu, S. Luo, S. Wang y H. Wang, ''NLES: un nuevo esquema de extensión de por vida
para sistemas ciberfísicos críticos para la seguridad que utilizan SDN y NFV''. Cosas de
Internet IEEE J., vol. 6, núm. 2, págs. 2463–2475, abril de 2019.
[6] G. Li, J. Wu, J. Li, K. Wang y T. Ye, ''Servicio de partición de recursos inteligentes basada en
la popularidad para la Internet de las cosas industrial habilitada para la computación
en la niebla''Trans. IEEE. Ind. Informat., vol. 14, núm. 10, págs. 4702–4711, octubre de
2018.
[7] D. Kreutz, FM Ramos y P. Verissimo, ''Hacia redes definidas por software
seguras y confiables'', enproc. 2do ACM SIGCOMMWorkshop Hot Topics
Softw. Red definida (SDN caliente), agosto de 2013, págs. 55–60.
137444
T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad
[8] S. Hong, L. Xu, H. Wang y G. Gu, "Envenenamiento de la visibilidad de la red en
redes definidas por software: nuevos ataques y contramedidas", enproc. Neto.
Distribuir sist. Seguro Síntoma (NDSS), 2015, págs. 8–11.
[9] S. Lee, C. Yoon, C. Lee, S. Shin, V. Yegneswaran y PA Porras, ''DELTA: un
marco de evaluación de seguridad para redes definidas por software'', en
proc. Neto. Distribuir sist. Seguro Síntoma (NDSS), 2017, págs. 1 a 15.
[10] P. Kazemian, M. Chang, H. Zeng, G. Varghese, N. McKeown y
S. Whyte, "Comprobación de políticas de red en tiempo real mediante análisis de
espacio de cabecera", enproc. 10º Simposio USENIX. La red. sist. Implemento de
diseño. (NSDI), 2013, págs. 99–111.
[11] B. Kordy, L. Piètre-Cambacédès y P. Schweitzer, ''Modelado de ataque y defensa basado
en DAG: no se pierda el bosque para los árboles de ataque''.computar ciencia Rvdo.,
vols. 13–14, págs. 1–38, noviembre de 2014.
[12] JB Hong, DS Kim, C.-J. Chung y D. Huang, ''Una encuesta sobre la usabilidad y las
aplicaciones prácticas de los modelos gráficos de seguridad''.computar ciencia Rvdo.,
vol. 26, págs. 1 a 16, noviembre de 2017.
[13] JB Hong y DS Kim, "Hacia un análisis de seguridad escalable mediante modelos de
seguridad de varias capas",J. Red. computar aplicación, vol. 75, págs. 156–168,
noviembre de 2016.
[14] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown y S.
Shenker, ''NOX: Hacia un sistema operativo para redes''.
Cómputo ACM SIGCOMM. común Rvdo., vol. 38, núm. 3, págs. 105 a 110, 2008.
[15] M. Casado, T. Garfinkel, A. Akella, MJ Freedman, D. Boneh,
N. McKeown y S. Shenker, ''SANE: una arquitectura de protección para redes
empresariales'', enproc. XV Conferencia USENIX Secur. Síntoma (Seguridad
USENIX), 2006, págs. 137–151.
[16] J. Matias, J. Garay, A. Mendiola, N. Toledo y E. Jacob, ''FlowNAC: control de
acceso a la red basado en flujo'', enproc. 3er euro Taller Softw. Red
definida (EWSDN), septiembre de 2014, págs. 79–84.
[17] AK Nayak, A. Reimers, N. Feamster y R. Clark, "Resonancia: control de
acceso dinámico para redes empresariales", enproc. 1er Taller ACM Res.
Red empresarial (REYEZUELO), 2009, págs. 11 a 18.
[18] H. Cheng, J. Liu, J. Mao, M. Wang y J. Chen, "OSCO: una plataforma de flujo abierto
compatible con seguridad mejorada abierta", enproc. En t. Conf. Algoritmos
Inalámbricos, Syst., Appl. (ERA UN). Cham, Suiza: Springer, 2018, págs. 66–77.
[19] SW Shin, P. Porras, V. Yegneswaran, M. Fong, G. Gu y M. Tyson, ''FRESCO:
Servicios de seguridad componibles modulares para redes definidas por
software'', enproc. Neto. Distribuir sist. Seguro Síntoma (NDSS), 2013, págs. 1 a
16.
[20] CJ Chung, P. Khatkar, T. Xing, J. Lee y D. Huang, ''NICE: Detección de intrusos en la
red y selección de contramedidas en sistemas de redes virtuales''.Trans. IEEE.
Depender. Segundo. computar, vol. 10, núm. 4, págs. 198–211, julio de 2013.
[21] U. Ghosh, P. Chatterjee y S. Shetty, ''Un marco de seguridad para redes eléctricas
inteligentes habilitadas para SDN'', enproc. 37° IEEE internacional. Conf. Distribuir
computar sist. Talleres (ICDCSW), junio de 2017, págs. 113–118.
[22] A. Chowdhary, S. Pisharody, A. Alshamrani y D. Huang, "Marco de seguridad
basado en juegos dinámicos en entornos de red en la nube habilitados para
SDN", enproc. Int. ACM Taller de Seguridad. suave Red definida Neto.
Virtualización de funciones (SDN-NFVSec), 2017, págs. 53–58.
[23] Y. Shi, F. Dai y Z. Ye, ''Un marco de seguridad mejorado de red definida por
software basado en cifrado basado en atributos'', enproc. 4to Int. Conf. sist.
Informar. (ICSAI), noviembre de 2017, págs. 965–969.
[24] PA Porras, S. Cheung, MW Fong, K. Skinner y V. Yegneswaran, ''Asegurar la
capa de control de red definida por software'', enproc. Neto. Distribuir
sist. Seguro Síntoma (NDSS), 2015, págs. 1 a 15.
[25] G. Stabler, A. Rosen, S. Goasguen y K.-C. Wang, ''Implementación de IP elástica y
grupos de seguridad mediante OpenFlow'', enproc. 6to Int. Tecnología de
virtualización de talleres. Distribuir computar Fecha (VTDC), 2012, págs. 53–60.
[26] G. Yao, J. Bi y P. Xiao, ''Solución de validación de direcciones de origen con
arquitectura OpenFlow/NOX'', enproc. 19º IEEE Internacional. Conf. Neto.
Protocolos (ICNP), octubre de 2011, págs. 7–12.
[27] JB Hong y DS Kim, "Análisis de seguridad escalable en el modelo de
representación de ataques jerárquicos usando medidas de centralidad", en
proc. 43º año. Internacional IEEE/IFIP Conf. Sistema confiable Neto. Taller (DSN-
W), junio de 2013, págs. 1 a 8.
[28] JB Hong y DS Kim, "Análisis de rendimiento de modelos de representación de
ataques escalables", enSeguridad y protección de la privacidad en los sistemas
de procesamiento de información, LJ Janczewski, HB Wolfe y S. Shenoi, eds.
Berlín, Alemania: Springer, 2013, págs. 330–343.
VOLUMEN 7, 2019
T.Eomet al.: enfoque sistemático para el modelado de amenazas y el análisis de seguridad
[29] JB Hong, T. Eom, JS Park y DS Kim, ''Análisis de seguridad escalable utilizando un
enfoque de partición y fusión en una infraestructura como nube de servicios'',
enproc. IEEE 11 Int. Conf. Cómputo autónomo de confianza. (ATC), diciembre de
2014, págs. 50–57.
[30] R. Deraison, (2002).El Proyecto NESSUS. [En línea]. Disponible: http://
www.nessus.org
[31] M. Schiffman, A. Wright, D. Ahmad y G. Eschelbeck, ''El sistema de puntuación de
vulnerabilidad común'', Nat. Infraestructura Consejo Asesor, Vulnerabilidad
Discl. Trabajar. Grupo, Subgrupo de Puntuación de Vulnerabilidad, 2004.
[32] Y. Qian, W. You y K. Qian, ''Análisis de vulnerabilidad de FlowVisor'', en proc.
Síntoma IFIP/IEEE. Integrar Neto. Gestión de servicios. (SOY), mayo de 2017,
págs. 867–868.
[33] T.-H. Nguyen y M. Yoo, ''Análisis de los ataques del servicio de descubrimiento de enlaces en el
controlador SDN'', enproc. En t. Conf. información Neto. (ICONO), enero de 2017, págs. 259–
261.
[34] M. Shakil, AFY Mohammed, H. Oh y JK Choi, ''DREAD-R: evaluación de la
gravedad del controlador ONOS SDN'', enproc. En t. Taller Tendencias
Multidisciplinares Artif. Intel. (MIWAI), 2017, págs. 323–330.
[35] SE Yusuf, M. Ge, JB Hong, HK Kim, P. Kim y DS Kim, "Modelado y
análisis de seguridad de redes empresariales dinámicas",
enproc. Internacional IEEE Conf. computar información Tecnología (CIT), diciembre de 2016,
págs. 249–256.
[36] M. Ge, JB Hong, W. Guttmann y DS Kim, "Un marco para automatizar el análisis de
seguridad del Internet de las cosas",J. Red. computar aplicación, vol. 83, págs.
12 a 27, septiembre de 2017.
[37] T. Eom, JB Hong, JS Park y DS Kim, "Modelado y análisis de seguridad de un
servicio web basado en SDN", enproc. En t. Conf. Arquitectura de
algoritmos. Proceso Paralelo. (ICAP), 2015, págs. 746–756.
[38] A. Chowdhary, S. Pisharody y D. Huang, ''Solución MTD escalable basada
en SDN en red en la nube'', enproc. Taller ACM Defensa de objetivos
móviles (MTD), 2016, págs. 27–36.
[39] R. Khondoker, A. Zaalouk, R. Marx y K. Bayarou, ''Comparación basada en características y
selección de controladores de redes definidas por software (SDN)''
enproc. Congreso Mundial computar aplicación información sist. (WCCAIS), enero de 2014,
págs. 1 a 7.
[40] K. Phemius, M. Bouet y J. Leguay, ''DISCO: Controladores SDN multidominio
distribuidos'', enproc. Red IEEE. oper. Administrar. Síntoma (NOM), mayo de
2014, págs. 1 a 4.
TAEHOON EOMrecibió los títulos de licenciatura y
maestría de la Universidad Aeroespacial de Corea,
Corea, donde actualmente está cursando el doctorado.
grado con el Departamento de Ingeniería Informática.
Sus intereses de investigación incluyen el modelado de
seguridad y el análisis de redes definidas por software.
JIN B HONGrecibió el Ph.D. Licenciado en Informática
por la Universidad de Canterbury, Nueva Zelanda.
Actualmente es profesor en el Departamento de Ciencias
de la Computación e Ingeniería de Software de la
Universidad de Australia Occidental, Australia. Sus
intereses de investigación incluyen el modelado y
análisis de seguridad de computadoras y redes, incluida
la computación en la nube, SDN e IoT, y defensa de
objetivos en movimiento.
VOLUMEN 7, 2019
SEONGMO ANrecibió los títulos de licenciatura y
maestría de la Universidad Aeroespacial de Corea, Corea
del Sur, donde actualmente está cursando el doctorado.
grado con el Departamento de Ingeniería Informática.
Sus intereses de investigación incluyen el modelado de
seguridad y el análisis de computación en la nube.
PARQUE JONG SOUrecibió la maestría en ingeniería
eléctrica e informática de la Universidad Estatal de
Carolina del Norte, en 1986, y el Ph.D. Licenciado en
Ingeniería Informática de la Universidad Estatal de
Pensilvania, en 1994. De 1994 a 1996, fue Profesor
Asistente en el Departamento de Ingeniería Informática
de la Universidad Estatal de Pensilvania. Fue el
presidente de KSEA Central PA, Chapter. Actualmente es
profesor titular en el Departamento de Software de la
Universidad Aeroespacial de Corea.
versidad Sus intereses de investigación actuales incluyen seguridad de la información,
sistemas integrados y tecnología blockchain. También está interesado en la
exploración de recursos mediante el uso de aeronaves, satélites y microrobots. Es
miembro del IEICE. Es miembro de la Junta Ejecutiva del Instituto Coreano de
Criptología y Seguridad de la Información y de la Sociedad de Aseguramiento de la
Información de Corea.
DONG SEONG KIMrecibió el Ph.D. Licenciado en enfoque
de seguridad de la Universidad Aeroespacial de Corea,
en 2008. Fue becario visitante de la Universidad de
Maryland, College Park, MD, EE. UU., en 2007. Dirigió el
Grupo de Seguridad Cibernética, Universidad de
Canterbury (UC), Christchurch, Nueva Zelanda , de
agosto de 2011 a enero de 2019, donde fue profesor
titular/profesor de ciberseguridad en el Departamento
de Ciencias de la Computación e Ingeniería del Software.
Desde junio de 2008 hasta
Julio de 2011, ocupó una posición posdoctoral en la Universidad de Duke, EE.
UU. Actualmente es profesor asociado de ciberseguridad en la Escuela de
Tecnología de la Información e Ingeniería Eléctrica de la Universidad de
Queensland, Brisbane, Australia. Sus intereses de investigación son la
seguridad cibernética y la confiabilidad de varios sistemas y redes. Es miembro
del consejo editorial de ElsevierInformática y Seguridad. Fue copresidente
general de la 24.ª Conferencia de Australasia sobre seguridad y privacidad de la
información (ACISP2019) y presidente general del 22.º Simposio internacional
sobre informática fiable de la IEEE Pacific Rim (PRDC 2017). Se desempeñó
como copresidente del programa para conferencias/talleres internacionales,
incluidos IEEE TrustCom2019, IEEE ICIOT2019 y GraMsec2015.
137445