ministerio de defensa

MINISTERIO DE DEFENSA
CD&E CIBERDEFENSA
DOCUMENTO DE DISEÑO DEL
EXPERIMENTO
01/12/2012
Este documento sirve de guía para el desarrollo del proyecto de experimentación del Concepto
de Ciberdefensa Inicial. Describe cada uno de los objetivos perseguidos, los elementos de
análisis, el escenario y los recursos que serán necesarios. Parte de los EXCLUSIVO PARA EL
EQUIPO DE CONTROL, ya que su conocimiento por parte del equipo de participantes puede
afectar al resultado del experimento.
Página | 1
DDE V 0.4
10/10/2012
MINISTERIO DE DEFENSA
INDICE
Contenido
1.
INTRODUCCIÓN. .................................................................................................................... 4
2.
PROPÓSITO DE LA EXPERIMENTACIÓN. ................................................................................ 4
3.
PLANTEAMIENTO DEL PROBLEMA Y SOLUCIONES................................................................ 4
3.1.
Enunciado del Problema. .................................................................................................. 4
3.2.
Descripción del Problema. ................................................................................................ 4
3.3.
Solución propuesta............................................................................................................ 5
3.4.
Hipótesis General del Proyecto ......................................................................................... 5
4.
OBJETIVOS DEL EXPERIMENTO. ............................................................................................ 5
4.1.
Generalidades sobre los Objetivos.................................................................................... 6
4.2.
Desarrollo de los Elementos Esenciales de Análisis (EEA)................................................. 6
4.3.
Objetivos del Evento. ........................................................................................................ 8
5.
METODOLOGÍAS. ................................................................................................................. 12
5.1.
6.
Metodología del Evento. ................................................................................................. 12
ESCENARIO .......................................................................................................................... 14
6.1.
Generalidades ................................................................................................................. 14
6.2.
Consideraciones sobre el escenario ................................................................................ 15
7.
EVALUACIÓN DE RIESGOS. .................................................................................................. 17
7.1.
Generalidades. ................................................................................................................ 17
7.2.
Riesgos del evento. ......................................................................................................... 17
8.
PLAN DE RECOGIDA Y ANÁLISISDE DATOS. ......................................................................... 18
8.1.
Relación entre el Plan de Análisis y el Plan de Recogida de Datos. ................................ 18
8.2.
Plan de Análisis de Datos. ............................................................................................... 19
8.3.
Plan de Recolección de Datos ......................................................................................... 19
9.
ANEXO A: ARQUITECTURA DEL EVENTO. DIAGRAMAS. ...................................................... 21
10.
ANEXO B: ORGANIZACIÓN Y RECURSOS NECESARIOS. ................................................... 26
11.
ANEXO C: PLANIFICACIÓN. .............................................................................................. 29
12.
ANEXO D: ANALISIS RIESGOS............................................................................................. 1
13.
ANEXO E: PLAN DE ANÁLISIS Y RECOLECCIÓN DE DATOS ................................................. 1
13.1.
Introducción .................................................................................................................. 1
13.2.
Procedimiento de análisis ............................................................................................. 1
Página | 2
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
13.3.
Informes de resultados ................................................................................................. 1
13.4.
Recolección de Datos. ................................................................................................... 1
14.
ANEXO F: SECUENCIA DE VERIFICACIÓN DEL EXPERIMENTO DESDE EL PUNTO DE VISTA
DE SISTEMAS. .............................................................................................................................. 15
14.1.
Servicios considerados a nivel de sistemas. ................................................................ 15
14.2.
Caracterización de los objetivos a realizar por cada sistema participante. ................ 15
14.3.
Proceso de secuenciación del experimento a nivel de sistemas. ............................... 32
14.4.
Fases de ataque desde el punto de vista de sistemas. ............................................... 33
Página | 3
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
CONCEPTO CIBERDEFENSA
DOCUMENTO DISEÑO EXPERIMENT0 DEL PROYECTO CD&E.
(DDE CIBERDEF)
1. INTRODUCCIÓN.
El Documento de Descripción del Proyecto (DDP) del Concepto de Ciberdefensa es el
documento guía para el desarrollo del proyecto de experimentación del Concepto
Ciberdefensa del Ejército. El DDP describe los objetivos perseguidos, los productos a
desarrollar, el plan de actividades, los eventos de los que consta el Proyecto y los recursos
que previsiblemente serán necesarios.
Además, el DDP anticipa la necesidad de experimentar el concepto a través de un evento:
Evento #1: Realización de un Experimento de Objetivo Limitado (LOE)de
Ciberdefensa en el marco de un escenario virtual que simule un posible despliegue de
una Brigada con apoyos de guerra electrónica, con todos los sistemas CIS desplegables
del Ejército, como pueden ser el SIMACET, TALOS, GESTA, FFT, etc. Tiene por
objetoevaluar las soluciones de seguridad propuestas en el DDPy obtener aspectos
derivados del problema a incluir en el Concepto de Ciberdefensa a desarrollar.
Así mismo, el DDP identifica la necesidad de redactar un Documento de Diseño del
Experimento (DDE), que contenga toda la información necesaria para la preparación
deesteevento y su posterior ejecución.
2. PROPÓSITO DE LA EXPERIMENTACIÓN.
El presente proyecto de experimentación tiene por objeto determinar la validez de las
soluciones contenidas en el presente documento derivadas del DDP, así como extraer las
lecciones aprendidas que pudieran servir para depurar estas y futuras
soluciones,elaborandorecomendaciones para su posible implantación.
3. PLANTEAMIENTO DEL PROBLEMA Y SOLUCIONES.
3.1. Enunciado del Problema.
No existe variación respecto al problema enunciado en el DDP.
Incrementar el nivel de eficacia en el uso del ciberespacio en las operaciones militares
proponiendo mecanismos de mejora, lecciones aprendidas y buenas prácticas basándose
en el análisis del estado de seguridad de los sistemas CIS desplegables del Ejército.
3.2. Descripción del Problema.
En la actualidad la mayoría de los sistemas de mando y control e información militar, así
como determinados sistemas de combate y de control de plataformas y armas, están
conectados a través de redes militares de comunicaciones que, en mayor o menor medida,
también están expuestos a las diferentes amenazas que existen en el ciberespacio:
Página | 4
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
disponen de interconexiones a otros sistemas, ya sean OTAN, UE o de países aliados;
forman parte de una federación de redes en el ámbito operativo; o sus enlaces se realizan
en ciertas ocasiones a través de infraestructuras civiles, lo que complica el establecimiento
y mantenimiento de la seguridad.
Además, la futura adaptación de estos sistemas al concepto NEC incrementará la
capacidad de mando y control de los Ejércitos. Las nuevas plataformas aéreas ya disponen
de sistemas de comunicaciones para recibir y transmitir información constantemente; los
sistemas de defensa aérea son teleoperados por ordenador; los sistemas de inteligencia,
vigilancia y reconocimiento (ISR) recogen tanta información que el desafío está en obtener
los datos críticos; las unidades de infantería disponen de sistemas de comunicación de
banda ancha, sistemas de posicionamiento (FFT) y dispositivos de visión nocturna, en
todos ellos existen dispositivos de proceso que representan una fortaleza pues
incrementan la capacidad de combate, pero que también podrían convertirse en una
debilidad pues presentan vulnerabilidades, lo que exige la adopción de medidas para su
protección, con la consecuente y necesaria puesta en marcha de capacidades de
ciberdefensa.
3.3. Solución propuesta.
La solución propuesta consiste en:
 Realización de un Experimento de Objetivo Limitado (LOE) de ciberdefensa en el
marco de un escenario virtual que simule un posible despliegue de una Brigada con
apoyos de guerra electrónica, con todos los sistemas CIS desplegables del Ejército,
como pueden ser el SIMACET, TALOS, GESTA, FFT, etc.
Para la realización del experimento se proponen dos fases:
 Fase 1: Realización de actividades de Ciberdefensa en un escenario virtual que simule
el despliegue de una Brigada con los sistemas CIS tácticos normalmente utilizados. En
esta fase se llevarán a cabo las actividades necesarias para realizar los procesos de
ataque sobre los nodos objetivo de la red.
 Fase 2: Realización de actividades de Ciberdefensa en el escenario anterior
implementando las siguientes medidas de seguridad en cada uno de los nodos:
 Implantación de un firewall.
 Implantación de un IDS.
 Implantación de un sistema de gestión de log’s y correlador de eventos.
 Implantación de un CERT para responder a los incidentes de seguridad que
ocurran en la red.
En esta fase se realizarán las mismas actividades anteriormente realizadas en la fase 1.
3.4. Hipótesis General del Proyecto
La hipótesis general del experimento, que se depurará durante la fase de diseño, es:
“La consecución de los objetivos de experimentación y, por tanto, la aplicación de la
solución propuesta, mejorará el nivel de seguridad en los sistemas CIS tácticos del Ejército”.
4. OBJETIVOS DEL EXPERIMENTO.
Página | 5
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
4.1. Generalidades sobre los Objetivos.
El conjunto de los Objetivospersigue la comprobación de la validez de los componentes de
la solución propuesta a la vez que se extraen lecciones aprendidas que sirvan para depurar
las soluciones. Cada uno de ellos se centra por lo general en una de las componentes de la
solución.
Para el logro de cada objetivo, se plantea una serie de pruebas para obtener una visión del
problema. Por medio del análisissebuscaráconocer el estado actual de la seguridad de los
sistemas CIS tácticos del Ejército y cómo influye la implantación de las medidas de
seguridad propuestas en el estado de seguridad.
A su vez, cada Objetivosecorresponde con varios Elementos Esenciales de Análisis (EEA).
Los EEAs son los diferentes aspectos de cada Objetivo que sirven como elementos
principales del foco analítico y permiten evaluar la bondad de la solución propuesta.
4.2. Desarrollo de los Elementos Esenciales de Análisis (EEA).
Los EEAs están orientados a alcanzar los Objetivos mediante la determinación del grado de
cumplimiento de las Medidas de Efectividad que se determinan en el Plan de Análisis y
Recolección de Datos (DCAP).
Se ha determinado que existen Elementos Esenciales de Análisis que dependen de
métricas proporcionadas por los elementos atacantes del experimento (señalizados con el
color rojo), otros dependen de medidas de efectividad obtenidas en los sistemas atacados
(color verde) y por último es necesario obtener datos de atacantes y atacados para
conseguir analizar los restantes (color naranja).
Para soportar estos Elementos Esenciales de Análisis serán necesarios obtener una serie de
datos por cada sistema.
Al comienzo de cada fase (I, II) y hasta el paso Análisis de Vulnerabilidades se recopilará la
siguiente información:
Número de puertos/servicios abiertos.
Códigos CVSS (Common Vulnerability Scoring) en estos servicios.
Número de vulnerabilidades detectadas por cada máquina virtual que componen
un nodo de nivel ALTO, MEDIO y BAJO.
Se deberán apoyar estos datos con los ficheros proporcionados por las herramientas
Nessus y Nmap.
Posteriormente, ya en el paso de “Proceso de ataque” se ejecutarán sucesivos ataques
basados en la información recopilada por las herramientas ejecutadas en los pasos previos.
Para cada ataque se deberá registrar el momento del tiempo en el que se produce el
ataque, contra quién se produce y de qué tipo es. Ello proporcionará al final la siguiente
información desde el punto de vista del atacante:
Número de ataques realizados
Número de ataques lanzados por los atacantes a un determinado ordenador de la
red objetivo.
Número de ataques exitosos
Número de ataques que finalmente han conseguido llegar a su destino final.
Página | 6
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Número de ataques parcialmente exitosos
Número de ataques que, por unas causas u otras, se han quedado a mitad del
camino.
Tiempo consumido por ataque  Tiempo consumido por tipo de ataque
Tiempo que ha llevado el llevar a cabo ese ataque concreto. Sumando los tiempos
de todos los ataques del mismo tipo se podrá concluir los tiempos consumidos por
tipo de ataque.
Tiempo consumido en cada fase
En base a este número se podrán obtener el tiempo por cada tipo de ataque, los
tiempos consumidos en cada fase del ejercicio y los tiempos acumulados hasta una
determinada fase.
Tiempo que ha llevado conseguir el éxito
Tiempo que le ha llevado al atacante tener éxito en su ataque.
Por otra parte, desde la plataforma de sistemas atacados, se deberá proporcionar el
ataque detectado, en qué momento del tiempo se produce, el evento que provoca la
sospecha y qué tipo de medidas defensivas se ejecutan para abortar el ataque. Estos
datos, al final, proporcionarán la siguiente información:
Número de ataques detectados
Serán los ataques que, desde el punto de vista de los sistemas atacados, se
consideren detectados.
Número de acciones defensivas tomadas por cada ataque
Debido a esa detección se pondrán en marcha mecanismos de defensa que
intentarán neutralizar esos ataques
Tiempo de inactividad de un servicio
Proporciona la inactividad de un servicio concreto y no de todo el sistema en su
conjunto.
Tiempo de inactividad del sistema atacado  Tiempo de recuperación
Como posibles efectos de un ataque se pueden producir la caída total o parcial del
sistema atacado o la pérdida de información. El tiempo de inactividad del sistema
es una medida de referencia de la magnitud del ataque, así como el tiempo en el
que todos los datos son restaurados para continuar con el normal funcionamiento
del sistema.
Con todos estos datos será posible calcular las Medidas de Efectividad que se definen
como:
Eficiencia defensiva
Es la medida de como de frecuente un ataque es interrumpido frente a lo
frecuente que la acción defensiva es tomada.
Se calcula como: ((Número total de ataques observados - número de ataques con
éxito observados) / número de acciones defensivas tomadas ) * 100%
Página | 7
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Cuando todos los ataques tienen éxito la eficiencia defensiva es cero. Para
defensas de prioridad, la eficiencia varía desde el 0% hasta el 100%. Para las
reactivas la eficiencia tiene de a ser mayor o igual al 100% (el mínimo ocurre si la
probabilidad de prevención de ataque es del 100%)
Factor de Defensa
Relación entre el intervalo de defensa prioritaria a la duración nominal de un tipo
particular de ataque. Proporciona una medida de la velocidad relativa de ejecución
entre defensa y ataque.
Se calcula como la razón entre la Duración de un ataque nominal y el intervalo de
defensa prioritaria.
Cuando las acciones de defensa prioritaria se aceleran (su intervalo se acorta), la
probabilidad de que un ataque triunfe disminuye.
De esta forma, se pueden entender las medidas de efectividad como elementos
comparativos de unos sistemas a otros y dentro de los mismos sistemas a cuando se
aplican medidas defensivas (Fase II) con respecto a lo ocurrido en la fase sin securizar
(Fase I).
Una representación de todos los datos y cálculos que con ellos se realizan se puede ver
en la siguiente figura:
Figura 1. Métricas y Medidas de Efectividad.
4.3. Objetivos del Evento.
OBJ 1.
Comprobar el estado de seguridad de los sistemas en cuanto al número de
vulnerabilidades detectadas.
Página | 8
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Este objetivo se articula en los siguientes EEAs:
EEA#1.1.
Superficie efectiva de ataque.
EEA#1.2
Tipos de puertos abiertos.
EEA# 1.3
Vulnerabilidades detectadas de nivel ALTO por cada máquina virtual que
compone un nodo mediante la herramienta Nessus.
EEA#1.4
EEA#1.5
Vulnerabilidades detectadas de nivel MEDIO por cada máquina virtual que
compone un nodo mediante la herramienta Nessus.
Vulnerabilidades detectadas de nivel BAJO por cada máquina virtual que
compone un nodo mediante la Herramienta Nessus.
Tabla 1 Elementos Esenciales de Análisis del Objetivo 1.
EEA#1.1 Se define la superficie efectiva de ataque para cada nodo como el número
de puertos y, por lo tanto, servicios detectados en comparación con el
total.
Se calculará como la razón entre el número de puertos abiertos y el
número de puertos disponibles total en cada nodo. Lo deseable, desde el
punto de vista de la defensa es que este parámetro sea lo más bajo posible
con lo cual se debería intentar que el número de puertos abiertos sea el
menor posible.
EEA#1.2 Será la tipología de los puertos detectados. Para ello se obtendrá los
códigos asignados en CVSS (Common Vulnerability Scoring System) a las
vulnerabilidades conocidas en estos servicios.
EEA#1.3 | EEA#1.4 | EEA#1.5 serán las vulnerabilidades detectadas para cada tipo
respectivamente ALTO, MEDIO y BAJO.
La criticidad de las vulnerabilidades es importantísima. Es mucho más
grave disponer de una vulnerabilidad de tipo ALTO que de muchas
vulnerabilidades de tipo BAJO.
OBJ 2.
Evaluar la capacidad de monitorización del estado de seguridad de los sistemas.
Este objetivo se articula en el siguiente EEA:
EEA # 2.1
Detección de ataques.
Tabla 2 Elemento Esencial de Análisis del Objetivo 2.
EEA#2.1 Será la relación del número de ataques detectados frente al número total
de ataques realizados en cada uno de los sistemas atacados.
Desde el punto de vista de la Defensa cuanto más alto sea este número
mejor.
OBJ 3.
Realización de ataques a los sistemas aplicando las fases de escaneo,
enumeración y ataque.
Página | 9
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Este objetivo se articula en los siguientes EEAs:
EEA # 3.1
Efectividad de los ataques
Tabla 3 Elemento Esencial de Análisis del Objetivo 3.
EEA#3.1 Para cada uno de los nodos habrá que estudiar:
cuántos de los ataques han tenido éxito. Es decir, han pasado por todas las
fases y han logrado su objetivo final. Se calcula como el número de ataques
con éxito entre el número total de ataques.
cuántos de ellos han tenido un éxito parcial. Se entiende por éxito parcial
cuando nose llega a la última fase pero se ha transitado por las fases
previas. Se calcula como el número de ataques con éxito parcial entre el
número total de ataques. Caracteriza la presencia de un ataque en un
sistema. Si el número de ataques con éxito parcial es mayor o igual que el
número de ataques con éxito entonces la probabilidad de los parciales es
también mayor.
cuánto tiempo han empleado los atacantes en cada una de las
fases.Teniendo los tiempos empleados en las fases T1 a Tn. El tiempo
acumulativo hasta cada fase será la suma de todos los tiempos desde la
primera a la correspondiente fase. La media será ese número dividido por
el tiempo total que se ha dedicado a esa fase. Incrementar el tiempo que
un ataque emplea en sus fases preparatorias así como el cambio de tiempo
gastado en las fases tempranas.
Cuánto ha durado un ataque exitoso. Se corresponde con el tiempo que ha
sido consumido para ejecutar desde la primera fase hasta la última. El
tiempo medio de tiempo de ejecución de un ataque es igual a la suma de
los distintos ataques dentro de cada fase dentro de los que han sido
exitosos. El efecto de las defensas puede ser observado mediante la
comprensión o expansión de este tiempo frente a una línea de tiempos
nominal de un ataque.
OBJ 4.
Evaluar la capacidad de manejo de incidentes/respuesta.
Este objetivo se articula en el siguiente EEA:
EEA # 4.1
Evaluación de la capacidad de recuperación del sistema frente a desastres y
perturbaciones.
Tabla 4 Elemento Esencial de Análisis del Objetivo 4.
EEA#4.1 Habrá que medir el impacto del ataque en el sistema atacado. Cuánto
tiempo de inactividad le ha provocado y, por otra parte, el tiempo que ha
empleado en atacante para producir ese desastre.
OBJ 5.
Realizar análisis de registros y análisis forense.
Página | 10
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Este objetivo se articula en el siguiente EEA:
EEA # 5.1
Número de ataques identificados por sistema para conseguir un registro
válido y un análisis forense significativo.
Tabla 5 Elemento Esencial de Análisis del Objetivo 5.
EEA#5.1 Vendrá representado por el número de ataques identificados suficientes
como para considerar una muestra significativa.
OBJ 6.
Implantación de puertas traseras en los sistemas.
Este objetivo se articula en el siguiente EEA:
EEA # 6.1
Efectividad de los ataques - Número de accesos exitosos en los sistemas de
destino desde el comienzo hasta el final del ejercicio.
Tabla 6 Elemento Esencial de Análisis del Objetivo 6.
EEA#6.1Para cada uno de los nodos habrá que estudiar después de la implantación
de las puertas traseras:
cuántos de los ataques han tenido éxito. Es decir, han pasado por todas las
fases y han logrado su objetivo final. Se calcula como el número de ataques
con éxito entre el número total de ataques.
cuántos de ellos han tenido un éxito parcial. Se entiende por éxito parcial
cuando no se llega a la última fase pero se ha transitado por las fases
previas. Se calcula como el número de ataques con éxito parcial entre el
número total de ataques. Caracteriza la presencia de un ataque en un
sistema. Si el número de ataques con éxito parcial es mayor o igual que el
número de ataques con éxito entonces la probabilidad de los parciales es
también mayor.
cuánto tiempo han empleado los atacantes en cada una de las
fases.Teniendo los tiempos empleados en las fases T1 a Tn. El tiempo
acumulativo hasta cada fase será la suma de todos los tiempos desde la
primera a la correspondiente fase. La media será ese número dividido por
el tiempo total que se ha dedicado a esa fase. Incrementar el tiempo que
un ataque emplea en sus fases preparatorias así como el cambio de tiempo
gastado en las fases tempranas.
Cuánto ha durado un ataque exitoso. Se corresponde con el tiempo que ha
sido consumido para ejecutar desde la primera fase hasta la última. El
tiempo medio de tiempo de ejecución de un ataque es igual a la suma de
los distintos ataques dentro de cada fase dentro de los que han sido
exitosos. El efecto de las defensas puede ser observado mediante la
comprensión o expansión de este tiempo frente a una línea de tiempos
nominal de un ataque.
Página | 11
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
OBJ 7.
Evaluar el comportamiento de los sistemas CIS tácticos del Ejército frente a
ataques DDoS.
Este objetivo se articula en el siguiente EEA:
EEA # 7.1
Evaluación de la capacidad de recuperación del sistema frente a desastres y
perturbaciones después de ataques DDoS.
Tabla 7 Elemento Esencial de Análisis del Objetivo 7.
EEA#7.1 Habrá que medir el impacto del ataque en el sistema atacado. Cuánto
tiempo de inactividad le ha provocado y, por otra parte, el tiempo que ha
empleado en atacante para producir ese desastre.
OBJ 8.
Comprobar el incremento del nivel de seguridad tras la implantación de medidas
de seguridad en los sistemas.
Este objetivo se articula en el siguiente EEAs:
EEA # 8.1
Superficie efectiva de ataque.
EEA # 8.2
Tipos de puertos abiertos.
EEA # 8.3
Vulnerabilidades detectadas de nivel ALTO por cada máquina virtual que
compone un nodo mediante la herramienta Nessus.
EEA # 8.6
Vulnerabilidades detectadas de nivel MEDIO por cada máquina virtual
que compone un nodo mediante la herramienta Nessus.
Vulnerabilidades detectadas de nivel BAJO por cada máquina virtual que
compone un nodo mediante la Herramienta Nessus.
Detección de ataques.
EEA # 8.7
Efectividad de los ataques
EEA # 8.4
EEA # 8.5
EEA # 8.8
EEA # 8.9
EEA # 8.10
EEA # 8.11
Evaluación de la capacidad de recuperación del sistema frente a desastres
y perturbaciones.
Número de ataques identificados por sistema para conseguir un registro
válido y un análisis forense significativo.
Efectividad de los ataques - Número de accesos exitosos en los sistemas
de destino desde el comienzo hasta el final del ejercicio.
Evaluación de la capacidad de recuperación del sistema frente a desastres
y perturbaciones después de ataques DDoS.
Tabla 8 Elemento Esencial de Análisis del Objetivo 8.
5. METODOLOGÍAS.
5.1. Metodología del Evento.
La metodología que se seguirá en el evento constará para cada una de las fases definidas
en el apartado de los siguientes pasos:
 Reconocimiento. Recopilación de información de todos los nodos objetivo de la red.
Esta fase dado que se estáen un entorno conocidose dará por realizada.
 Mapeo de RED. Descubrimiento de red e identificación de Servicios y Sistemas
Operativos. Herramientas a emplear:
Página | 12
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
 Znmap.
 Análisis de vulnerabilidades. Obtener vulnerabilidades explotables de cada uno de
los nodos de la red.
 Nessus.
 OpenVas.
 Proceso de Ataque.Ejecutar los exploits adecuados para hacerse con el control de las
máquinas con vulnerabilidades explotables. Si es necesario realizar escalada de
privilegios, mediante herramientas de craqueo de contraseñas.
 Backtrack: armitage, canvas.
 CoreImpact.
 Appliance de S21SEC.
 Herramienta de craqueo de contraseñas.
 Instalación de puestas traseras en las máquinas comprometidas. Esta fase se
considera como objetivo, dependiente de la viabilidad de obtener un malware de
este tipo.
 Ataques DDoS.

Herramienta IS LOIC o similar.
Reconocimiento
Mapeo
de RED
Análisis de
Vulnerabilidades
Proceso
de
Ataque
Instalación
de puertas
traseras
Ataques
DDoS
Figura 2. Metodología.
Al final de cada fase del evento se realizará un experimento tipo discusión dirigidadebido a
que son especialmente útiles tanto para explorar nuevos matices o aspectos derivados de
una solución, como para analizarla y descomponerla. Unadiscusióndirigidanoes más que
un intercambio de ideas, en el que los participantes exponen sus puntos de vista dirigidos
por unmoderadorconelfindedescubrir en grupo nuevas soluciones o analizar las existentes,
dentro del problema planteado.
La discusión es observada por elEquipo de Control que, de acuerdo a un Plan establecido
de Análisis y Recolección de Datos (DCAP), captura los datos pertinentes.
Página | 13
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
NODO-7
PLATAFORMA ATAQUE
INNOTEC
AMPLIANCE
(192.168.7.6-7)
ITM
CORE IMPACT
ATCVM-44
(192.168.7.4)
S21SEC
AMPLIANCE
(192.168.7.5)
IS LOIC
ATCVM-43
(192.168.7.3)
UNIVERSIDAD
GRANADA
TUNEL VPN
Router Virtual
ROUVM-7
(192.168.7.1)
ITM
BACKTRACK 5.2
ATCVM-42
(192.168.7.2)
Figura 3. Plataforma de ataque.
En el Anexo A se detalla la Arquitectura delEvento y el detalle de los escenarios
para las distintas fases del experimento.
En el Anexo B se especifican la organización y los recursos necesarios para la
celebración del Evento.
En el Anexo C se encuentra planificada la agenda del Evento.
6. ESCENARIO
6.1. Generalidades
El término Escenario se define como una descripción del área, entorno, medios, objetivos y
acontecimientos relacionados con el conflicto o crisis, durante un periodo de tiempo
adecuado para el estudio satisfactorio de los objetivos a alcanzar. Conforme a lo anterior
se definen dos tipos de escenario:
Escenario lógico de pruebas. Se define de forma detallada el escenario CIS en el
que se va a realizar el experimento en cada una de las dos fases.
Este escenario estará compuesto por la descripción de los distintos sistemas y
nodos dispuestos para entrar en acción. En la Figura 4 y Figura 5 se pueden
visualizar estos escenarios.
Además se dispone de una “puesta en escena” de este despliegue de sistemas que
queda apoyado por la Figura 3 y la siguiente descripción.
“Ante la situación de crisis extrema en el país de RWENZORILAND, con una sangrienta
guerra civil donde se suceden continuas violaciones de los derechos humanos, la
comunidad internacional reacciona y acuerda intervenir. Pese al bloqueo inicial de toda
iniciativa por parte de uno de los países con derecho a veto, BIASLAND, finalmente éste
acepta y el Consejo de Seguridad de las Naciones Unidas emite una resolución
autorizando el envío y despliegue de una fuerza multinacional RWESAF bajo paraguas
de la OTAN, que detenga la extrema violencia y el incontable número diario de
muertes. Esta fuerza multinacional, deberá actuar en todo el espectro de las
operaciones para lo cual se considera clave su cohesión e interoperabilidad para
Página | 14
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
alcanzar la situación final deseada, -detenida la violencia y acuerdos de paz y transición
política alcanzados-.
Una de las agrupaciones tácticas de entidad Brigada, es liderada por España. A ella se
subordinan, entre otras, un batallón del país LAZYLAND desplegado al SW de la base
principal de la provincia de responsabilidad española -PSB-, que además destaca un
combat outpost –COP East- al SE.
RWESAF acuerda desplegar una red federada de misión donde interoperen todas las
partes interesadas; naciones que contribuyen con tropas, tanto pertenecientes a la
OTAN como no, la nación anfitriona, y algunas agencias y organizaciones no
gubernamentales, que permita establecer y mantener una visión común sobre el
entorno operativo accediendo a un intercambio de información eficaz. Esta red se basa
en el compromiso, la confianza mutua y la voluntad de las naciones para asegurar el
ejercicio del mando y control C2.
En este escenario, BIASLAND permanece poco a favor del despliegue aliado y decide
lanzar una campaña encubierta de actividades en el ciberespacio contra RWESAF. Para
ello, BIASLAND aprovecha dos elementos fundamentales; en primer lugar, sus
tradicionales influencias político-estratégicas sobre LAZYLAND , y en segundo lugar, el
desinterés para cumplimentar las directivas sobre ciberdefensa que ha dictado
COMRWESAF, por parte de LAZYLAND.
Así, fuentes de inteligencia de RWESAF aseguran disponer de información certera de
que LAZYLAND está descuidando totalmente la seguridad en sus enlaces con una de las
ONGs presentes en ZO procedente de BIASLAND, y de que en la red interna de la COPEast, los CIS se están empleando, compartiendo conexiones de banda ancha a Internet
mediante un proveedor comercial externo, para descargas masivas de archivos,
videoconferencias particulares e incluso acciones fraudulentas de algunos de sus
miembros relacionadas con el tráfico ilegal de drogas y armas.”
Figura 4. Escenario de Contexto.
Área de pruebas. Distribución en los diversos locales del Área de los equipos que
van a participar en el experimento. Se plantean tres áreas:
 Área Seguridad. Albergará al equipo de Análisis y Ataque.
 Área Discusiones. Sala para realizar los experimentos tipo discusión dirigida.
 Área Participantes. Albergará al equipo de Participantes.
6.2. Consideraciones sobre el escenario
Página | 15
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Previamente al inicio de cada fase del evento se ha de comprobar el funcionamiento
conjunto de todos los sistemas CIS tácticos desplegados en el evento.
Los sistemas CIS tácticos seguirán la secuencia de ejecución que se describe en el Anexo F.
Los escenarios deben cumplir dos requisitos: validez y credibilidad. La validez se refiere a
la habilidad del escenario para representar correctamente todos los factores, ambiente
(red táctica) y relaciones que sustentan el modelo conceptual del experimento. La
credibilidad se relaciona con la aceptación del mismo por la comunidad de profesionales
involucrados en el experimento: actores, investigadores y mandos responsables apoyados.
Se ha diseñado un escenario para cada una de las fases del experimento. Su diagrama
lógico se representa en las siguientes figuras.
Figura 5. Escenario lógico de la Fase 1.
Página | 16
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Figura 6. Escenario lógico de la Fase 2.
En el Anexo A se detallan los escenarios anteriormente mostrados para cada una de las
fases.
7. EVALUACIÓN DE RIESGOS.
7.1. Generalidades.
Durante todas las fases del experimento, desde su planeamiento hasta su análisis, existen
una serie de riesgos que pueden poner en peligro la validez del experimento. La presencia
de estos riesgos debe ser siempre tenida en cuenta y, por tanto, es fundamental planear
medidas orientadas a mitigarlos.
Para cada uno de los riesgos se debe valorar cuál es su relevancia en el experimento y el
nivel de riesgo que representa.
En el Anexo D se establece la matriz de evaluación de riesgos para el evento, en la que se
detalla la relevancia o impacto correspondiente, su nivel y las medidas a adoptar para
mitigar el riesgo pertinente (Plan de Mitigación de Riesgos).
7.2. Riesgos del evento.
Los principales riesgos del evento son:
Falta de conocimiento del Concepto por parte de los participantes.
Los participantes provienen de diferentes organizaciones y tendrán diferente
formación y experiencia en Ciberdefensa. Para mitigar este riesgo durante la MPC
se efectuará un repaso/conferencia sobre el Concepto de Ciberdefensa.
Página | 17
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Diferente motivación o ideas preconcebidas por parte de los participantes.
Los participantes provienen de diferentes organizaciones y no solamente tendrán
diferente formación y experiencia en Ciberdefensa, sino que presentarán diferente
motivación a la hora de participar. Para mitigar este riesgo el Equipo de Análisis
deberá de tener presente en todo momento la motivación e ideas preconcebidas
de los diferentes participantes.
Disponibilidad de los sistemas C2.
Para minimizar este riesgo se realizará con una antelación del más de un mes a la
fecha de celebración del evento la petición de los diferentes sistemas alos
organismos responsables.
Disponibilidad del sistema Gesta.
Para minimizar este riesgo se pedirá apoyo al Regimiento de Guerra Electrónica 31
para realizar la instalación del mismo en una plataforma virtual.
Interoperabilidad entre los diferentes sistemas C2.
Sistemas no interoperables a través del COE por cambios de versiones. Se utilizará
la herramienta Integra desarrollada en el Área TICS del ITM.
Los indicadores no son representativos.
En las pruebas previstas, que los indicadores escogidos no sirvan para dar
respuesta a los EEA. Se mitigará a través del análisis exhaustivo de los datos
guardados automáticamente.
Plazos de montaje del experimento.
No alcanzar las fechas previstas para el experimento con los escenarios propuestos
montados. Implicar a más personal del Área TICS del ITM en su montaje.
8. PLAN DE RECOGIDA Y ANÁLISISDE DATOS.
Además de las métricas y los escenarios hay que elaborar los Planes de captura o
recolección de datos y el de análisis de los mismos.
Estas dos tareas están fuertemente ligadas puesto que el análisis está siempre limitado a
los datos que se hayan recopilado.
Por otra parte debe tenerse en cuenta la instrucción de los recolectores de datos que se
deben asegurar que los datos para el experimento sean aquellos que los analistas esperan
y que las diferencias no previstas (anomalías) deben ser identificadas y registradas para
que, o bien el proceso de análisis pueda compensarlas, o bien los datos contaminados
puedan ser borrados.
Estos dos planes son vitales porque se encuentran en el corazón de la experimentación.
Asegurando que se capturan datos fiables y válidos y que el análisis acomete los asuntos
clave del experimento así como que los datos estén disponibles y la información sea
entendida y explotada por completo no sea desaprovechada.
En el Anexo E se encuentra detallado el Plan de Recogida y Análisis de Datos.
8.1. Relación entre el Plan de Análisis y el Plan de Recogida de Datos.
Página | 18
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
El propósito fundamental del Plan de Recolección de datos es alimentar el Plan de Análisis.
El proceso de trabajo debe comenzar con un Plan de Análisis de los Datos para determinar
cómo los asuntos a estudiar van a ser abordados con los datos generados para el
experimento. Por tanto, se puede entender que el Plan de Recogida de Datos actúa como
suministrador del Plan de Análisis que actúa como consumidor de los mismos.
Una vez asumida la necesidad de considerar los requisitos del análisis primero, la realidad
es que los factores prácticos (acceso, minimizar la interferencia, clasificación,...) pueden
limitar lo que puede ser realmente recopilado en un experimento. Por lo tanto, aunque el
análisis debe ser posicionado en primer lugar, el desarrollo de los dos planes debe ser
iterativo y continuo.
El propósito del plan de recolección de datos debe ser proporcionar lo que se necesita en
el Plan de Análisis. Perder de vista este principio siempre conlleva al mismo problema que
consiste en recopilar los datos que son fáciles de conseguir en lugar de los que son
necesarios para un experimento válido que contribuya al crecimiento del conocimiento.
Finalmente, el equipo de experimentación necesita recordar que ninguno de estos planes
es un fin en sí mismo. Ambos son instrumentos para la consecución de los objetivos
globales del experimento. Como tales, están sujetos y deben ceñirse al resto del Plan de
Experimentación.
El Plan de Recolección de datos debe estar coordinado con los escenarios, las pre-pruebas,
el plan de formación para los recolectores y los sistemas usados para archivar los datos y la
información.
El Plan de Análisis debe estar organizado desde el principio hasta el final, desde la
depuración en las pre-pruebas hasta el análisis y modelado post-experimento.
8.2. Plan de Análisis de Datos.
El Análisis es el proceso de aprender lo que se quiere saber desde lo que ya se sabe o se
tiene la posibilidad de conocer. Es una parte crucial de cualquier experimento. Organizar
los resultados de la experimentación e integrarlos con el conocimiento existente para
generar conocimiento nuevo y válido es el reto analítico.
El Plan de Análisis toma su forma del modelo conceptual subyacente del experimento.
Las medidas específicas son importantes porque proporcionan información acerca del
nivel de medida (nominal, ordinal, intervalo o ratio) disponible para cada variable de
interés. Estos niveles de medida, en su momento, ayudarán a determinar la técnica
analítica adecuada a ser aplicada. Los otros factores clave necesarios para seleccionar la
técnica más adecuada son el número de observaciones o puntos de datos independientes
para cada variable.
El Análisis normalmente se organiza en tres fases:
Análisis descriptivo de las variables individuales
Análisis bivariable de relaciones
Análisis multivariable de patrones mayores.
8.3. Plan de Recolección de Datos
Página | 19
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
El Plan de Recolección de datos incluye todas las variables a ser recopiladas, todos los
lugares donde han de ser capturadas, todos los medios de captura de los datos y todos los
sitios donde los datos serán almacenados para su proceso. Esto requerirá ser recogido en
un documento principal donde se incorporará tanto la filosofía general a ser usada como
los detalles necesarios para la implementación.
Un plan de recolección de datos de alta calidad también especifica el soporte requerido, la
formación necesaria, los estándares competentes a los que alinearse, el enfoque al control
de la calidad, cómo los datos serán archivados para asegurar su integridad y el proceso por
el cual los conjuntos de datos serán reducidos de su estado más tosco para crear conjuntos
de variables ideadas desde el Plan de Análisis y ensambladas para un análisis eficiente.
Este plan tampoco es un fin en sí mismo sino más bien un medio para asegurar que el
proceso de recolección de datos está organizado para conseguir el éxito y entendimiento
de todos aquellos que necesitan apoyar el esfuerzo.
La creación del plan de recolección de datos puede ser ideado como una tarea secuencial,
aunque se probará que realmente es iterativa porque está muy fuertemente ligada con los
objetivos del experimento, el escenario, los espacios físicos disponibles para el
experimento, los sistemas a ser empleados para soportar el experimento, y otros factores
que probablemente cambiarán desde la fase inicial del concepto a través de la fase de prepruebas.
Los pasos clave en este proceso serán:
Especificación de las variables a ser recopiladas.
Identificación de los mecanismos de recolección para cada variable.
Aseguramiento del acceso para recolectar cada variable.
Especificación del número de observaciones necesarias para cada variable y
comprobación de que efectivamente son generadas.
Identificación de la formación para asegurar la calidad de la recolección de los
datos.
Especificación de los mecanismos para capturar y archivar los datos.
Definición de los procesos necesarios para la reducción de los datos y su posterior
ensamblado.
Los tipos de mecanismos de recolección usados en los experimentos normalmente son:
Recolección automática
Registro para una posterior reducción
Encuestas
Pruebas de Conceptos
Observación humana
Cada una de ellas tiene su uso particular, fortalezas, debilidades y factores que necesitan
ser considerados cuando sean empleadas.
Página | 20
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
9. ANEXO A: ARQUITECTURA DEL EVENTO. DIAGRAMAS.
La arquitectura técnica es la combinación global de los siguientes elementos usados para
soportar el experimento: sistemas de comunicación, sistemas de información de soporte,
redes, plan de trabajo, bases de datos, modelos y simulaciones.
Los dos retos más importantes para el equipo técnico son definir los requisitos para los
desarrolladores del concepto y para los diseñadores del experimento y después integrar
los distintos sistemas en un entorno de trabajo del experimento. El concepto del
experimento requerirá frecuentemente un sistema que emule la futura capacidad.
Los diseñadores pueden identificar o desarrollar una simulación o herramienta que
proporcione esta capacidad. Normalmente, el equipo técnico también será el
implementador de un conjunto de sistemas o herramientas que proporcionen una
maqueta para la operación de unos cuarteles generales. Herramientas como JSAF pueden
ser también utilizadas para simular las fuerzas aliadas, enemigas o neutrales y esta
información podría ser suministrada a las herramientas que soportan los cuarteles
generales a través de los interfaces C4I. El equipo técnico tendrá normalmente la mayor
carga de trabajo en el experimento. Además, este equipo requiere de los diseñadores del
experimento un plan y unos objetivos claros lo antes posible.Tal y como se ha discutido
previamente, el asunto a estudiar debe ser establecido de forma temprana y en un nivel
suficientemente detallado. Por tanto, los Expertos en la Materia deben trabajar
estrechamente con los desarrolladores técnicos para compartir su visión detallada del
asunto a estudiar y que de esa forma puedan representarlo adecuadamente. El equipo
técnico debería identificar áreas de riesgo en sus programas pronto y comunicar las fechas
límite a los diseñadores, moviendo herramientas u otros componentes al experimento
después de la MPC.
Finalmente para cada experimento, debe existir un proceso bien construido de
integración, pruebas y verificación de los componentes de la arquitectura técnica. Este
proceso debe ser bien gestionado usando un enfoque gradual construyendo desde las
pruebas de los elementos individuales a través de la realización del sistema completo en
viñetas del escenario.
Los desarrolladores del concepto y otros expertos en la materia deben participar en el
proceso de pruebas para verificar que los resultados generados dentro de la arquitectura
técnica representan adecuadamente el estado actual del asunto bajo investigación. Esto
debe ser realizado y documentado adecuadamente de tal forma que los analistas
entiendan las fortalezas y debilidades de la arquitectura técnica y puedan delimitar sus
análisis adecuadamente.
A continuación se muestran los distintos diagramas que representan la arquitectura
técnica del experimento. En primer lugar, una visión global de toda la infraestructura a
desplegar. Seguidamente el detalle de cada nodo representado en el diagrama general
tanto en la Fase 1 como en la Fase 2.
Página | 21
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Red WAN
NODO-4
PC GRUPO ART.
CD&E CIBERDEFENSA
RED WAN v2.01
Router
Virtual
ROUVM-4
Router
Virtual
ROUVM-3
192.168.50.5/30
192.168.4.0/24
192.168.50.6/30
NODO-3
PC BRIGADA
SIMACET GU
EDC GESTA
192.168.3.0/24
192.168.51.5/30
192.168.50.65/30
192.168.51.1/30
NODO-1
NODO TACOMS
RRC
Simulador WAN
WANVM-1
Router
FISICO
ROUFIS-1
192.168.51.6/30
192.168.51.9/30
192.168.51.2/30
192.168.51.10/30
192.168.51.14/30
192.168.51.26/30
NODO-7
PLATAFORMA
ATAQUE
192.168.50.58/30
192.168.50.30/30
192.168.51.30/30
Router Virtual
ROUVM-7
(192.168.7.1)
ROUTER
CENTRAL
ROUVM-12
192.168.51.13/30
192.168.51.18/30
192.168.50.57/30
192.168.50.61/30
192.168.51.22/30
192.168.51.25/30
Router
Virtual
ROUVM-2
192.168.7.0/24
NODO-2
PC BON
SIMACET PU
192.168.2.0/24
192.168.51.29/30
NODO-8
Monitorización
Gestión
Router Virtual
ROUVM-8
(192.168.8.1)
192.168.8.0/24
RED WAN
MAQUINAS VIRTUALES
Símbolo
192.168.51.21/30
Total
Descripción
4
WANEM
1
ROUTER WAN
7
ROUTER
NODO
192.168.50.29/30
NODO-6
PC CIA
FFT
Router
Virtual
ROUVM-6
192.168.6.0/24
192.168.51.17/30
192.168.50.66/30
Router
Virtual
ROUVM-5
NODO-5
PC CIA
COMFUT
192.168.5.0/24
Figura 7. Red WAN.
Nodo 1: PC brigada
 Fase1
NODO-1 PC BRIGADA
12.12.12.X/24
QUORUM
Monitorización
Gestión
28.28.28.X/24
FAILOVER
TCPDUMP/NFSEM
WIRWSARK
MONVM-19
192.168.1.8
COE
PC BON EW
(SERVIDOR EDC)
GESVM-14
192.168.1.3
SIMACET GU
SERVIDOR-2
SIMVM-13
192.168.1.2
SIMACET GU
QUORUM
192.168.1.3
SERVIDOR LOG
(OSSIM)
MONVM-18
192.168.1.7
SIMACET GU
SERVIDOR-1
SIMVM-13
192.168.1.1
INTEGRA-1
(INTERFAZ NFFI)
INTVM-15
192.168.1.105
SWITCH
SWVM-18
INTEGRA-2
(INTERFAZ NFFI)
INTVM-15
192.168.1.106
SIMACET GU
COE
(192.168.1.101)
SIMACET GU
DC2
192.168.1.29
SIMACET GU
DC1
192.168.1.28
SIMACET GU
NAS
192.168.1.30
CLIENTE EDC
GESTA
GESVM-16
DHCP
CLIENTE SIMACET
(ESCORPIO)
SIMVM-17
DHCP
Router Virtual
ROUVM-1
192.168.1.50
PC BRIGADA
MAQUINAS VIRTUALES
Símbolo
Total
Descripción
2
PC
6
Servidor
1
Switch
3
Servidor
Monitorización
1
Servidor de
archivos
2
Servidor de
directorios
Figura 8. Nodo 1 PC Brigada Fase 1.
Página | 22
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
 Fase 2
NODO-3 PC BRIGADA (SECURIZADO)
12.12.12.X/24
QUORUM
pliance®
orkA
etw
N
28.28.28.X/24
FAILOVER
Monitorizacion
CERT-ET DESPLEGABLE
COE
PC BON EW
(SERVIDOR EDC)
GESVM-14
192.168.1.3
SIMACET GU
SERVIDOR-2
SIMVM-13
192.168.1.2
SIMACET GU
QUORUM
192.168.1.3
Monitorización
Gestión
TCPDUMP/NFSEM
WIRWSARK
MONVM-19
192.168.1.8
SERVIDOR LOG
(OSSIM)
MONVM-18
192.168.1.7
SIMACET GU
SERVIDOR-1
SIMVM-13
192.168.1.1
INTEGRA-1
(INTERFAZ NFFI)
INTVM-15
192.168.1.105
SWITCH
SWVM-18
PC BRIGADA
MAQUINAS VIRTUALES
INTEGRA-2
(INTERFAZ NFFI)
INTVM-15
192.168.1.106
SIMACET GU
COE
(192.168.1.101)
Símbolo
IPS
SIMACET GU
DC2
192.168.1.29
SIMACET GU
DC1
192.168.1.28
SIMACET GU
NAS
192.168.1.30
CLIENTE EDC
GESTA
GESVM-16
DHCP
Router Virtual
ROUVM-1
192.168.1.50
CLIENTE SIMACET
(ESCORPIO)
SIMVM-17
DHCP
Total
Descripción
2
PC
6
Servidor
1
Switch
3
Servidor
Monitorización
1
Servidor de
archivos
2
Servidor de
directorios
Figura 9. Nodo 1 PC Brigada Fase 2.
Nodos 2-4-5-6
 Fase1
NODO-2 PC BON
NODO-4
PC GRUPO ART.
CLIENTE TALOS
TALVM-24
(192.168.4.3)
TALOS
12.12.12.X/24
QUORUM
Monitorización
TCPDUMP/NFSEM
WIRWSARK
MONVM-33
192.168.4.4
Cliente NFFI
COE
Monitorización
Gestión
Gestión
SERVIDOR LOG
(OSSIM)
MONVM-34
192.168.4.5
SIMACET GU
SERVIDOR-2
SIMVM-13
192.168.2.2
SIMACET GU
QUORUM
192.168.2.3
SWITCH
SWVM-26
FSE TALOS
TALVM-25
(192.168.4.2)
SEC. MORTEROS
TALVM-25
(192.168.4.2)
FDC
(192.168.4.6)
SIMACET GU
DC2
192.168.2.29
OAV
(192.168.4.7)
NODO-6 CIA
FFT
FFTVM-30
(192.168.6.3)
FFT
FFTVM-31
(192.168.6.2)
SWITCH
SWVM-18
SERVIDOR LOG
(OSSIM)
MONVM-18
192.168.1.7
SIMACET GU
DC1
192.168.2.28
SIMACET GU
NAS
192.168.2.30
CLIENTE EDC
GESTA
GESVM-16
DHCP
NODO-5 CIA
Monitorización
Gestión
TCPDUMP/NFSEM
WIRWSARK
MONVM-40
192.168.6.4
FFT
SWITCH
SWVM-32
TCPDUMP/NFSEM
WIRWSARK
MONVM-19
192.168.1.8
SIMACET GU
SERVIDOR-1
SIMVM-13
192.168.2.1
SIMACET GU
COE
(192.168.2.101)
Router Virtual
ROUVM-2
(192.168.4.1)
CO
(192.168.4.4)
28.28.28.X/24
FAILOVER
Monitorización
Gestión
TCPDUMP/NFSEM
WIRWSARK
MONVM-37
192.168.5.4
SERVIDOR LOG
(OSSIM)
MONVM-41
192.168.6.5
SERVIDOR LOG
(OSSIM)
MONVM-38
192.168.5.5
Figura 10.
Router Virtual
ROUVM-1
192.168.2.50
COMFUT
COMFUT
CONVM-27
(192.168.5.2)
SWITCH
SWVM-29
Router Virtual
ROUVM-5
(192.168.5.1)
Router Virtual
ROUVM-6
(192.168.6.1)
CLIENTE SIMACET
(ESCORPIO)
SIMVM-17
DHCP
COMFUT
CONVM-28
(192.168.5.3)
Nodos 2-4-5-6 Fase 1.
Página | 23
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
 Fase 2
NODO-2 PC BON
NODO-4
PC GRUPO ART.
CLIENTE TALOS
TALVM-24
(192.168.4.3)
TALOS
12.12.12.X/24
QUORUM
Monitorización
Cliente NFFI
COE
Monitorización
Gestión
Gestión
SERVIDOR LOG
(OSSIM)
MONVM-34
192.168.4.5
SIMACET GU
SERVIDOR-2
SIMVM-13
192.168.2.2
SIMACET GU
QUORUM
192.168.2.3
SWITCH
SWVM-26
FSE TALOS
TALVM-25
(192.168.4.2)
IPS
TCPDUMP/NFSEM
WIRWSARK
MONVM-19
192.168.1.8
SIMACET GU
SERVIDOR-1
SIMVM-13
192.168.2.1
SWITCH
SWVM-18
SERVIDOR LOG
(OSSIM)
MONVM-18
192.168.1.7
SIMACET GU
COE
(192.168.2.101)
Router Virtual
ROUVM-2
(192.168.4.1)
IPS
SEC. MORTEROS
TALVM-25
(192.168.4.2)
CO
(192.168.4.4)
FDC
(192.168.4.6)
SIMACET GU
DC2
192.168.2.29
OAV
(192.168.4.7)
NODO-6 CIA
SIMACET GU
NAS
192.168.2.30
NODO-5 CIA
SWITCH
SWVM-32
FFT
FFTVM-31
(192.168.6.2)
SIMACET GU
DC1
192.168.2.28
Monitorización
Gestión
TCPDUMP/NFSEM
Monitorización
Gestión
TCPDUMP/NFSEM
WIRWSARK
MONVM-40
192.168.6.4
FFT
FFT
FFTVM-30
(192.168.6.3)
28.28.28.X/24
FAILOVER
TCPDUMP/NFSEM
WIRWSARK
MONVM-33
192.168.4.4
WIRWSARK
MONVM-37
192.168.5.4
SERVIDOR LOG
(OSSIM)
MONVM-38
192.168.5.5
SERVIDOR LOG
(OSSIM)
MONVM-41
192.168.6.5
Router Virtual
ROUVM-6
(192.168.6.1)
CLIENTE EDC
GESTA
GESVM-16
DHCP
Figura 11.
Router Virtual
ROUVM-1
192.168.2.50
COMFUT
COMFUT
CONVM-27
(192.168.5.2)
SWITCH
SWVM-29
Router Virtual
ROUVM-5
IPS (192.168.5.1)
IPS
CLIENTE SIMACET
(ESCORPIO)
SIMVM-17
DHCP
COMFUT
CONVM-28
(192.168.5.3)
Nodos 2-4-5-6 Fase 2.
Nodo 7-8
Página | 24
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
NODO-7
PLATAFORMA ATAQUE
INNOTEC
AMPLIANCE
(192.168.7.6-7)
ITM
CORE IMPACT
ATCVM-44
(192.168.7.4)
S21SEC
AMPLIANCE
(192.168.7.5)
IS LOIC
ATCVM-43
(192.168.7.3)
UNIVERSIDAD
GRANADA
TUNEL VPN
Router Virtual
ROUVM-7
(192.168.7.1)
ITM
BACKTRACK 5.2
ATCVM-42
(192.168.7.2)
Leyenda
Subtítulo de leyenda
Símbolo
NODO-8
Monitorización Gestión
TCPDUMP/NFSEM
WIRWSARK
192.168.8.2
Total
Descripción
5
PC
4
Servidor de
base de datos
2
Switch
1
Nube
Almacenamiento
SERVIDOR LOG
(OSSIM)
192.168.8.3
NETFLOW
192.168.8.3
Router Virtual
ROUVM-9
(192.168.800.1)
Figura 12.
Página | 25
Nodos 7-8.
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
10. ANEXO B: ORGANIZACIÓN Y RECURSOS NECESARIOS.
Organización Del Evento
El personal asistente a las pruebas se organizará en los siguientes equipos o grupos de
trabajo:
 Dirección: tendrá como misión la verificación y comprobación del correcto desarrollo y
realización de las pruebas del evento. Estará formado por un representante del
MADOC y dos del ITM.
 Equipo de Control: tendrá como misión la de llevar el control y dirección de las
pruebas, la comprobación y verificación de su correcta superación y control de los
medios de apoyo asignados. De este equipo dependerán todos los equipos que
integran las pruebas. El control y dirección de las pruebas será ejercido por personal de
ITM y MADOC.
 Equipo de participantes: tendrá como misión la operación y control de los sistemas CIS
involucrados en las pruebas. Dispondrá de tres equipos: sistemas C2, administración
de seguridad y CERT.
 Equipo de Seguridad: tendrá como misión la operación y control de los sistemas de
seguridad. Dispondrá de dos equipos, uno de análisis y otro de ejecución.
 Equipo de Observadores: su misión será participar en la discusión dirigida en base a lo
observado durante la realización de las pruebas.
DISEÑ0
DIRECCION
CONTROL
SEGURIDAD
OBSERVADORES
ANALISIS
PARTICIPANTES
SISTEMAS C2
ADMON
EJECUCION
SEGURIDAD
CERT
Figura 13.
Organización del evento.
Página | 26
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Recursos Humanos
UNIDAD/ORGANISMO
MADOC
EME DIVOPE / SEC. CIS
JCISAT
FUTER / BRITRANS
DIMA / PCMHS
ITM
Centro de Investigación
de Tecnologías de la
Información
yComunicaciones (CITIC)
de la Universidad de
Granada
S21SEC
PARTICIPACIÓN
Oficiales (2) realización dirección y control del
experimento.
Oficial (1) representante del Grupo de Trabajo
en el Plande Obtención de la Capacidad de
Ciberdefensa Militar (PACDM)como asesor del
programa.
Oficial representante del ET (1) en el Ejercicio
Multinacional CYBERENDEAVOR para ofrecer
una conferencia sobre el mismo el 19SEP12 en
el Centro Mediterráneo de la Universidad de
Granada y como asesor en el LOE.
Un (1) representante de ARTIC (MC3) como
asesor en el LOE.
Un (1) representante CERT-ET (SEGINFOSIT)
comoasesor en el LOE.
Un (1) Operador del Nodo TACOMS.
Dos(2) operadores de SIMACET.
Un (1) representante del CG BRITRANS -área de
INFOSEC- como asesor del programa.
Un (1) representante del REW-31 como asesor
delprograma.
Un (1) representante del Área de Securización y
Calidadde software para C2 como asesor del
programa
Trece (13) personas para el diseño, control y
ejecución del experimento.
Colaboración en el LOE como parte del
escenario, representando a una hipotética
organización civildesplegada en ZO.
Colaboración en la plataforma de ataque del
escenario.
EQUIPO
Un (1) Dirección
Un (1) Control
Un (1) Observador
Tres (3) Observadores
Tres (3) Participantes
Un (1) Observador
Un (1) __________
Un (1) Observador
Dos (2) Dirección
Un (1) Control
Cinco (5) Seguridad
Cinco (5) Participantes
Participantes
Un (1) Seguridad
Tabla 9 Recursos Humanos
Recursos Materiales
UNIDAD/ORGANISMO
ITM
JCISAT
MATERIAL
Plataforma virtual del Centro Experimentación en
Ciberdefensa.
Nodo TACOMS.
Sistemas Talos, FFT, COMFUT.
Plataforma de ataques.
Equipos virtuales de securización FIREWALL, IPS.
Router y simulador WAN virtuales.
Sistemas de Monitorización.
Nodo TACOMS.
Sistema SIMACET.
CERT.
Página | 27
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
UNIDAD/ORGANISMO
MATERIAL
REWE 31
Sistema GESTA.
S21SEC
Plataforma de Ataque
Universidad Granada
Plataforma civil
Tabla 10 Recursos Materiales.
Página | 28
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
11. ANEXO C: PLANIFICACIÓN.
La planificación para el evento será la mostrada en la siguiente tabla:
FECHA
HORARIO
09:00 - 09:30
MARTES
11 DICIEMBRE
SEGURIDAD
SEGURIDAD/PARTICIPANTES
SEGURIDAD/PARTICIPANTES
TODOS
09:00 - 10:00
PROCESO ATAQUE
SEGURIDAD/PARTICIPANTES
10:00 - 11:00
INSTALACION PUERTAS TRASERAS
SEGURIDAD/PARTICIPANTES
11:00 - 13:00
ATAQUES DDoS
13:00 - 13:45
DISCUSION DIRIGIDA FIN EXPERIMENTO FASE 1
13:45 – 14:00
PUNTO DE CONTROL
09:00 - 13:45
PREPARACION FASE 2 DEL EXPERIMENTO
10:00 - 10:30
VIERNES
14 DICIEMBRE
TODOS
DIRECCION/CONTROL/OBSERVADORES
TODOS
RECEPCIÓN DE VIPS – ENTREGA DOSSIER BIENVENIDA
(BLOQUE 1 - SALA G100)
TEMAS ADMINISTRATIVOS y EXPLICACIÓN DE
ESCENARIO
CAFÉ Y TRASLADO AL BLOQUE 10 – TICS
11:00 - 13:00
EJERCICIO TABLE TOP
13:00 - 13:45
VISITA ÁREAS ITM
13:00 - 13:45
TODOS
SEGURIDAD/PARTICIPANTES
10:30 - 11:00
9:30 - 10:00
JUEVES
13 DICIEMBRE
TICS-ITM
10:30 - 11:30
11:30 - 12:30
12:30 - 13:45
13:45 - 14:00
10:00 - 10:30
09:30 - 10:00
MIÉRCOLES
12 DICIEMBRE
BIENVENIDA GRAL. ITM (SALA G30, EDIFICIO 1)
UNIDAD/EQUIPO
DATOS ADMINISTRATIVOS/
TRASLADO LABORATORIO CIBERDEFENSA (EDIFICIO 10)
PRESENTACION MEDIOS MONITORIZACION Y
PRESENTACION A LOS PARTICIPANTES
COMIENZO EXPERIMENTOFASE 1: MAPEO DE RED
ANALISIS VULNERABILIDADES
PROCESO ATAQUE
PUNTO DE CONTROL
09:30 - 10:00
LUNES
10 DICIEMBRE
ACTIVIDAD
PERSONAL SEGURIDAD ITM
PERSONAL ITM – INVITADOS
PERSONAL ITM – INVITADOS
PERSONAL ITM – INVITADOS
INVITADOS
PERSONAL ITM – INVITADOS
RELLENADO DE CUESTIONARIOS POR PARTE DE LOS
EXPERTOS
SMEs
13:45 – 14:00
PUNTO DE CONTROL
09:00 - 10:00
COMIENZO EXPERIMENTO FASE 2: MAPEO DE RED
10:00 - 12:00
ANALISIS VULNERABILIDADES
SEGURIDAD/PARTICIPANTES
SEGURIDAD/PARTICIPANTES
TODOS
SEGURIDAD
12:00 - 13:45
PROCESO ATAQUE
13:45 – 14:00
PUNTO DE CONTROL
09:00 - 10:00
10:00 - 11:00
11:00 - 13:00
13:00 - 13:50
INSTALACION PUERTAS TRASERAS
SEGURIDAD/PARTICIPANTES
ATAQUES DDoS
SEGURIDAD/PARTICIPANTES
DISCUSION DIRIGIDA FIN EXPERIMENTO FASE 2
DIRECCION/CONTROL/OBSERVADORES
PUNTO DE CONTROL, CONCLUSIONES Y DESPEDIDA
TODOS
Tabla 11 Planificación del Evento
TODOS
Página | 29
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
12. ANEXO D: ANALISIS RIESGOS.
Id. Riesgo
Título
Estado
Descripción
Probabilidad Impacto Criticidad
Fecha
Seguimiento
Acciones de Mitigación
RSK-001
Falta de conocimiento del
Concepto por parte de los
participantes
Abierto Los participantes provienen de diferentes
organizaciones y tendrán diferente formación
y experiencia en Ciberdefensa.
ALTA
BAJO
BAJA
Apertura
04/10/2012
RSK-002
Diferente motivación o
Abierto Los participantes provienen de diferentes
ideas preconcebidas por
organizaciones y no solamente tendrán
parte de los participantes.
diferente formación y experiencia en
Ciberdefensa, sino que presentarán diferente
motivación a la hora de participar
ALTA
BAJO
BAJA
04/10/2012
Equipo de Análisis deberá de
tener presente en todo
momento la motivación e
ideas preconcebidas de los
diferentes participantes
RSK-003
Disponibilidad de los
sistemas C2
Abierto Disponibilidad de todos los sistemas CIS
tácticos del Ejército previstos en el
ejercicio
MEDIA
ALTO
ALTA
04/10/2012
se realizará con una
antelación del más de un
mes a la fecha de
celebración del evento la
petición de los diferentes
sistemas a los organismos
responsables.
RSK-004
Disponibilidad del
sistema Gesta
Interoperabilidad entre
los diferentes sistemas
C2
Los indicadores no son
representativos
Abierto Disponibilidad del Sistema GESTA
MEDIA
ALTO
MEDIA
04/10/2012
Abierto Sistemas no interoperables a través del
COE por cambios de versiones
ALTA
MEDIO
MEDIA
04/10/2012
Abierto En las pruebas previstas, no sirvan para dar
respuesta a los EEA
BAJA
BAJO
BAJA
04/10/2012
Plazos de montaje del
experimento
Cerrado No alcanzar las fechas previstas para el
experimento con los. escenarios propuestos
montadospropuestos montados
BAJA
ALTO
MEDIA
04/10/2012
Perición de apoyo al rewe
31
ITM relizará integración de
sistemas a través de la
herranienta Integra
Se mitigará a través del
análisis exhaustivo de los
datos guardados
automáticamente.
Implicar a mas personal el
Area TICS del ITM en su
montaje
RSK-005
RSK-006
RSK-007
Cierre
Durante la MPC se efectuará
un repaso/conferencia sobre
el Concepto de
Ciberdefensa.
Tabla 12 Matriz de Riesgos.
Página | 1
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
13. ANEXO E: PLAN DE ANÁLISIS Y RECOLECCIÓN DE DATOS
13.1.
Introducción
El plan de análisis y recolección de datos del eventoha sido elaborado a partir de los
objetivos de experimentación definidos en el apartado 4 del cuerpo de este documento.
13.2.
Procedimiento de análisis
En el grupo de seguridad se ha constituido un equipo de análisis y de recogida de datos,
cuya misión será el comprobar el correcto almacenaje de los mismos realizado por las
herramientas de recolección automáticas instaladas en el nodo 8 y en cada uno de los
nodos de los participantes 2-4-5-6 y recoger los informes generados por la diversas
herramientas de análisis de vulnerabilidades, escaneo, etc. Su composición y funciones
específicas se detallan en este documento.
Los análisis a posteriori de los datos almacenados por las herramientas de recolección de
datos serán realizados por la unidad de Seguridad al completo dado el volumen que se
estima de losmismos.
En la discusión dirigida se realizará un análisis de eventos del tipo descubrimiento que
tiene una naturaleza cualitativa y donde se tratan de capturar opiniones e ideas de
expertos en la materia. Ésta es la misión principal del analista supervisor del grupo junto
con los analistas colaboradores.
13.3.
Informes de resultados
Está previsto elevar un informe con las primeras impresiones en la semana siguiente a la
ejecución del evento.
El informe final con las conclusiones del análisis deberá estar entregadofebrerode 2013.
13.4.
Recolección de Datos.
Equipo de análisis
Estará formado por el personal de la Unidad de Seguridad y un miembro de la unidad de
CD&E, pertenecientes al ITM.
Analista supervisor de grupo (1)
Analistas de grupo (3)
Recolectores de datos (1)
A continuación se describe las tareas asignadas a cada miembro del grupo.
Jefe de análisis. Es el encargado de supervisar que las discusiones dirigidas están
encaminadas a recoger los elementos de análisis diseñados y que los métodos de
recogida de datos están funcionando correctamente. El perfil de esta figura es un
analista que haya participado en el diseño del experimento y que conozca bien los
objetivos de análisis.
Analistas. Supervisan la obtención de datos y recomiendan al facilitador/jefe de
análisis cuándo se debe volver a incidir sobre algún objetivo de análisis por falta de
Página | 1
DDE V 0.4
10/10/2012
MINISTERIO DE DEFENSA
datos. Pueden intervenir en las discusiones para solicitar a la audiencia volver a tratar
ideas o soluciones que no hayan quedado suficientemente claras.
Recolectores de datos. Son los encargados de repartiry recoger los cuestionarios en las
discusiones dirigidas.Además durante las discusiones dirigidas tienen que tomar nota
de los datos relevantes que se manifiesten por parte de los participantes expertos en
la materia y que puede servir para arrojar conclusiones importantes del experimento.
Sistema de recolección automática
Para la recolección de datos se tiene previsto el montaje de una infraestructura a nivel
central y local a cada nodo con la suficiente capacidad de almacenamiento en una unidad
de red para que recopile los siguientes tipos de datos:
Tráfico de red. Herramientas Wiresark y TcpDump/Nfsem.
Tráfico de enrutamiento. Netflow.
Eventos de los diferentes sistemas. OSSIM
Así mismo para la realización de análisis forense se haninstalado dos herramientas por
cada nodo:
EnCase.
Autopsy
En las figuras siguientes se muestra la infraestructura local a cada nodo y central:
NODO-8
Monitorización Gestión
TCPDUMP/NFSEM
WIRWSARK
ENCASE
AUTOPSY
192.168.8.2
Almacenamiento
SERVIDOR LOG
(OSSIM)
192.168.8.3
NETFLOW
Router Virtual
ROUVM-9
(192.168.800.1)
192.168.8.3
Figura 14.
Nodo Central de Almacenamiento.
Página | 2
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Monitorización
TCPDUMP/NFSEM
Gestión
WIRWSARK
ENCASE
AUTOPSY
MONVM-33
192.168.2.4
SERVIDOR LOG
(OSSIM)
MONVM-34
192.168.2.5
Figura 15.
Nodo Local de Almacenamiento.
Sistema de recolección manual
Cuestionarios
El cuestionario se rellenará al finalizar la primera fase del experimento (fase I) y servirá
para obtener datos relevantes acerca de las medidas de seguridad que se están
implementando por parte de los asistentes en sus respectivos destinos.
Este cuestionario tendrá una primera parte demográfica en la que se pretende analizar la
representatividad de la muestra.
Este cuestionario tiene por objetivo recopilar datos estadísticos de los participantes en el
experimento de Ciberdefensa. Esencialmente está diseñado para capturar la experiencia adquirida
en destinos relacionados con seguridad y servirá para proporcionar una valoración cualitativa de la
audiencia del experimento. El cuestionario es anónimo y será tratado como confidencial una vez
completado. Su uso únicamente está autorizado dentro de las actividades relacionadas con el
análisis del evento.
Cuestionario Demográfico
Por favor indique su empleo
1.
2.
3.
a.
b.
c.
d.
e.
f.
g.
CORONEL
TENIENTE CORONEL
COMANDANTE
CAPITÁN
TENIENTE
CIVIL
OTROS
Si la respuesta anterior fue OTROS, indique cual:
¿Cuál es su edad?
Página | 3
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
¿Cuántos años tiene de servicio en las Fuerzas Armadas?
4.
a.
b.
c.
d.
e.
f.
1-5
6-10
11-15
16-20
21-25
Más de 25
¿Cuántos años de experiencia acumula en destinos relacionados con seguridad?
5.
a.
b.
c.
d.
1-3
4-6
7-9
10 ó más
Por favor, indique su destino actual
6.
Indique por favor las redes tácticas y sistemas CIS de la que dispone su organización
7.
La segunda parte se corresponderá con preguntas de tipo Escala de Likert o de texto libre.
Con ellas se pretende recoger un estado de las acciones de ciberseguridad que se están
llevando a cabo en los distintos organismos y por parte de los representantes de éstos en el
experimento y están basadas en una serie de veinte controles críticos definidos por CSIS
(Center forStrategic& Internacional Studies)1.
Este cuestionario tiene por objetivo recoger su opinión con respecto los temas de discusión tratados para
cada escenario que se le presenta. En ellos, normalmente se propondrá una modalidad de apoyo
logístico sobre la que se basan las siguientes preguntas. El cuestionario es anónimo y será tratado como
confidencial una vez completado. Su uso únicamente está autorizado dentro de las actividades
relacionadas con el análisis del evento.
Unas preguntas son de texto libre y otras de elección con múltiples respuestas. Por favor lea atentamente
las preguntas y conteste la opción que considera más ajustada según su experiencia y criterio, de
acuerdo con la escala de graduación que se incluye más abajo. Recuerde que no todos los “1” tienen
connotaciones negativas ni todos los “6” positivas.
1
http://www.sans.org/critical-security-controls/
Página | 4
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Este cuestionario se circunscribe al plano Táctico y a su interactuación con Redes de Sistemas Tácticos
de Mando y Control y a la red de Propósito General cuando fuese necesario para el desarrollo de
operaciones tanto en Zona de Operaciones como en territorio nacional.
La “organización” en este cuestionario se entiende como aquella que facilita el acceso a los medios
técnicos para interactuar con esos sistemas y, por tanto, la responsable de la relación de usted con
dichos sistemas tácticos C2.
Muy en
desacuerdo
En
desacuerdo
Ligeramente en
desacuerdo
Ligeramente
de acuerdo
De acuerdo
Totalmente de
acuerdo
1
2
3
4
5
6
C
Cuestionario Controles- Capacidades
Realizar un control de los dispositivos disponibles en la
1. red es un primer paso en la seguridad de su
1
2
3
4
5
6
NS/NC
1
2.
Existe un inventario de los dispositivos autorizados para
estar conectados a su red y cuáles no lo deben estar.
1
2
3
4
5
6
NS/NC
1
3.
Se dispone de mecanismos de bloqueo y detección para
los no autorizados.
1
2
3
4
5
6
NS/NC
1
4. nuevos equipos que se pretendan conectar a la red que
1
2
3
4
5
6
NS/NC
1
Existen herramientas en su infraestructura de red que
monitoricen y detecten esta circunstancia.
1
2
3
4
5
6
NS/NC
1
6.
Se debe disponer de un inventario del software
autorizado e instalado en los equipos pertenecientes a
su red
1
2
3
4
5
6
NS/NC
2
7.
Facilitaría las labores de gestión, administración y
mantenimiento de los programas instalados
1
2
3
4
5
6
NS/NC
2
infraestructura TICs
Existen procedimientos de seguridad con respecto a
se pretende controlar.
5.
Página | 5
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
8.
Puede provocar un gran inconveniente para los usuarios
al no poder instalar por su cuenta ninguna aplicación.
1
2
3
4
5
6
NS/NC
2
9.
Existen implementadas herramientas
centralizado de software en su entorno.
1
2
3
4
5
6
NS/NC
2
Su organización tiene implementada una gestión de
configuración
formal
que
permita
detectar
10. vulnerabilidades debidas a software instalado en
portátiles, dispositivos móviles, estaciones de trabajo o
servidores.
1
2
3
4
5
6
NS/NC
3
11.
Tiene implementado un proceso de control de cambios
del software.
1
2
3
4
5
6
NS/NC
3
12.
Se mantiene una relación de vulnerabilidades de
seguridad actualizada en su organización.
1
2
3
4
5
6
NS/NC
4
13. mitigaciones disponibles para ser utilizadas en caso
1
2
3
4
5
6
NS/NC
4
14. organización
Existen procesos y herramientas utilizados en su
para detectar prevenir y corregir
aplicaciones maliciosas (malware).
1
2
3
4
5
6
NS/NC
5
Se contemplan en su organización la realización de
auditorías de seguridad de código (a realizar por la
15. organización o algún órgano técnico del Ministerio de
Defensa), que detecten defectos de seguridad en el
desarrollo o adquisición de aplicaciones software.
1
2
3
4
5
6
NS/NC
6
Se realiza algún tipo de análisis de riesgo en el
desarrollo de software utilizando “casos de abuso”2
1
2
3
4
5
6
NS/NC
6
de
control
Existe para estas vulnerabilidades una relación de
necesario.
16.
2
Mecanismo similar a los casos de uso que describen el comportamiento del sistema abajo ataque. Es
una forma de entrar en la mente de los atacantes. Se debe conocer lo que se quiere proteger,de quién y
por cuánto tiempo.
Página | 6
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Se lleva a cabo el análisis de la seguridad del código
17. fuente desarrollado como mecanismo de verificación y
1
2
3
4
5
6
NS/NC
6
1
2
3
4
5
6
NS/NC
6
1
2
3
4
5
6
NS/NC
7
1
2
3
4
5
6
NS/NC
8
1
2
3
4
5
6
NS/NC
9
22. un plan integrado de formación y evaluación a los
1
2
3
4
5
6
NS/NC
9
Se realiza el control de configuración y control de
cambios de las posibles debilidades de seguridad en
23.
dispositivos de red tales como firewalls, routers y
switches.
1
2
3
4
5
6
NS/NC 10
Se tienen en cuenta en la seguridad los puertos,
protocolos y servicios de los equipos conectados en red.
1
2
3
4
5
6
NS/NC 11
1
2
3
4
5
6
NS/NC 11
validación estático
Se realizan pruebas de seguridad basadas en el riesgo y
18. tests de penetración de las aplicaciones (“Hackeo ético”)
dinámicamente, es decir, en tiempo de ejecución
Se tienen en cuenta y controlan los dispositivos
19. conectados a redes inalámbricas y sus puntos de
acceso.
Existe una metodología probada y unos procedimientos
20. de actuación para la recuperación en un tiempo
razonable de los datos críticos en su organización
Cree que su organización está preocupada por la
21. concienciación de toda la plantilla en temas de
seguridad, realizándose cursos al efecto.
Considera que dentro de su organización se proporciona
responsables técnicos de la seguridad.
24.
Se restringen los puertos y servicios del dispositivo a
25. aquellos que sean estrictamente necesarios para
desempeñar la función que tiene encomendada.
Página | 7
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Se configuran, asignan, controlan y usan correctamente
26. los privilegios de administrador de los dispositivos, las
1
2
3
4
5
6
NS/NC 12
27. perimetral mediante proxys, redes DMZ 3 , sistemas de
1
2
3
4
5
6
NS/NC 13
Se controla el flujo de información entre redes a distintos
niveles de confianza
1
2
3
4
5
6
NS/NC 13
Se mantienen, monitorizan y analizan regularmente los
registros de auditoría de los eventos considerados
29.
significativos o que puedan afectar a la seguridad de la
organización.
1
2
3
4
5
6
NS/NC 14
Se establecen los accesos a la información siguiendo el
criterio de qué personas, equipos y/o aplicaciones tienen
30.
la “necesidad de conocer” basándose en la clasificación
aprobada de la información.
1
2
3
4
5
6
NS/NC 15
Considera que los procesos de creación, mantenimiento
y borrado de cuentas de usuario de su organización
31. garantiza el correcto uso de estas por parte de los
usuarios (cuentas inactivas, creación de cuentas con
perfil por defecto, …)
1
2
3
4
5
6
NS/NC 16
1
2
3
4
5
6
NS/NC 17
33. Prevention) para monitorizar la información sensible de la
1
2
3
4
5
6
NS/NC 17
Tiene su organización un plan de respuesta ante eventos
adversos, amenazas o incidentes, evaluado y con los
34.
recursos que lo tienen que ejecutar suficientemente
formado y entrenado.
1
2
3
4
5
6
NS/NC 18
redes y las aplicaciones.
Se encuentra bien definida y establecida una seguridad
prevención de intrusiones, firewalls,…
28.
Existe un control basado en el contenido de los datos
32. sobre la información que los usuarios comparten o
transmiten desde sus dispositivos.
Se dispone de herramientas del tipo DLP (Data Loss
organización.
3
Desmilitarizedzone – Red local que se ubica entre la red interna de una organización y una red externa.
Página | 8
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Considera que la infraestructura de red ha sido diseñada,
35. construida, actualizada y validada para resistir ataques
1
2
3
4
5
6
NS/NC 19
Se ha diseñado su red con un arquitectura mínima de
tres capas (DMZ, middleware y red privada)
1
2
3
4
5
6
NS/NC 19
Se ha definido una correcta y adecuada segmentación
en Redes de área Local Virtuales (VLANs) en la
37. arquitectura de red basada tanto en la organización
como en la seguridad como medida preventiva de las
Amenazas Persistente Avanzadas (APT)
1
2
3
4
5
6
NS/NC 19
1
2
3
4
5
6
NS/NC 20
1
2
3
4
5
6
NS/NC 20
de amenazas complejas.
36.
Se han efectuado pruebas de penetración y ejercicios de
38. simulación de ataques más allá de los de análisis de
vulnerabilidades.
En caso afirmativo, los ha llevado a cabo una entidad
39. externa a su organización, con una perspectiva diferente
y objetiva en cuanto a los resultados obtenidos.
De esta forma, se evaluarán las capacidades que hoy en día se están proporcionando en
materia de ciberseguridad en base a dichos controles.
Figura 1. Matriz de análisis de Capacidades de Ciberdefensa.
Página | 9
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Por último, se le pedirá a los distintos asistentes que rellenen un cuestionario para recabar su
opinión al respecto de la metodología CD&E y otros aspectos organizativos con el objeto de
refinar y mejorar todo lo posible el método de cara a posibles futuros eventos.
Este cuestionario tiene por objetivo recoger su opinión con respecto los temas de discusión tratados para
cada escenario que se le presenta. En ellos, normalmente se propondrá una modalidad de apoyo
logístico sobre la que se basan las siguientes preguntas. El cuestionario es anónimo y será tratado como
confidencial una vez completado. Su uso únicamente está autorizado dentro de las actividades
relacionadas con el análisis del evento.
Unas preguntas son de texto libre y otras de elección con múltiples respuestas. Por favor lea atentamente
las preguntas y conteste la opción que considera más ajustada según su experiencia y criterio, de
acuerdo con la escala de graduación que se incluye más abajo. Recuerde que no todos los “1” tienen
connotaciones negativas ni todos los “6” positivas.
Este cuestionario se circunscribe al plano Táctico y a su interactuación con Redes de Sistemas Tácticos
de Mando y Control y a la red de Propósito General cuando fuese necesario para el desarrollo de
operaciones tanto en Zona de Operaciones como en territorio nacional.
La “organización” en este cuestionario se entiende como aquella que facilita el acceso a los medios
técnicos para interactuar con esos sistemas y, por tanto, la responsable de la relación de usted con
dichos sistemas tácticos C2.
Muy en
desacuerdo
En
desacuerdo
Ligeramente en
desacuerdo
Ligeramente
de acuerdo
De acuerdo
Totalmente de
acuerdo
1
2
3
4
5
6
Cuestionario Final - Dinámica de Grupo
1.
Mi experiencia previa en la materia a tratar me han
permitido aportar ideas valiosas que enriquecieron las
discusiones dirigidas
1
2
3
4
5
6
NS/NC
2.
La composición de los grupos fue adecuada (no
excesivamente numerosa) para facilitar la expresión de
ideas de todos los participantes
1
2
3
4
5
6
NS/NC
3.
La composición del grupo fue suficientemente
heterogénea para abarcar diversas posiciones y puntos
de vista
1
2
3
4
5
6
NS/NC
4.
En la dinámica del grupo, evalúe la participación de
todos los representantes (1- fue similar, 6- una
persona impuso su criterio y acaparó la voz la mayor
parte del tiempo)
1
2
3
4
5
6
NS/NC
Cuestionario Final – Desarrollo de las Sesiones
Página | 10
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
5.
6.
Las herramientas puestas a mi disposición, permitieron
expresar mis opiniones de forma clara y completa.
Los cuestionarios presentados fueron adecuados para
completar y capturar mi opinión sobre los temas
tratados
1
2
3
4
5
6
NS/NC
1
2
3
4
5
6
NS/NC
7.
Evalúe la duración de las sesiones para tratar todos los
objetivos de análisis. (1- sesiones muy cortas, 6sesiones muy largas)
1
2
3
4
5
6
NS/NC
8.
La estructuración de las sesiones fue adecuada para
tratar todos los objetivos de análisis.
1
2
3
4
5
6
NS/NC
9.
Los escenarios presentados fueron de gran ayuda para
situar en contexto el concepto de logística conjunta
1
2
3
4
5
6
NS/NC
1
2
3
4
5
6
NS/NC
Evalúe el número de sesiones totales del experimento
10. (1- pocas sesiones, no permitió abordar todos los
temas; 6-excesivas sesiones, muy cansado y repetitivo)
Cuestionario Final – Infraestructura del Experimento
11.
Las salas de experimentación proporcionadas por el
ITM fueron muy adecuadas para la ejecución del
experimento
1
2
3
4
5
6
NS/NC
12.
Los sistemas CIS utilizados funcionaron correctamente
1
2
3
4
5
6
NS/NC
Por favor comente sobre los servicios adicionales
13. proporcionadas por el ITM: comida, instalaciones,
mobiliario, acceso, etc.
NS/NC
Matriz de recolección de datos
Página | 11
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
En cada una de las fases (I y II) se ejecutará la secuencia reflejada en la metodología:
Reconocimiento, Mapeo de Red, Análisis de Vulnerabilidades, Proceso de Ataque, Instalación
de puertas traseras y ataques DDoS.
Al comienzo, es decir, durante las tres primeras fases se obtendrán para cada una de las
máquinas, los siguientes datos:
ESCENARIO FASE 1
Maquina i4
Dir. IP
FASE j5
COMIENZO
Número de puertos/servicios abiertos
6
7
Códigos CVSS asociados a las vulnerabilidades conocidas en estos servicios .
Vulnerabilidades nivel alto
8
Vulnerabilidades nivel medio
Vulnerabilidades nivel bajo
9
10
INTERMEDIO – ATACANTE
TIEMPO11 TIPO DE ATAQUE
EVENTO
INTERMEDIO – ATACADO
TIEMPO
TIPO DE DEFENSA
EVENTO
4
Para cada uno de los nodos i habrá que recoger esta información.
[NODO1 – SIMACET GU]
[NODO2 – TALOS]
[NODO 3 – TACOMS]
[NODO4 – SIMACET PU]
[NODO5 – COMFUT]
[NODO6 – FFT]
5
Para cada fase j de las siguientes: Análisis de Vulnerabilidades, Proceso Ataque, Instalación de Puertas
Traseras y Ataques DDoS
6
Incluir informe de herramienta Nessus y Nmap
7
Incluir informe de herramienta Nessus y Nmap
8
Incluir informe de herramienta Nessus y Nmap
9
Incluir informe de herramienta Nessus y Nmap
10
Incluir informe de herramienta Nessus y Nmap
11
Proporcionará el tiempo consumido en cada ataque
Página | 12
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
FINAL
Número de ataques realizados
Número de ataques exitosos
Número de ataques parcialmente exitosos
Tiempo consumido en cada ataque
Tiempo empleado en cada fase
Tiempo que ha llevado conseguir el éxito
Número de ataques detectados
Número de acciones defensivas tomadas
por cada ataque
Tiempo inactividad servicio
Tiempo de inactividad del sistema atacado
Tiempo de recuperación
Tabla 13
Tabla de datos EEA Fase 1
ESCENARIO FASE 2
Maquina i12
Dir. IP
FASE j13
COMIENZO
Número de puertos/servicios abiertos
14
15
Códigos CVSS asociados a las vulnerabilidades conocidas en estos servicios .
12
Para cada uno de los nodos i habrá que recoger esta información.
[NODO1 – SIMACET GU]
[NODO2 – TALOS]
[NODO 3 – TACOMS]
[NODO4 – SIMACET PU]
[NODO5 – COMFUT]
[NODO6 – FFT]
13
Para cada fase j de las siguientes: Análisis de Vulnerabilidades, Proceso Ataque, Instalación de Puertas
Traseras y Ataques DDoS
14
Incluir informe de herramienta Nessus y Nmap
Página | 13
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Vulnerabilidades nivel alto
16
Vulnerabilidades nivel medio
Vulnerabilidades nivel bajo
17
18
INTERMEDIO – ATACANTE
TIEMPO19 TIPO DE ATAQUE
EVENTO
INTERMEDIO – ATACADO
TIEMPO
TIPO DE DEFENSA
EVENTO
FINAL
Número de ataques realizados
Número de ataques exitosos
Número de ataques parcialmente exitosos
Tiempo consumido en cada ataque
Tiempo empleado en cada fase
Tiempo que ha llevado conseguir el éxito
Número de ataques detectados
Número de acciones defensivas tomadas
por cada ataque
Tiempo inactividad servicio
Tiempo de inactividad del sistema atacado
Tiempo de recuperación
Tabla 14
Tabla de datos EEA Fase 2.
15
Incluir informe de herramienta Nessus y Nmap
Incluir informe de herramienta Nessus y Nmap
17
Incluir informe de herramienta Nessus y Nmap
18
Incluir informe de herramienta Nessus y Nmap
19
Proporcionará el tiempo consumido en cada ataque
16
Página | 14
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
14. ANEXO F: SECUENCIA DE VERIFICACIÓN DEL EXPERIMENTO DESDE EL PUNTO DE
VISTA DE SISTEMAS.
14.1.
Servicios considerados a nivel de sistemas.
Los servicios considerados, desde el punto de vista sistémico, a efectos de determinar una
secuenciación en el proceso operativo de los sistemas participantes en el experimento, son
los siguientes:
Servicio de Inicialización caracterizado desde el punto de vista operativo por la
generación y posicionamiento de las entidades asociadas a cada sistema participante.
Este servicio determinará el Objetivo 1 a realizar por el operador de cada sistema.
Servicio de Cambios de Posicionamiento de Entidades caracterizado desde el punto de
vista operativo por la realización de forma manual o automática del movimiento o
cambio de posición de las entidades asociadas a cada sistema. Este servicio
determinará el Objetivo 2 a realizar por el operador de cada sistema.
Servicio de Mensajería caracterizado desde el punto de vista operativo por la
generación automática o manual de mensajes entre sistemas. Este servicio
determinará el Objetivo 3 a realizar por el operador de cada sistema.
A nivel de sistema otros servicios podrán ser considerados, sin embargo las actuales
limitaciones en la interoperabilidad con otros sistemas del sistema SIMACET restringe su
aplicación.
14.2.
Caracterización de los objetivos a realizar por cada sistema participante.
Página | 15
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Compañía COMFUT
La Compañía COMFUT verificará los siguientes objetivos:
Objetivos
Objetivo 1
Objetivo 2
Descripción
Generación, posicionamiento y representación en
SIMACET
Cambios de posición y representación en SIMACET
Objetivo 1:
Verificar la generación y posicionamiento de la compañía COMFUT y su
representación en SIMACET PU (Batallón) y SIMACET GU (Brigada). Utilización del
protocolo NFFI.
Acción 1
Generación y
posicionamiento
de COMFUT 1.
Acción 2
Generación y
posicionamiento
de COMFUT 2.
Acción 3
Generación y
posicionamiento
de COMFUT 3.
Resultado
esperado
Generación y
posición de
COMFUT 1.
Inspección de su
representación en
SIMACET PU.
Inspección de su
representación en
SIMACET GU.
Verificación /
Comentario
Resultado
esperado
Generación y
posición de
COMFUT 2.
Inspección de su
representación en
SIMACET PU.
Inspección de su
representación en
SIMACET GU.
Verificación /
Comentario
Resultado
esperado
Generación y
posición de
COMFUT 3.
Inspección de su
Verificación /
Comentario
Página | 16
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
representación en
SIMACET PU.
Inspección de su
representación en
SIMACET GU.
Forma de ejecución:
Manual por parte del operador de la compañía COMFUT.
Repetición de las acciones:
Una sola vez al inicio.
Incidencia en otros sistemas:
Ninguna
Objetivo 2:
Verificar los cambios de posición de la compañía COMFUT y su incidencia en
SIMACET PU (Batallón) y SIMACET GU (Brigada). Utilización del protocolo NFFI.
Acción 1
Cambio de
posición en
COMFUT 1,
según el avance
del Batallón.
Acción 2
Cambio de
posición en
COMFUT 2,
según el avance
del Batallón.
Resultado
esperado
Cambio de la
posición de
COMFUT 1.
Inspección del
cambio de
posición en
SIMACET PU.
Inspección del
cambio de
posición en
SIMACET GU.
Verificación /
Comentario
Resultado
esperado
Cambio de la
posición de
COMFUT 2.
Inspección del
cambio de
posición en
SIMACET PU.
Inspección del
Verificación /
Comentario
Página | 17
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
cambio de
posición en
SIMACET GU.
Acción 3
Resultado
esperado
Cambio de la
posición de
COMFUT 3.
Inspección del
cambio de
posición en
SIMACET PU.
Inspección del
cambio de
posición en
SIMACET GU.
Cambio de
posición en
COMFUT 3,
según el avance
del Batallón.
Verificación /
Comentario
Forma de ejecución:
Manual por parte del operador de la compañía COMFUT.
Repetición de las acciones:
TBD
Incidencia en otros sistemas:
Ninguna
Objetivo 3: No considerado.
Grupo de Artillería de Campaña TALOS.
El Grupo de Artillería de Campaña TALOS verificará los siguientes objetivos:
Objetivos
Objetivo 1
Objetivo 2
Descripción
Generación, posicionamiento y representación en
SIMACET
Cambios de posición y representación en SIMACET
Objetivo 1:
Verificar la generación y posicionamiento de elementos del Grupo de Artillería de
Campaña TALOS y su representación en SIMACET GU (Brigada). Utilización del
protocolo NFFI.
Página | 18
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Acción 1
Generación y
posicionamiento
del Observador
Avanzado (OAV)
de TALOS.
Acción 2
Generación y
posicionamiento
del Grupo de
Artillería TALOS.
Resultado esperado
Verificación /
Comentario
Generación y posición
del OAV de TALOS.
Inspección de la
representación en
SIMACET GU.
Resultado esperado
Verificación /
Comentario
Generación y posición
del Grupo de Artillería
TALOS.
Inspección de la
representación en
SIMACET GU.
Forma de ejecución:
Manual por parte del operador de TALOS.
Repetición de las acciones:
Una sola vez al inicio.
Incidencia en otros sistemas:
Ninguna
Objetivo 2:
Verificar los cambios de posición de elementos del Grupo de Artillería de Campaña
TALOS y su incidencia en SIMACET GU (Brigada). Utilización del protocolo NFFI.
Acción 1
Resultado esperado
Cambio de posición
en el Observador
Avanzado (OAV) de
TALOS, según el
avance de la
Brigada.
Cambio de la
posición del OAV en
TALOS.
Inspección del
cambio de posición
en SIMACET GU.
Acción 2
Resultado esperado
Cambio de posición
en el Grupo de
Verificación /
Comentario
Verificación /
Comentario
Cambio de la
posición del Grupo
Página | 19
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Artillería TALOS,
según el avance de
la Brigada.
de Artillería TALOS.
Inspección del
cambio de posición
en SIMACET GU.
Forma de ejecución:
Manual por parte del operador de TALOS.
Repetición de las acciones:
TBD
Incidencia en otros sistemas:
Ninguna
Objetivo 3:
No considerado
Página | 20
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Compañía FFT.
La Compañía FFT verificará los siguientes objetivos:
Objetivos
Objetivo 1
Objetivo 2
Descripción
Generación, posicionamiento y representación en
SIMACET
Cambios de posición y representación en SIMACET
Objetivo 1:
Verificar la generación y posicionamiento de la compañía FFT y su representación en
SIMACET PU (Batallón) y SIMACET GU (Brigada). Utilización del protocolo NFFI.
Acción 1
Resultado esperado
Generación y
posicionamiento
de la Compañía
FFT.
Generación y posición de
la Compañía FFT.
Inspección de la
representación en
SIMACET PU.
Inspección de la
representación en
SIMACET GU.
Verificación /
Comentario
Forma de ejecución:
Manual por parte del operador de la Compañía FFT.
Repetición de la acción:
Una sola vez al inicio.
Incidencia en otros sistemas:
Ninguna
Objetivo 2:
Verificar los cambios de posición de la compañía FFT y su incidencia en SIMACET PU
(Batallón) y SIMACET GU (Brigada). Utilización del protocolo NFFI.
Acción 1
Cambio de posición
en Compañía FFT,
según el avance del
Resultado esperado
Verificación /
Comentario
Cambio de la
posición de la
Compañía FFT.
Página | 21
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Batallón.
Inspección del
cambio de posición
en SIMACET PU.
Inspección del
cambio de posición
en SIMACET GU.
Forma de ejecución:


Manual por parte del operador de la Compañía FFT.
Automática, generándose un desplazamiento circular de la compañía, de radio
predeterminado.
Repetición de la acción:


Manual: TBD
Automática: Continuada.
Incidencia en otros sistemas:
Ninguna
Objetivo 3:
No considerado
Página | 22
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Grupo de Inteligencia GESTA.
El Grupo de Inteligencia GESTA verificará los siguientes objetivos:
Objetivos
Objetivo 1
Objetivo 2
Objetivo 3
Descripción
Generación, posicionamiento y representación en
SIMACET
Cambios de posición y representación en SIMACET
Generación de mensajería y representación en SIMACET
Objetivo 1:
Verificar la generación y posicionamiento de elementos del Grupo de Inteligencia
GESTA y su representación en SIMACET GU (Brigada).
Acción 1
Resultado esperado
Generación y
posicionamiento
de entidades
GESTA.
Generación y posición de
entidades GESTA.
Inspección de la
representación en
SIMACET GU.
Acción 2
Resultado esperado
Verificación /
Comentario
Verificación /
Comentario
Forma de ejecución:
Manual por parte del operador de GESTA.
Repetición de las acciones:
Una sola vez al inicio.
Incidencia en otros sistemas:
Ninguna
Objetivo 2:
Verificar los cambios de posición de elementos del Grupo de Inteligencia GESTA y su
incidencia en SIMACET GU (Brigada).
Acción 1
Resultado esperado
Página | 23
Verificación /
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Comentario
Cambio de posición
en entidades
GESTA, según el
avance de la
Brigada.
Acción 2
Cambio de la
posición de
entidades GESTA.
Inspección del
cambio de posición
en SIMACET GU.
Resultado esperado
Verificación /
Comentario
Forma de ejecución:
Manual por parte del operador de GESTA.
Repetición de las acciones:
TBD
Incidencia en otros sistemas:
Ninguna
Objetivo 3:
Verificar la generación de mensajería de forma manual o automática asociada a las
entidades GESTA y su incidencia en SIMACET GU (Brigada).
Acción 1
Generación de
mensajería de
entidades GESTA.
Resultado esperado
Verificación /
Comentario
Mensajes GESTA
generados.
Inspección de la
presentación de la
mensajería en
SIMACET GU.
Forma de ejecución:


Manual por parte del operador de GESTA.
Automáticamente por parte del sistema.
Repetición de las acciones:
TBD
Página | 24
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Incidencia en otros sistemas:
Interoperabilidad con SIMACET.
Página | 25
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Brigada SIMACET GU.
La Brigada SIMACET GU verificará los siguientes objetivos:
Objetivos
Objetivo 1
Objetivo 2
Objetivo 3
Descripción
Generación, posicionamiento y representación en otros
sistemas
Cambios de posición y representación en otros sistemas
Generación de mensajería y representación en otros
sistemas
Objetivo 1:
Verificar la generación y posicionamiento de la Brigada SIMACET GU y su
representación en SIMACET PU (Batallón) y Grupo de Inteligencia GESTA.
Acción 1
Resultado esperado
Generación y
posicionamiento
de la Brigada
SIMACET GU.
Generación y posición de
la Brigada.
Inspección de la
representación en
SIMACET PU y GESTA.
Acción 2
Resultado esperado
Verificación /
Comentario
Verificación /
Comentario
Forma de ejecución:
Manual por parte del operador de SIMACET GU.
Repetición de las acciones:
Una sola vez al inicio.
Incidencia en otros sistemas:
Ninguna
Objetivo 2:
Verificar los cambios de posición de la Brigada SIMACET GU y su incidencia en SIMACET
PU (Batallón) y Grupo de Inteligencia GESTA.
Página | 26
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Acción 1
Resultado esperado
Cambio de posición
en la Brigada
SIMACET GU.
Cambio de la
posición de Brigada.
Inspección del
cambio de posición
en SIMACET PU y
GESTA.
Acción 2
Resultado esperado
Verificación /
Comentario
Verificación /
Comentario
Forma de ejecución:
Manual por parte del operador de SIMACET GU.
Repetición de las acciones:
TBD
Incidencia en otros sistemas:
Ninguna
Objetivo 3:
Verificar la generación de mensajería de forma manual o automática asociada a la
Brigada SIMACET GU y su incidencia en SIMACET PU (Batallón) y Grupo de Inteligencia
GESTA.
Acción 1
Generación de
mensajería de
entidades de
Brigada.
Resultado esperado
Verificación /
Comentario
Mensajes SIMACET
GU generados.
Inspección de la
presentación de la
mensajería en
SIMACET PU y
GESTA.
Forma de ejecución:


Manual por parte del operador de SIMACET GU.
Automáticamente por parte del sistema.
Página | 27
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Repetición de las acciones:
TBD
Incidencia en otros sistemas:
Interoperabilidad con SIMACET PU y GESTA.
Página | 28
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Batallón SIMACET PU.
El JBON SIMACET PU verificará los siguientes objetivos:
Objetivos
Objetivo 1
Objetivo 2
Objetivo 3
Descripción
Generación, posicionamiento y representación en otros
sistemas
Cambios de posición y representación en otros sistemas
Generación de mensajería y representación en otros
sistemas
Objetivo 1:
Verificar la generación y posicionamiento del JBON SIMACET PU y su representación en
SIMACET GU (Brigada) y Grupo de Inteligencia GESTA.
Acción 1
Generación y
posicionamiento
del JBON
SIMACET PU.
Acción 2
Resultado esperado
Verificación /
Comentario
Generación y posición
del JBON.
Inspección de la
representación en
SIMACET GU y GESTA.
Resultado esperado
Verificación /
Comentario
Forma de ejecución:
Manual por parte del operador de SIMACET PU.
Repetición de las acciones:
Una sola vez al inicio.
Incidencia en otros sistemas:
Ninguna
Objetivo 2:
Verificar los cambios de posición del JBON SIMACET PU y su incidencia en SIMACET GU
(Brigada) y Grupo de Inteligencia GESTA.
Página | 29
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Acción 1
Cambio de posición
en el JBON SIMACET
PU.
Acción 2
Resultado esperado
Verificación /
Comentario
Cambio de la
posición del JBON.
Inspección del
cambio de posición
en SIMACET GU y
GESTA.
Resultado esperado
Verificación /
Comentario
Forma de ejecución:
Manual por parte del operador de SIMACET PU.
Repetición de las acciones:
TBD
Incidencia en otros sistemas:
Ninguna
Objetivo 3:
Verificar la generación de mensajería de forma manual o automática asociada al JBON
SIMACET PU y su incidencia en SIMACET GU (Brigada) y Grupo de Inteligencia GESTA.
Acción 1
Generación de
mensajería de
entidades JBON.
Resultado esperado
Verificación /
Comentario
Mensajes SIMACET
PU generados.
Inspección de la
presentación de la
mensajería en
SIMACET GU y
GESTA.
Forma de ejecución:


Manual por parte del operador de SIMACET PU.
Automáticamente por parte del sistema.
Repetición de las acciones:
Página | 30
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
TBD
Incidencia en otros sistemas:
Interoperabilidad con SIMACET GU y GESTA.
Sistema de Comunicaciones Tácticas TACOM.
Por definir.
Página | 31
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
14.3.
Proceso de secuenciación del experimento a nivel de sistemas.
Con independencia del escenario considerado en el que operaran los sistemas
participantes en el experimento, la realización de los objetivos indicados mantendrán el
siguiente proceso de secuenciación operativa.
El proceso mantendrá la siguiente secuencia:
Inicialización.
La secuencia de inicialización será la siguiente:
1
Entidades
Brigada
2
Batallón
3
4
Grupo de Inteligencia
Grupo de Artillería de
Campaña
Compañía FFT
Compañía COMFUT
5
6
7
Sistemas
SIMACET
GU
SIMACET
PU
GESTA
TALOS
Verificación
Objetivo 1
FFT
COMFUT
TACOM
Objetivo 1
Objetivo 1
Objetivo 1
Objetivo 1
Objetivo 1
Iteración.
La secuencia de iteración será la contraria a la de inicialización:
Entidades
Página | 32
Sistemas
Verificación
DDE V 3.2
28/11/2012
MINISTERIO DE DEFENSA
Sistemas
COMFUT
FFT
TALOS
Verificación
Objetivo 2
Objetivo 2
Objetivo 2
4
Entidades
Compañía COMFUT
Compañía FFT
Grupo de Artillería de
Campaña
Grupo de Inteligencia
GESTA
5
Batallón
6
Brigada
SIMACET
PU
SIMACET
GU
TACOM
Objetivos 2
y3
Objetivos 2
y3
Objetivos 2
y3
1
2
3
7
Estas secuenciaciones serán llevadas a cabo mediante las acciones indicadas en el
apartado anterior para cada sistema participante.
14.4.
Fases de ataque desde el punto de vista de sistemas.
Desde el punto de vista de la secuenciación planteada a nivel de sistemas las fases de
ataque irán asociadas a la inicialización e iteración dentro del proceso de secuenciación
operativa como se muestra a continuación.
Página | 33
DDE V 3.2
28/11/2012