Jnic2015 PDF

RIASC, Universidad de Leon INCIBE
ACTAS DE LAS PRIMERAS

JORNADAS
NACIONALES DE
EN
INVESTIGACION
CIBERSEGURIDAD
Leon. 14, 15, 16 de septiembre 2015
Jornadas Nacionales de Investigacion en Ciberseguridad (1a . 2015. Leon)

Actas de las primeras Jornadas Nacionales de Investigacion en Ciberseguridad .
Leon, 14, 15, 16 de septiembre de 2015 : I JNIC2015 [Leon] : Universidad de Leon,
Area
de Publicaciones, 2015
1 recurso en lnea (XI, 211 p)
Indice. En la port.: RIASC, Universidad de Leon, INCIBE. Bibliograf..
Textos en espanol e ingles. Ttulo tomado de la portada del PDF
ISBN 978-84-9773-742-5
1. Informatica-Seguridad-Medidas-Investigacion-Congresos. 2. InternetSeguridad-Medidad-Investigacion-Congresos. 3. Proteccion de la informacion
(Informatica)-Investigacion-Congresos. I. Universidad de Leon. Area

de Publicaciones.
II. Instituto Nacional de Ciberseguridad. III. Research Institute of Applied Sciences in
Cybersecurity
004.738.5.056:001.891(063)
001.891(063):004.738.5.056
004.056:001.891(063)
001.891(063):004.056
c
Universidad
de Leon
Area de Publicaciones
c
RIASC,
Universidad de Leon INCIBE
Esta permitida la descarga y la reproduccion total o parcial de esta obra y
y su difusion siempre y cuando sea para uso personal o academico.
Los derechos de autor de cada contribucion individual corresponden a sus autores.
ISBN: 978-84-9773-742-5
JNIC2015
Prefacio
Las Jornadas Nacionales de Investigacion en Ciberseguridad nacen este ano 2015 en el seno de los
grupos de trabajo fomentados por el Instituto Nacional de Ciberseguridad INCIBE que es tambien
co-organizador del evento junto con el Instituto de Ciencias Aplicadas a la Ciberseguridad (Research
Institute of Applied Sciences in Cybersecurity, RIASC) de la Universidad de Leon.
Se ha hecho un gran esfuerzo por parte de todos los integrantes de los grupos de trabajo para
que la primera edicion tenga lugar este mismo ano. Tambien nacen con vocacion de continuidad y
con el objetivo claro de fomentar un lugar de encuentro estable en Espana para los investigadores en
ciberseguridad.
Finalmente se tiene un completo programa con diez sesiones que abarcan los siguientes temas:
Primera sesion: Vulnerabilidades, malware y exploits 1
Segunda sesion: Artculos cortos - Vulnerabilidades, Malware y exploits
Tercera sesion: Seguridad, ataques y contramedidas
Cuarta sesion: Seguridad en redes
Quinta sesion: Artculos cortos - Seguridad en Redes, ataques, contramedidas y criptografa
Sexta sesion: Vulnerabilidades, malware y exploits 2
Septima sesion: Privacidad, Criptografa y autentificacion
Octava Sesion: Temas relacionados con la ciberseguridad
Novena sesion: Ciberseguridad en Industria
Decima sesion: Innovacion docente en ciberseguridad
Las sesiones de las Jornadas se celebran en la Real Colegiata de San Isidoro, en Leon, los das 14, 15
y 16 de septiembre. Esperamos sinceramente que estos das sean productivos para todos los asistentes.
Leon, 11 de septiembre de 2015
El Comite Editorial
Miguel V. Carriegos
JNIC2015
Comite ejecutivo
Gilles Barthe
Jose Bernabeu Auban
Miguel V. Carriegos
Luis Castillo
Antonio Fernandez-Anta
Pablo Garca Bringas
Pedro Garca-Teodoro
Angel
Gomez de Agreda
Santos Gonzalez
Javier Lopez
Mario Piattini
Antonio Ramos
Raul Riesco Granadinos
Jose Mara Sierra Camara
Miquel Soriano
Carmela Troncoso
Vctor A. Villagra
IMDEA Software Institute

Universitat Politècnica de València
Universidad de Leon
Universidad de Granada
IMDEA Networks Institute
DeustoTech, Universidad de Deusto
Mando Conjunto de Ciberdefensa
Universidad de Oviedo
Universidad de Malaga
Universidad de Castilla-La Mancha
MundoHacker
Instituto Nacional de Ciberseguridad
Universidad Carlos III de Madrid
Universitat Politècnica de Catalunya
Gradiant - Centro Tecnologico de Telecomunicaciones de Galicia
Universidad Politecnica de Madrid
ii
JNIC2015
Comite organizador
General Chair
Javier Alonso
Universidad de Leon
Program Chairs
Migue V. Carriegos
Ramon Angel
Fernandez Daz
Universidad de Leon
Universidad de Leon
Financial Chair
Adriana Suarez Corona
Universidad de Leon
Workshop Chair
Pedro Garca-Teodoro
Industrial Track Chair

Ignacio Cano
Instituto Nacional de Ciberseguridad
Education & Innovation Track

Chair
Gregorio Martnez Perez
Universidad de Murcia
Challenges Track Chair

Juan Tapiador
Students Session Chair

Juan Caballero
Publication Chairs
Juan Felipe Garca Sierra
Jorge Lorenzana Tamargo
Universidad de Leon
Universidad de Leon
Publicity Chairs
Paolo Casari
Igor Santos
IMDEA Networks Institute

Local Arrangement Chairs

Juan Felipe Garca Sierra
Ricardo J. Rodrguez
Universidad de Leon
Universidad de Leon
Web Master
Sara Isabel Gonzalez
Jorge Lorenzana Tamargo
Universidad de Leon
Universidad de Leon
iii
JNIC2015
Comite de programa
chair: Miguel V. Carriegos
chair: Ramon Angel

Fernandez
Isaac Agudo
Cristina Alcaraz
Enrique Alegre Gutierrez
Javier Alonso
Rafael Ignacio Alvarez

Sanchez
Inaki Arenaza
Patricia Arias Cabarcos
Simona Bernardi
Alvaro
Botas
Juan Caballero
Pino Caballero Gil
Jordi Castellà-Roca
Josep Domingo-Ferrer
Jose-Luis Ferrer-Gomila
Dario Fiore
David G. Rosado
Juan F. Garca
Luis Javier Garca Villalba
Pedro Garca-Teodoro
Mara Isabel Gonzalez Vasco
Juan Hernandez-Serrano
Boris Kopf
Olga Leon
Javier Lopez
Gabriel Lopez Millan
Andres Marn Lopez
Angel
Martn del Rey
Gregorio Martnez Perez
David Megas
Alfonso Munoz
Guillermo Navarro
Jorge Ramio
Sergi Robles
Ricardo J. Rodrguez
Antonio Ruiz Martnez
Manuel Sanchez Rubio
Ana Lucila Sandoval Orozco
Igor Santos
Juan Tapiador
Juan Tena
Salvador Trujillo
Juan Vera Del Campo
Alexandre Viejo
Universidad de Leon
Universidad de Leon
Universidad de Leon
Universidad de Leon
Universidad de Alicante
Universidad de Mondragon
Centro Universitario de la Defensa
Universidad de Leon
Universidad de La Laguna
Universitat Rovira i Virgili
Universidad de las Islas Baleares
Universidad de Castilla-La Mancha
Universidad de Leon
Universidad Complutense de Madrid
Universidad Rey Juan Carlos
Universidad de Salamanca
Universitat Oberta de Catalunya
Criptored, Universidad Politecnica de Madrid
Universidad Autonoma de Barcelona
Universidad Autonoma de Barcelona
Universidad de Leon
Universidad de Alcala
Universidad Complutense de Madrid
Universidad de Valladolid
IKERLAN Research Centre
iv
JNIC2015
Vctor A. Villagra
Antonio Zamora Gomez
Urko Zurutuza

Universidad de Alicante
Universidad de Mondragon
JNIC2015
Revisores adicionales
Carles Angles
Vicenc Creus
Eduardo Fidalgo Fernandez
Francisco Martn-Fernandez
Jose Luis Montero
Ana Nieto
vi
JNIC2015
Contenidos
Primera sesi
on: Vulnerabilidades, malware y exploits 1
Propagacion del malware: nuevos modelos para nuevos escenarios . . . . . . .
A. Martn del Rey, A. Hern
andez Encinas, J. Martn Vaquero, A.
Queiruga Dios and G. Rodrguez S
anchez
Sistema de Deteccion de Intrusos aplicando Seleccion Negativa en
Perfiles de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cesar Guevara, Matilde Santos and Victoria L
opez
Segunda sesi
on: Artculos cortos: Vulnerabilidades, Malware y
exploits
The Attack of the Clones: A Study of the Impact of Shared Code on
Vulnerability Patching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Antonio Nappa, Richard Johnson, Leyla Bilge, Juan Caballero and Tudor Dumitras
14
Experiences on NFC Relay Attacks with Android: Virtual Pickpocketing

Revisited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jose Vila and Ricardo J. Rodrguez
16
CARONTE : Detecting Location Leaks for Deanonymizing Tor Hidden

Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Srdjan Matic, Platon Kotzias and Juan Caballero
18
Prevencion de ataques ROP mediante Instrumentacion Dinamica . . . . . . .

Miguel Martn Perez, Ricardo J. Rodrguez and Vctor Vi
nals
20
Robustenciendo Apache frente a ataques de desbordamiento de pila . . . . .

Hector Marco and Ismael Ripoll
22
Prevencion de explotacion de vulnerabilidades mediante diversificacion

por emulacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ismael Ripoll and Hector Marco
24
Tercera sesi
on: Seguridad, ataques y contramedidas
Sistema Inmunitario Adaptativo para la mitigacion de ataques de
Denegacion de Servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jorge Maestre Vidal, Ana Lucila Sandoval Orozco and Luis Javier
Garca Villalba
La utilizacion de herramientas de monitorizacion de usuarios como base
para el perfilado de identidades en fuentes abiertas: OSRFramework . . . . .
Yaiza Rubio and Felix Brezo
vii
26
32
JNIC2015
Neural Networks applied to the learning process of Automated

Intrusion Response systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pilar Holgado and Victor A. Villagr
a
Spam Honeypots in Cloud Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carlos Cilleruelo Rodrguez, Alberto Cuesta Parejo and Manuel S
anchez
Rubio
39
45
Cuarta sesi
on: Seguridad en redes
Security via Underwater Acoustic Networks: the Concept and Results
of the RACUN Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paolo Casari, Joerg Kalwa, Michele Zorzi, Stefano Nasta, Sabrina
Schreiber, Roald Otnes, Paul van Walree, Michael Goetz, Arwid Komu
lainen, Bernt Nilsson, Jan Nilsson, Tommy Oberg,
Ivor Nissen, Henrik
Strandberg, Henry Dol, Geert Leus and Francesco Pacini
Sistema visual de monitorizacion de seguridad de flujos de red industriales
Mikel Iturbe, I
naki Garitano, Urko Zurutuza and Roberto Uribeetxeberria
Correlacion de alertas en la deteccion de malware en redes basada en
anomalas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jorge Maestre Vidal, Ana Lucila Sandoval Orozco and Luis Javier
Garca Villalba
51
59
67
Quinta sesi
on: Artculos cortos: Seguridad en Redes, ataques,
contramedidas y criptografa
Rational Protection Against Timing Attacks . . . . . . . . . . . . . . . . . . . . . . . . .
Goran Doychev and Boris K
opf
72
Resource Monitoring for the Detection of Parasite P2P Botnets . . . . . . . . . 74

Rafael A. Rodrguez-G
omez, Gabriel Maca-Fern
andez and Pedro GarcaTeodoro
Multigraph Project: First Steps towards the Definition of a Multiple
Attack Graph Model Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mattia Zago, Juan Jose Andreu Bl
azquez, Manuel Gil Perez and Gregorio Martnez Perez
Seguridad definida por software en subestaciones electricas . . . . . . . . . . . . .
Elas Molina, Armando Astarloa and Eduardo Jacob
VERITAS: Visualizacion de Eventos en Red Inteligente para el
Tratamiento y Analisis de la Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jose Camacho, Gabriel Maci
a-Fern
andez, Pedro Garca-Teodoro and
Roberto Ther
on
viii
76
78
80
JNIC2015
Security services as cloud capabilities using MAS . . . . . . . . . . . . . . . . . . . . .

Fernando De La Prieta, Luis Enrique Corredera de Colsa, Alberto
L
opez Barriuso and Juan M. Corchado
Programmable Hash Functions go Private: Contructions and
Applications to (Homomorphic) Signatures with Shorter Public Keys . . . .
Dario Catalano, Dario Fiore and Luca Nizzardo
Certified PUP: Abuse in Authenticode Code Signing . . . . . . . . . . . . . . . . . .
Platon Kotzias, Srdjan Matic, Richard Rivera and Juan Caballero
Aplicacion del cifrado con preservacion del formato para eventos de
ciberseguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L. Gonz
alez Manzano, J. M. de Fuentes and V. Gayoso Martnez
Modelling ephemeral leakage in group key exchange protocols . . . . . . . . . . .
Mara Isabel Gonz

alez Vasco, Angel
L. Perez del Pozo and Adriana
Su
arez Corona
82
84
86
88
90
Sexta sesi
on: Vulnerabilidades, malware y exploits 2
Deteccion de funciones inseguras en repositorios de software libre . . . . . . .
Alfonso Mu
noz Mu
noz and Pablo Gonz
alez Perez
Ingeniera inversa: metodos utilizados y analisis de tecnicas para la
proteccion de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Alberto Garca Moro and Vctor A. Villagr
a Gonz`
alez
92
99
Prototipado rapido de un analizador de malware para Android

empleando Razonamiento Basado en Casos . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Francisco J. Ribadas-Pena and Manuel Ba
nobre-G
omez
S
eptima sesi
on: Privacidad, Criptografa y autentificaci
on
Informing Protocol Design Through Crowdsourcing: the Case of
Pervasive Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Anna Maria Mandalari, Marcelo Bagnulo and Andra Lutu
Cifrado de datos con preservacion del formato . . . . . . . . . . . . . . . . . . . . . . . . 110
V. Gayoso Martnez, L. Hern
andez Encinas, A. Martn Mu
noz, J. M.
de Fuentes and L. Gonz
alez Manzano
Codigos monomiales vistos como subespacios vectoriales invariantes . . . . . 116
M. I. Garca Planas, M. D. Magret and L.E. Um
Octava Sesi
on: Temas relacionados con la ciberseguridad
Towards Automatic Integration of Information Security Governance
and Management using a BPMS approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Angel
J. Varela Vaca and Rafael M. Gasca
ix
JNIC2015
Evolving from a static toward a proactive and dynamic risk-based

defense strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Pilar Holgado, Manuel Gil Perez, Gregorio Martnez Perez and Vctor
A. Villagr
a
How to find an image despite it has been modified . . . . . . . . . . . . . . . . . . . . 137
Diego Garca Ord
as, Laura Fern
andez Robles, Mara Teresa Garca
Ord
as, Oscar Garca-Olalla Olivera and Enrique Alegre
Inseguridad en infraestructuras crticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Manuel S
anchez Rubio, Jose Miguel G
omez-Casero Marichal and Carlos Cilleruelo Rodrguez
Novena sesi
on: Ciberseguridad en Industria
Reto en ciberseguridad: analisis forense de discos . . . . . . . . . . . . . . . . . . . . . . 148
Andres Caro
Research-to-market transition in European Cybersecurity Projects . . . . . . 156
Aljosa Pasic
Cyber Ranges for Cybersecurity Training: Challenges and Novel
Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Jorge L
opez Hern
andez-Ardieta, Pascual Parra L
opez, David Santos
Esteban and Javier Martnez-Torres
Metodologa para el Analisis, Auditora de Seguridad y Evaluacion
del Riesgo Operativo de Redes Industriales y Sistemas SCADA
(MAASERISv2.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Fernando Sevillano and Marta Beltr
an
D
ecima sesi
on: Innovaci
on docente en ciberseguridad
Repositorio de actividades autonomas para la docencia de seguridad en
sistemas informaticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Francisco J. Ribadas-Pena, Ruben Anido-Bande and Vctor M. DarribaBilbao
Experiencias actualizando la asignatura de Seguridad Informatica para
los grados de Ingeniera Informatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Marta Beltr
an and Isaac Martn de Diego
Laboratorio Docente de Ciberseguridad basado en live-USB . . . . . . . . . . . . 182
Rafael A. Rodrguez-G
omez, Francisco L
opez Perez, Mara Guarnido
Ayll
on, M
onica Leyva Garca, Anabel Reyes Maldonado, Antonio Mu
noz
Gij
on, Jose Enrique Cano and Jose Camacho
JNIC2015
Bachillerato de Excelencia, Criptografa y Seguridad de la Informacion:

Una oportunidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Angel
Martn del Rey, Ascensi
on Hern
andez Encinas, Jes
us Martn
Vaquero, Araceli Queiruga Dios and Gerardo Rodrguez S
anchez
Graduate studies in Cyber-Security: A proposal . . . . . . . . . . . . . . . . . . . . . . . 195
Juan F. Garca, Javier Alonso and Miguel V. Carriegos
Una apuesta por la educacion en ciberseguridad desde el ambito
universitario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Andres Caro
Una propuesta para la ense
nanza de la Ciberseguridad en el Grado de
Ingeniera Informatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Jose Antonio G
omez Hern
andez
xi
JNIC2015

1
Propagacion del malware: nuevos modelos para

nuevos escenarios
A. Martn del Rey, A. Hernandez Encinas, J. Martn Vaquero,
A. Queiruga Dios, G. Rodrguez Sanchez
Departamento de Matematica Aplicada, Universidad de Salamanca, Salamanca, Espa
na.
malware. Estos
nos proporcionar
an herramientas muy u
tiles a la hora no s
olo de entender el comportamiento del
malware en su propagaci
on, sino tambien en la simulaci
on de posibles medidas de control (que ayuden a tomar
decisiones para contener la epidemia).
En la literatura cientfica se pueden encontrar muchos
modelos propuestos cuya finalidad es tratar de simular la
propagaci
on de malware, ya sea sobre redes de ordenadores o sobre redes de dispositivos m
oviles (vease, por ejemplo [4], [5], [6]). La inmensa mayora de los mismos son
modelos deterministas basados en sistemas de ecuaciones
diferenciales ordinarias ([7], [8]). Se trata de modelos p
uramente te
oricos de manera que, en casi todos los casos, su
objetivo es el estudio cualitativo del sistema de ecuaciones
diferenciales que rige la din
amica. Debido a su naturaleza
presentan tres importantes inconvenientes [9]:
(1) No tienen en cuenta las interacciones locales entre los
distintos dispositivos de la red.
(2) Suponen que los dispositivos se encuentran homogeneamente conectados y distribuidos.
(3) No tienen en cuenta las caractersticas individuales de
cada uno de los dispositivos.
En el nuevo escenario que se vislumbra (y que se puso de manifiesto al principio de esta secci
on), es necesario
tener en cuenta todos estos condicionantes ya que existen m
ultiples tipos de dispositivos conectados, cada uno
de ellos con unos roles y caractersticas muy especficas
que deben ser tenidas en cuenta a la hora de dise
nar un
modelo epidemiol
ogico eficiente. Ello se puede conseguir si
se utiliza un paradigma diferente: el de los modelos individuales. En ellos, se considera un conjunto de entidades
individuales que representar
an a los actores involucrados
en el fen
omeno de la propagaci
on del malware, se definen
sus relaciones y especificaciones en relaci
on al codigo malicioso, y se construyen las reglas de transici
on entre los
distintos estados. Los resultados que se obtienen muestran
tanto la evoluci
on individual de cada uno de los dispositivos como la evoluci
on global del sistema.
El objetivo de este trabajo es poner de manifiesto la
necesidad de la b
usqueda de nuevos modelos para hacer
frente a los nuevos escenarios planteados. Para ello se propondr
a y estudiar
a un modelo determinista basado en un
sistema de ecuaciones diferenciales ordinarias, y posteriormente se introducir
a el correspondiente modelo individual.
El resto del trabajo se organiza como sigue: en la seccion
2 se hace una breve introducci
on a los modelos individuales; el modelo determinista y su contrapartida individual
se introducen y estudian en la secci
on 3, y finalmente las
Resumen La mayor parte de los modelos matem

aticos
desarrollados para estudiar y simular la propagaci
on del
malware son modelos globales; es decir, no tienen en cuenta las caractersticas individuales de los dispositivos que
forman parte del medioambiente en el que se produce la
infecci
on. En los nuevos escenarios que se plantean (Internet de las Cosas, SmartCities, etc.), en los que la conectividad
global es poco menos que un axioma, estos modelos presentan serias deficiencias. El objetivo de este trabajo es poner
de manifiesto de manera justificada dichas deficiencias y
proponer los modelos individuales como alternativa.
n
I. Introduccio
El gran desarrollo cientfico y tecnologico de los u
ltimos
a
nos ha dado lugar a nuevos paradigmas como la Internet
de las Cosas, el BYOD, las SmartCities, la telemedicina,
los medios de transporte inteligentes, las viviendas inteligentes, etc. Estos conceptos estan a
un dando sus primeros
pasos y, aunque actualmente su nivel de implantaci
on no
es muy alto, seran los pilares sobre los que se cimente nuestra futura sociedad. En este sentido, no parece arriesgado
decir que en ella la conectividad sera global, de manera
que la mayor parte de los aspectos de nuestra vida los
podremos controlar de manera remota.
Los instrumentos tecnologicos gracias a los cuales este
nuevo escenario ser
a una realidad no son solo las computadoras sino tambien los dispositivos moviles (tabletas,
telefonos inteligentes,...), los dispositivos wereables, los
electrodomesticos inteligentes, etc.
Desafortunadamente este idlico paraso tecnol
ogico no
se encuentra exento de amenazas. Sin duda, la m
as importante es la debida a la accion del codigo malicioso (tambien conocido como malware, su acronimo en Ingles).
Los costes que ocasiona tanto economicos como sociales e
incluso polticos son cuantiosos, con lo que la lucha contra
el mismo supone uno de los grandes retos de la Ciberseguridad.
Esta lucha se lleva a cabo en diferentes frentes: desde la concienciacion del usuario para que adopte medidas
de seguridad oportunas hasta la adopcion e implantaci
on
de polticas de seguridad adecuadas en los distintos organismos y compa
nas, pasando por el desarrollo de software antivirus por parte de las empresas especializadas.
Adem
as la comunidad cientfica ha prestado especial atenci
on al dise
no de metodos y algoritmos para detectar la
presencia de malware en los distintos dispositivos ([1], [2],
[3]). Aunque esta es una lnea de actuacion fundamental, hemos de considerar tambien como actuaci
on complementaria el desarrollo de modelos matematicos que nos
permitan simular el comportamiento de una epidemia de
JNIC2015

2
conclusiones se presentan en la seccion 4.
Se pueden integrar datos de distinta naturaleza, de manera que es posible ejemplificar y probar hip
otesis.
Por otra parte, entre las desventajas de utilizar estos
modelos podemos mostrar las siguientes:
Son sensibles a peque
nas variaciones de las condiciones
iniciales de las reglas de transici
on.
Dependiendo de la complejidad del fen
onemo que se
quiera simular, es posible que haya que calcular un gran
n
umero de simulaciones para obtener los patrones generales de comportamiento.
II. Los modelos individuales: una breve

n
introduccio
Los modelos de naturaleza individual se fundamentan
en una tecnica de modelizacion matematica cuyo objetivo
es el estudio de diferentes tipos de fenomenos complejos
mediante la modelizacion de los mismos como sistemas
evolutivos formados por entidades individuales que interact
uan entre s de manera autonoma [10].
Esta metodologa se basa en la interaccion local de entidades individuales sobre un espacio y tiempo discretos,
de manera que se obtengan patrones de comportamiento
colectivo. As, en cada instante de tiempo toda entidad
se encuentra en un estado determinado que va cambiando
de acuerdo a una determinada regla de transici
on local.
Usualmente las variables de dicha funcion de transici
on
son los estados de otras entidades vecinas en instantes
previos de tiempo. Los principales ejemplos de modelos
individuales son los modelos basados en aut
omatas celulares [11] y los modelos basados en agentes [12].
La noci
on de automata celular (AC) fue introducida en
la decada de los 40 por J. Von Neumann y S. Ulam. Un
AC se puede definir como un tipo particular de m
aquina
de estados finitos formada por un n
umero finito de identicas unidades de memoria llamadas celulas (las entidades
individuales) que se encuentran dispuestas e interconectadas de manera homogenea. Ademas adoptan un estado
en cada instante de tiempo y van cambiandolo de manera
sincronizada de acuerdo a una misma regla de transici
on
local.
Por su parte, los modelos basados en agentes (MBA) se
desarrollaron a partir de la decada de los 90 cuando se empez
o a hacer un uso masivo de los recursos computacionales. Se trata de una generalizacion del concepto de aut
omata celular en el sentido de que los agentes (las entidades
individuales en este caso) no tienen porque encontrarse
distribuidos e interconectados de manera homogenea (es
decir, las vecindades de cada agente pueden variar con el
paso del tiempo), pudiendo variar el conjunto finito de estados que adoptan de un agente a otro. Adem
as los agentes
pueden no ser identicos y sus estados pueden ir cambiando de manera no simultanea de acuerdo a distintas reglas
de transicion local. En la actualidad, los MBA se utilizan
para simular una gran variedad de fenomenos correspondientes a distintas ramas de la Ciencia y Tecnologa: Ecologa, Finanzas y Economa, Ciencias Polticas y Sociales,
Biologa Computacional, etc.[13].
Las principales ventajas que presentan los modelos individuales son las siguientes:
Se puede modelizar de manera explcita la heterogeneidad (definicion y especificaciones) que presentan los agentes.
Se pueden simular de manera eficiente tanto el comportamiento individual como el comportamiento global del
sistema.
Se obtienen resultados graficos facilmente interpretables
por gente no experta.
n de los modelos
III. Descripcio
Los dos modelos matem
aticos propuestos en este trabajo para estudiar y simular la propagaci
on del malware son
modelos compartimentales de manera que los dispositivos
se dividen en los siguientes cuatro tipos:
(1) Dispositivos susceptibles: aquellos que no han sido infectados pero que pueden serlo en un futuro.
(2) Dispositivos infectados: aquellos que han sido infectados por el malware y que son capaces de transmitirlo. Se
dividen a su vez en:
(i) Dispositivos portadores: aquellos que han sido infectados pero no sufren da
nos ya que su sistema operativo es
distinto del atacado por el malware.
(ii) Dispositivos infecciosos: dispositivos infectados cuyo
sistema operativo es el blanco de los ataques del c
odigo
malicioso.
(3) Dispositivos recuperados: aquellos dispositivos susceptibles que han sido vacunados(dotados de las medidas
de seguridad adecuadas para que no sean infectados por el
malware), o aquellos dispositivos infectados (portadores o
infecciosos) en los que se ha detectado el malware y se ha
eliminado con exito.
En estos modelos supondremos que el proceso de limpieza al que se ven sometidos los dispositivos infectados
en los que se ha detectado el malware les dota de una inmunidad temporal; lo mismo les ocurrir
a a los dispositivos
susceptibles en los que se han instalado contramedidas.
Consecuentemente, los dispositivos recuperados vuelven
al estado de susceptibilidad al malware pasado un cierto
periodo de tiempo. Adem
as, como la velocidad de propagaci
on del malware es muy alta, podemos suponer que la
poblaci
on de dispositivos se mantiene constante a lo largo
del tiempo. Esto es:
N = S (t) + P (t) + I (t) + R (t) ,
(1)
donde N es el n
umero total de individuos de la poblacion,
y S (t) , P (t) , I (t) y R (t) son el n
umero de dispositivos
susceptibles, portadores, infectados y recuperados, respectivamente, en el instante de tiempo t.
A. El modelo global
A.1 El sistema de EDOs que rige la din
amica
Como hemos comentado anteriormente, el modelo que
desarrollaremos ser
a un modelo compartimental SPIRS
(vease la Figura 1).
JNIC2015

3
a (1 )
"*+,-.*+$")
v
!!"#$%&'($")
$%&'($")
a
#/0$##1*"*")
y eliminado con exito, b (P (t) + I (t)), y dispositivos susceptibles vacunados: vS (t) y los dispositivos que pierden
la inmunidad, R (t).
b
$$#!%$+-.*")
b
A.2 Determinaci
on de los par
ametros
Los par
ametros involucrados en las ecuaciones que gobiernan la din
amica del sistema son el coeficiente de transmisi
on a, el coeficiente de vacunaci
on v, el coeficiente de
perdida de inmunidad , la fracci
on de la poblaci
on con
el mismo sistema operativo que el atacado por el malware
, y el coeficiente de recuperaci
on b. En lo que sigue describiremos c
omo podemos determinar de manera te
orica
cada uno de esos par
ametros.
El coeficiente de transmisi
on a. La propagaci
on del
malware se produce a traves de contactos infecciosos (contactos adecuados y efectivos) entre el dispositivo susceptible y el infectado. Observese que un contacto entre dos
dispositivos es adecuado cuando el mismo puede conducir
a la transmisi
on del c
odigo malicioso; asimismo, un contacto adecuado es efectivo (y, por lo tanto, ser
a un contacto
infeccioso) cuando ha dado lugar a un contagio explcito. En la situaci
on que tratamos de simular los contactos
adecuados se realizar
an mediante el envo de informacion
a traves del correo electr
onico, y dichos contactos seran
infecciosos cuando el especimen del c
odigo malicioso vaya
adjunto en los mismos.
Se denomina coeficiente de contacto k al n
umero de contactos adecuados que tiene un dispositivo con el resto de
dispositivos en cada instante de tiempo. Usualmente el
coeficiente de contacto depende del n
umero total de dispositivos N , con lo que k = k (N ) = N , donde representa el promedio de contactos entre dos dispositivos de
la red en cada instante de tiempo. Si q es la probabilidad
de que un contacto adecuado acabe en contagio, entonces
qN representa el n
umero de contactos efectivos de cada
dispositivo con el resto de la poblaci
on en cada instante
de tiempo. Consecuentemente
Fig. 1. Diagrama de flujo representando la din

amica del modelo.
La din
amica del modelo viene regida por el siguiente
sistema de ecuaciones diferenciales ordinarias:
S 0 (t) = aS (t) (I (t) + P (t)) vS (t) + R (t) , (2)
P 0 (t) = a (1 ) S (t) (I (t) + P (t)) bP (t) , (3)
I 0 (t) = aS (t) (I (t) + P (t)) bI (t) ,
(4)
R0 (t) = b (P (t) + I (t)) + vS (t) R (t) ,
(5)
con las siguientes condiciones iniciales:
S (0) = S0 , P (0) = P0 , I (0) = I0 ,
R (0) = N S0 P0 I0 ,
S (t) 0, P (t) 0, I (t) 0, R (t) 0.
(6)
(7)
(8)
Adem
as los parametros que intervienen en el mismo son
los siguientes: el coeficiente de transmisi
on del malware a,
el coeficiente de vacunaci
on v, el coeficiente de perdida de
inmunidad , la fraccion de la poblacion con el mismo
sistema operativo que el atacado por el malware, y el coeficiente de recuperaci
on de los infectados b. Observese que
0 a, v, , , b 1.
La ecuacion (2) nos indica que la variacion del n
umero
de dispositivos susceptibles es igual a la diferencia entre
los dispositivos recuperados que han perdido la inmunidad, R (t), y los dispositivos que han dejado de ser
susceptibles. Estos u
ltimos son la suma de los dispositivos
susceptibles que se infectan en cada instante de tiempo
(que es el producto entre los dispositivos susceptibles y
los dispositivos infectados: aS (t) I (t) -incidencia-) y los
dispositivos susceptibles en los que se instalan medidas de
seguridad en cada instante de tiempo: vS (t).
La ecuacion (3) refleja que la variacion del n
umero de
dispositivos portadores es igual a la diferencia entre los
nuevos dispositivos susceptibles -con sistema operativo
distinto al atacado por el malware- que se han infectado,
a (1 ) S (t) (I (t) + P (t))), y aquellos dispositivos portadores en los que se ha detectado y eliminado el malware
(pasan a ser recuperados): bP (t).
La evolucion del n
umero de dispositivos infecciosos viene dada por la ecuacion (4) de manera que su variaci
on es
la diferencia entre los nuevos dispositivos susceptibles que
se han infectado -y que poseen el mismo sistema operativo que el atacado por el malware-, aS (t) (I (t) + P (t)),
y los dispositivos infecciosos que se han recuperado, bI (t).
La ecuacion (5) indica que la variacion del n
umero de
dispositivos recuperados es la diferencia entre los dispositivos que se recuperan (dispositivos tanto portadores como infecciosos en los que el malware ha sido detectado
a=q
N
k (N )
=q
= q .
N
N
(9)
El coeficiente de vacunaci
on v. Los dispositivos susceptibles pueden adquirir inmunidad temporal si en ellos
se instalan parches u otro tipo de programas informaticos anti-malware. En este sentido v = , donde
representar
a la fracci
on de la poblaci
on susceptible que es
vacunada en cada instante de tiempo y 0 1 sera el
coeficiente de exito que tiene la vacunaci
on.
El coeficiente de p
erdida de inmunidad . El periodo de inmunidad, TI , es el periodo de tiempo comprendido
entre el instante en el que se elimina el malware del dispositivo y el instante en el que dicho dispositivo vuelve
a ser susceptible. Un sencillo c
alculo empleando tecnicas
estadsticas nos muestra que = T1I .
El coeficiente de recuperaci
on b. Como hemos comentado anteriormente, la recuperaci
on de un dispositivo
infectado depende de dos factores: la detecci
on del c
odigo
malicioso y la eliminaci
on con exito del mismo (una vez
detectado). Entonces si d es la probabilidad de detectar el
JNIC2015

4
malware en cada instante de tiempo y e es la probabilidad

de que sea eliminado con exito, se tendra que b = d e.
El coeficiente . Habitualmente el codigo malicioso
ataca a los dispositivos cuyo sistema operativo es uno en
concreto, de manera que el resto de los dispositivos (aunque resulten infectados y puedan transmitir el malware)
no sufren da
nos. En este sentido representar
a la fracci
on del n
umero total de ordenadores de la red que posee
el mismo sistema operativo que el objeto de ataque del
gusano computacional.
dada por:
S1
I1
R1
que ser
a el punto de equilibrio endemico. Observese que
esta u
ltima soluci
on tiene sentido si b (v + ) aN < 0,
es decir, si la poblaci
on es superior a un cierto umbral:
A.3 El n
umero reproductivo basico
b (v + )
.
(14)
a
Adem
as se demuestra
que elpunto de equilibrio libre de

vN
N
, 0, 0, +v
es local y asint
oticamente
infecci
on E0 = +v
estable si y s
olo si R0 < 1, mientras que el punto de equilibrio endemico E1 = (S1 , P1 , I1 , R1 ) dado por (11)-(13)
es local y asint
oticamente estable si R0 > 1 (recuerdese
que este punto existe si = b ( + v) aN < 0).
En la Figura 2 se puede observar la evoluci
on de los
distintos tipos de ordenadores cuando a = 0,000138 ( =
1
1
1
72 , q = 0,01), v = 0,005 ( = 100 , = 0,5), = 48 ,
1
b = 0,0375 (d = 24
, e = 0,9) y = 0,6. El tiempo se mide en horas, S (0) = 100, P (0) = 1, I (0) =
1, R (0) = 0 y se simulan las primeras 150 horas a partir de la aparici
on de los primeros infectados. En este caso R0 0,304659 < 1 y consecuentemente no se producir
a epidemia. El punto de equilibrio libre de infecci
on es
N>
El n
umero reproductivo basico R0 es uno de los par
ametros de mayor importancia en el estudio de la propagaci
on
del c
odigo malicioso ya que su valor numerico indicar
a si
la presencia de un cierto especimen en una red se va a
convertir en una epidemia (el n
umero de dispositivos infectados crecera) o no. El n
umero reproductivo b
asico se
puede definir como el n
umero de dispositivos infectados directamente por un u
nico dispositivo infectado (paciente
cero) en una red de dispositivos enteramente susceptible.
Seg
un esto, si R0 > 1 el n
umero de dispositivos infectados crecera (y se producira una epidemia), mientras que
si R0 < 1 no se producira ninguna propagaci
on del c
odigo
malicioso. Si utilizamos el metodo NG (vease [14]) para calcular el n
umero reproductivo basico, obtenemos que
dicho valor viene dado por:
R0 =
aN
.
b ( + v)
b
(1 ) (b (v + ) aN )
, P1 =
(11)
a
a ( + b)
(b (v + ) aN )
=
,
(12)
a ( + b)
b (aN b + v)
=
,
(13)
a ( + b)
=
(10)
,)-./*-().+
&""
Observese que para evitar que se produzca una epidemia

sera necesario hacer el R0 tan peque
no como fuera preciso. Teniendo en cuenta su expresion explcita, ello se
puede conseguir llevando a cabo, por ejemplo, alguna de
las siguientes actuaciones: (1) Reduciendo el n
umero total de dispositivos de la red N mediante, por ejemplo, el
aislamiento; (2) Reduciendo el coeficiente de transmisi
on
a disminuyendo para ello los contactos entre los dispositivos o extremando las medidas a la hora de abrir correos
electr
onicos sospechosos u otro tipo de mensajes recibidos;
(3) Aumentando el coeficiente de recuperacion b mediante
la mejora de las prestaciones del software antivirus.
%"
!"#$%&'()*%#
+,-'./,-%#
$"
012%$$(,#,#
#"
3%$"&%-./,#
!"
'()*+
!"
#"
$"
%"
&""
&!"
&#"
Fig. 2. Evoluci
on de los distintos compartimentos cuando R0 < 1.
E0 (82,2581, 0, 0, 19,7419), de modo que en el instante

t = 150 los valores de los distintos compartimentos son
S (150) 81,7380, P (150) 0,0073, I (150) 0,0148 y
R (150) 19,2399.
En la Figura 3 se puede observar la evoluci
on de los
distintos tipos de ordenadores cuando a = 0,000208 ( =
1
1
1
48 , q = 0,01), v = 0,005 ( = 100 , = 0,5), = 48 ,
1
b = 0,03125 (d = 24
, e = 0,75) y = 0,6. Inicialmente
S (0) = 1000, P (0) = 1, I (0) = 1, R (0) = 0. Por otra parte, el tiempo se mide en horas y se simulan las primeras
200 horas a partir de la aparici
on de los primeros infectados. En este caso R0 5,3871 > 1 y consecuentemente se
producir
a epidemia. El punto de equilibrio libre de infecci
on es E1 = (150, 130,56, 195,84, 525,6). As en la anterior
simulaci
on se obtiene que el instante t = 200 los valores
de los compartimentos son S (200) 150,166, P (200)
130,524, I (200) 195,785 y R (200) 525,525.
A.4 Puntos de equilibrio del sistema

Los puntos de equilibrio del sistema (2)-(5) son las soluciones del sistema no lineal:
0 = aS (I + P ) vS + R,
0 = a (1 ) S (I + P ) bP,
0 = aS (I + P ) bI,
0 = bP + bI + vS R,
Un sencillo calculo nos muestra
que existen

dos soluciones:
N
vN
, 0, 0, +v
, que ser
a el punto
E0 = (S0 , P0 , I0 , R0 ) = +v
de equilibrio libre de infeccion, y E1 = (S1 , P1 , I1 , R1 )
JNIC2015

5
-'./0(.&'/)
decir, supondremos que hasta un cierto instante de tiempo, Tprof [i], no se habr
an implementado dichas medidas
en el dispositivo, y a partir de dicho instante de tiempo
s se instalar
an. Si 0 1 es la probabilidad de exito
que tiene la vacunaci
on, entonces se verifica que:

1, con probabilidad si t Tprof [i]
v[i, t] =
(17)
0, en otro caso
#"""
,""
!"#$%&'()*%#
+,-'./,-%#
+""
012%$$(,#,#
*""
3%$"&%-./,#
$""
%&'()
!"
#""
#!"
$""
El coeficiente de p
erdida de inmunidad [i]: nos
indica si el agente i-esimo pierde la inmunidad que le han
conferido las medidas profil
acticas o no. Depender
a del periodo de inmunidad, Tinm [i] del dispositivo. De esta manera se tendr
a que:

1, si t Tinm [i]
[i] =
(18)
0, en otro caso
Fig. 3. Evoluci
on de los distintos compartimentos cuando R0 > 1.
B. El modelo individual basado en agentes

En lo que sigue vamos a esbozar las principales caractersticas del modelo individual que se propone como contrapartida al modelo global presentado en la secci
on III.A.
En este sentido se tratara de un MBA de manera que los
agentes representar
an los distintos dispositivos que se encuentran en la red.
El coeficiente de recuperaci
on b[i, t]: al igual que en
el caso global, la recuperaci
on de un dispositivo (agente)
infectado depende de dos factores: la detecci
on del c
odigo malicioso y la eliminaci
on con exito del mismo (una
vez detectado). As supongamos que d[i, t] es la probabilidad de detectar el malware en el agente i-esimo en cada
instante de tiempo t (observese que depende del tiempo
puesto que en el influye si hay implementados metodos de
detecci
on en el dispositivo en el instante de tiempo considerado y de su eficacia); y e[i] es la probabilidad de que
sea eliminado con exito, se tendr
a que:

1, con probabilidad d[i, t] e[i]
b[i, t] =
(19)
0, con probabilidad 1 d[i, t] e[i]
B.1 Caractersticas de los agentes

Sea est[i, t] el estado del agente i-esimo en el instante
de tiempo t de manera que dicho estado podr
a ser susceptible (est[i, t] = S), portador (est[i, t] = P ), infeccioso (est[i, t] = I) o recuperado (est[i, t] = R). Se verificar
a pues que S (t) es el n
umero de dispositivos que se
encuentran en estado susceptible en el instante de tiempo
t, y as sucesivamente.
Las especificaciones individuales que caracterizan cada
agente son las siguientes:
El coeficiente de transmisi
on a[i, t]: este par
ametro
depende no solo del agente sobre el que se este calculando sino tambien del tiempo, ya que supondremos que la
topologa los contactos de un dispositivo (que se mide.en
terminos de un grafo de conexiones) se va modificando con
el tiempo. As, si vec[i, t] es la vecindad del agente i-esimo
en el instante de tiempo t, [i, j, t] representa el n
umero
de contactos efectivos entre el agente i-esimo y el agente
j-esimo durante el instante de tiempo t y q[i, j] es la probabilidad de que un contacto efectivo entre ambos agentes
acabe en contagio, entonces podemos definir la siguiente
variable booleana:
1, con probabilidad [i, j, t] q[i, j]
si j vec[i, t]
0, con probabilidad 1 [i, j, t] q[i, j]

a[i, j, t] =
si j vec[i, t]
0, 0 si j
/ vec[i, t]
(15)
Consecuentemente se verificara que:
_
a[i, t] =
a[i, j, t].
(16)
El coeficiente de sistema operativo [i]: ser

a de
naturaleza booleana de tal manera que nos indica si el
sistema operativo del agente i-esimo es el mismo que el
objeto de ataque por el malware o no. As:

1, si posee el mismo S.O. que el atacado
[i] =
0, en otro caso
(20)
El coeficiente de dispositivo [i]: al igual que el
caso anterior ser
a de naturaleza booleana de tal manera
que nos indica si el tipo de dispositivo que define al agente
i-esimo es el mismo que el atacado por el malware o no.
En nuestro caso, y para no complicar en exceso el modelo,
podemos suponer que el malware puede atacar o bien a
computadoras o bien a dispositivos m
oviles (tabletas y
telefonos inteligentes). As:
1, si el tipo de dispositivo al que pertence

el agente i es el atacado por el malware
[i] =
0, en otro caso
(21)
Observese que un factor clave en el modelo individual es
la correcta determinaci
on de los par
ametros involucrados
en el mismo. Se consideran coeficientes, periodos temporales y probabilidades particulares en cada dispositivo, los
cuales depender
an del tipo y del rol que jueguen dentro
del proceso infeccioso y de las caractersticas particulares
del malware.
jvec[i,t]
El coeficiente de vacunaci
on v[i, t]: este coeficiente
nos indica si el agente i-esimo tiene implementadas medidas profilacticas en el instante de tiempo t que le hagan
inmune a la accion del malware (y por lo tanto, que pase
a ser recuperado). Este parametro depende del tiempo, es
JNIC2015

6
B.2 Las reglas de transicion
En este sentido existen diferentes tipos de dispositivos

(computadoras, dispositivos m
oviles, dispositivos wereables, etc.) que tienen distintos usos y finalidades y diferentes especificaciones y roles en relaci
on con el malware. Consecuentemente es necesario dise
nar modelos matem
aticos que tengan en cuenta estas caractersticas.
Desafortunadamente lo anterior no es posible si seguimos considerando modelos cuya din
amica venga regida
por sistemas de ecuaciones diferenciales. Como alternativa
eficaz y eficiente podemos considerar los modelos basados
en agentes. Es una metodologa relativamente novedosa y
que ya se ha aplicado con exito a la simulacion de otro
tipo de fen
omenos.
Las simulaciones (individuales y globales) que se obtienen a partir de estos modelos son m
as realistas que las
obtenidas a partir de los modelos globales ya que tienen
en cuenta las caractersticas individuales de los diferentes
dispositivos y sus interacciones locales.
Estos modelos presentan dos desventajas fundamentales, a saber: (1) es necesario tener una eficaz monitorizaci
on del sistema para determinar de manera correcta los
distintos par
ametros que intervienen en el modelo, y (2)
tienen un coste computacional m
as elevado que el de los
modelos basados en ecuaciones diferenciales.
Las reglas de transicion entre los diferentes estados en

los que se puede encontrar un agente se pueden resumir
de la siguiente manera:
Transicion de susceptible a portador: El agente i-esimo
que es susceptible en el instante de tiempo t, pasa a ser
portador en el instante de tiempo t + 1 cuando
a[i, t] = 1 AND [i] = 0.
(22)
Transicion de susceptible a infeccioso: El agente i-esimo

que es susceptible en el instante de tiempo t, pasa a ser
infeccioso en el instante de tiempo t + 1 cuando
a[i, t] = 1 AND [i] = 1.
(23)
Transicion de susceptible a recuperado: El agente i-esimo que es susceptible en el instante de tiempo t, pasa a
ser recuperado en el instante de tiempo t + 1 cuando
a[i, t] = 0 AND v[i, t] = 1.
(24)
Transicion de portador o infeccioso a recuperado: El

agente i-esimo que es portador o infeccioso en el instante
de tiempo t, pasa a estar recuperado en el instante de
tiempo t + 1 cuando b[i, t] = 1.
Transicion de recuperado a susceptible: El agente i-esimo, recuperado en el instante de tiempo t, pasa a ser susceptible en el instante de tiempo t + 1 cuando [i] = 1.
En la Figura 4 se presenta la evolucion global de dos de
los distintos compartimentos del modelo basado en agentes: el n
umero total de susceptibles y de infectados. La
simulaci
on se realiza sobre 10,000 dispositivos y en la figura s
olo se visualizan las primeras 48 horas del proceso
infeccioso. Los valores de los parametros utilizados han sido aleatorios y similares a los de la simulacion de la Figura
3.
Agradecimientos
Este trabajo ha sido parcialmente subvencionado por
el Ministerio de Economa y Competitividad (Espa
na) y
por los fondos europeos FEDER con el proyecto TIN201455325-C2-2-R.
Referencias
[1] Y. Ding, X. Yuan, K. Tang, X. Xiao, Y. Zhang, A fast malware detection algorithm based on objective-oriented association
mining, Comput. Secur., vol. 39, pp. 315324, 2013.
[2] P. Wang, Y.-S. Wang, Malware behavioural detection and vaccine development by using a support vector model, J. Comput.
Syst. Sci., vol. 81, no. 6, pp. 1012-1026, 2015.
[3] C. C. Zou, W. Gong, D. Towsley, L. Gao, The Monitoring and
Early Detection of Internet Worms, IEEE ACM T. Network.,
vol. 13, no. 5, pp. 961-974, 2005.
[4] A. Dadlani, M.S. Kumar, K. Kim, K. Sohraby, Stability and
Immunization Analysis of a Malware Spread Model Over ScaleFree Networks, IEEE Commun. Lett., vol. 18, no. 11, pp. 19071910, 2014.
[5] S. Wen, W. Zhou, J. Zhang, Y. Xiang, W.L. Zhou, W.J. Jia, et
al, Modeling and Analysis on the Propagation Dynamics of Modern Email Malware, IEEE Trans. Dependable Secur. Comput.,
vol. 11, no. 4, pp. 361-374, 2014.
[6] C. C. Zou, W. Gong, D. Towsley, Code Red Worm Propagation
Modeling and Analysis, Proc. 9th ACM Conference on Computer and Communication Security (CCS02), p.138-147, Nov.
18-22, Washington DC, USA, 2002.
[7] S. Peng, Y. Shui, A. Yang, Smarphone Malware and Its Propagation Modeling: A survey, IEEE Commun. Surv. Tutor., vol.
16, no. 2, pp. 925-941, 2014.
[8] L.X. Yang, X. Yang, The impact of nonlinear infection rate on
the spread of computer virus, Nonlinear Dyn., 2015, to appear,
doi: 10.1007/s11071-015-2140-z
[9] Martn del Rey, A., Mathematical modeling of the propagation
of malware: a review, Secur. Commun. Netw., 2015, to appear,
doi: 10.1002/sec.1186.
[10] T.T. Allen, Introduction to Discrete Event Simulation and
Agent-based Modeling. London: Springer-Verlag, 2011.
[11] S. Wolfram, A New Kind of Science. Champaign, IL: Wolfram
Media, 2002.
[12] S.F. Railsback, V. Grimm, Agent-Based and Individual-Based
Modeling. Princeton, NJ: Princeton University Press, 2012.
./+0(+/1/2(+
-"""
,"""
%"""
#"""

!"
#"
$"
%"
&"

!"#$%&'()*%#
+,-%$'./0#
'()*+
Fig. 4.Evoluci
on global de susceptibles e infectados en el modelo
individual.
IV. Conclusiones
En este trabajo se ha puesto de manifiesto que el paradigma en el que se basan la mayor parte de los modelos
matem
aticos propuestos hasta la fecha para simular la propagaci
on de malware, debe cambiar para hacer frente al
nuevo escenario de conectividad total al que se aproxima
nuestra sociedad.
JNIC2015

7
[13] T. Terano, H. Kita, T. Kaneda, K. Arai, H. Deguchi (Eds.),

Agent-Based Simulation: From Modeling Methodologies to RealWorld Applications. Tokio: Springer-Verlag, 2005.
[14] O. Diekmann, J.A.P. Heesterbeek, and J.A.J. Metz, .On the definition and the computation of the basic reproduction ratio R0
in models for infectious diseases in heterogeneous populations,
J. Math. Biol., vol. 28, no. 4, pp. 365382, 1990.
JNIC2015

1
Sistema de Deteccion de Intrusos aplicando

Seleccion Negativa en Perfiles de Usuario
Cesar Guevara, Matilde Santos, Victoria Lopez
Facultad de Informatica, Universidad Complutesnse de Madrid
cesargue@ucm.es,msantos@ucm.es,vlopez@fdi.ucm.es
toda la informaci
on del tr
afico de la red que se genera
en el ambiente que se encuentra funcionando, es decir,
recolecta la informaci
on de red interna como informacion
de red externa (conexiones entrantes y salientes).
Resumen Esta trabajo propone un modelo de datos y

la aplicaci
on de Sistemas Inmunes Artificiales para el desarrollo e implementaci
on de un Sistema de Detecci
on de
Intrusos, que permita identificar actividades an
omalas e intrusivas dentro de un sistema de informaci
on de gobierno.
El IDS propuesto utiliza un conjuntos de datos del comportamiento de los usuarios que han ejecutado m
ultiples tareas
en un perodo considerable de tiempo dentro del sistema
real. Las contribuciones especficas son: modelo de datos,
la identificaci
on de un perfil de usuario y la aplicaci
on de algoritmos de selecci
on negativa y de b
usqueda de secuencias
de forma local como KPM para identificar tareas intrusivas
de forma eficiente. Los resultados son
optimos y con una
tasa de falsas alarmas bajo.
Con los tipos anteriores de recolecci

on de datos permiten una variedad de IDS como la detecci
on de usos indebidos (misuse detection) la cual compara la informacion
recogida con descripciones (o firmas) de ataques conocidos. Por otra parte, la detecci
on de anomalas (anomaly
detection) utiliza los datos hist
oricos sobre la ejecucion
de tareas o actividades en el sistema y detalla el comportamiento deseado de usuarios como de las aplicaciones,
para construir un perfil que representa la operaci
on normal del sistema monitorizado, e identifica patrones de actividades que se desvan del perfil definido.
Adem
as existen una variedad de tecnicas , metodologas
y algoritmos para el desarrollo de un IDS. El
area mas
utilizada para los IDS es la aplicaci
on de Inteligencia Artificial con las tecnicas de Machine Learning y Minera
de Datos (Data Mining). En esta
area se han realizado m
ultiples investigaciones y artculos, obteniendo
grandes avances de sobre la aplicaci
on distintas tecnicas
como Arboles
de Decisi
on, Redes Neuronales, Algoritmos Geneticos, Support Vector Machines, Sistemas Inmunes Artificiales entre otras [2]. Los IDS tambien utilizan tecnicas y modelos estadsticos con el prop
osito de
automatizar completamente la detecci
on de ataques maliciosos distinguiendo del uso normal de los sistemas. Las
m
as utilizadas son Redes Bayesianas, Cadenas de Markov,
etc.
En este trabajo se presenta una propuesta de investigaci
on en torno a la seguridad inform
atica, y m
as especficamente en el
area de los sistemas de detecci
on de
intrusos (IDS) basados en anomalas de comportamiento
de usuarios. El sistema propuesto utiliza la tecnica de
Sistemas Inmunes artificiales aplicando el algoritmo de
selecci
on negativa, adem
as, un algoritmo de b
usqueda
de secuencias en forma local llamado Knuth-Morris-Pratt
(KMP).
El artculo est
a organizado de la siguiente forma: en la
Secci
on 2 se detalla trabajos realizados anteriormente presentado sus fortalezas y compar
andolos con nuestra propuesta. En la Secci
on 3 se detalla el objetivo de la investigaci
on y la aportaci
on cientfica, adem
as se presenta los
materiales y metodos utilizados para la construcci
on del
IDS. Posteriormente, en la Sesi
on 4 se presentan desarrollo
del algoritmo. En las sessi
on 5 se presentan los resultados
del sistema propuesto. Finalmente, en la Secci
on 6 se pre-
Palabras Clave: Sistema inmune artificial, Sistema

de Deteccion de Intrusos, comportamiento de usuario, Selecci
on negativa
n
I. Introduccio
En la actualidad la seguridad de la informaci
on es un
rea muy importante para cualquier persona o instituci
a
on
alrededor del mundo, ya que los datos se han convertido en
el activo mas importante el cual debe ser salvaguardado
de una manera eficiente y adecuada. La gran mayora
de los datos deben mantenerse seguros de cualquier intruso o actividad no permitida, de modo que la seguridad
tiene una importancia crtica. El termino de intrusi
on
como lo presenta [1] se puede definir como cualquier conjunto de acciones que tratan de comprometer la integridad, confidencialidad o disponibilidad de un recurso. Por
ello es necesario utilizar una herramienta que pueda detectar estas actividades y mantener la informaci
on accesible solo a las personas autorizadas. Dicha herramienta
se la denomina como Sistema de Deteccion de Intrusos
(IDS), el mismo que analiza eventos que suceden en un
sistema informatico en busca de signos de intrusiones. El
principal objetivo de un IDS es monitorear la actividad
en un servidor, red o un equipo informatico (PC, Tablet,
m
ovil, etc.) de tal forma que permita identificar de manera eficiente posibles ataques o intentos de violaci
on a la
seguridad basados en patrones de comportamiento, firmas
de c
odigo o analisis de protocolos, para luego alertar al
administrador del equipo. El gran auge en el desarrollo
e implementacion de m
ultiples IDS han surgido algunas
maneras en la recoleccion y utilizacion de la informaci
on
para el sistema de deteccion, los cuales se describen continuaci
on:
Basado en el Host: Este tipo de sistema de detecci
on
utiliza la informacion de tareas o actividades realizadas
en el equipo donde se encuentra funcionando el IDS.
Basado en la Red: Este sistema de detecci
on utiliza
JNIC2015

2
sentan las conclusiones y trabajos futuros que han surgido

de esta investigacion.
de anomalas en red.
Este trabajo propone la aplicaci
on de un sistema inmune con selecci
on negativa en las tareas que ejecutan los
usuarios dentro de un sistema inform
atico, donde, a partir del hist
orico de estas ejecuciones se genera un perfil de
uso normal el cual permite identificar anomalas con resultados
optimos y con un coste computacional bajo. En
las siguientes secciones se presentar
a las aportaciones de
la propuesta y adem
as todo el proceso de modelado de la
soluci
on para un IDS.
II. Trabajos Relacionados

Un sistema de deteccion de intrusos IDS es un sistema
de software o hardware automatizado para realizar un
proceso de monitoreo y analisis de datos del medio inform
atico para la deteccion de intrusiones como lo presenta [3][4] [14]. En m
ultiples trabajos en los cuales los
IDS centran su atencion en la tecnica de Sistema inmunes artificial como una optima alternativa para identificar comportamientos anomalos los presenta en [5] [6]
[7] [8] . Los cuales validan que dicha tecnica la cual proporciona resultados fiables y que son una gran
area de
investigacion para el futuro.
Es por eso que con un creciente n
umero de investigadores informaticos que seleccionan y estudian esta
tecnica, las cuales, obtienen un gran exito como un mecanismo natural para la solucion de diversos problemas, incluyendo diagnostico de fallos, la deteccion de virus y detecci
on de fraude hipotecario como lo presenta [9] [10] [11]
[12] [13].
De los trabajos mas recientes en la aplicaci
on de sistemas inmunes artificiales es el presentado por [15], el
cual propone un algoritmo de seleccion negativa que ha
demostrado ser eficaz para los problemas de detecci
on de
anomalas y que presenta una nueva estrategia en la etapa
de entrenamiento, ademas, un continuo entrenamiento
para la reduccion de muestras self para reducir el coste
computacional en fase de pruebas. Este algoritmo puede
obtener la tasa de deteccion mas alta y una tasa m
as baja
de falsas alarmas en la mayora de los casos.
Por otro lado la investigacion realizada por [16] presenta un nuevo enfoque para la deteccion de anomalas
en el tr
afico de red utilizando detectores generados por
un algoritmo genetico. Este trabajo utiliza el algoritmo
de selecci
on negativa en un sistema inmune que puede
detectar patrones anomalos. Este trabajo, muestra una
comparativa con varios otros experimentos realizados con
un conjunto de datos conocidos llamado NSL-KDD. El algoritmo propuesto muestra resultados muy buenos en el
an
alisis, en comparacion con otros metodos de aprendizaje
autom
atico.
Otro trabajo muy interesante que en el cual se aplica el
sistemas inmunes con seleccion negativa, como lo presenta
[17]. El trabajo propuesto detalla los excelentes mecanismos de auto-aprendizaje, la capacidad de adaptaci
on del
sistema inmunologico humano y ademas muestra los conceptos y las definiciones formales de antgeno, anticuerpos
y celulas de memoria en el dominio de seguridad de la
red. Un aspecto muy importante de la investigaci
on es
como se establecen las formulaciones evoluci
on din
amica
de los perfiles de deteccion (incluida la generaci
on de los
perfiles de deteccion, de aprendizaje dinamico, transformaci
on dinamica, y la auto-organizacion din
amica), que
lograr
a que los perfiles de deteccion dinamica se puedan
sincronizar con el entorno de red real. Este trabajo obtiene
resultados experimentales buenos en la cual se convierte
en como una solucion a tener en cuenta para la detecci
on
todos y Materiales
III. Me
A. Objetivo y aportaciones de la Investigaci
on
El objetivo principal de la investigaci
on es desarrollar
un algoritmo din
amico y eficiente el cual pueda identificar
el comportamiento an
omalo de un usuario o agente que
realice tareas intrusivas en un sistema informatico. Por
otra parte las aportaciones de la investigaci
on al estudio
de IDS son:
Utilizaci
on de datos reales de usuarios de un sistema
inform
atico real para el desarrollo del modelo de datos y
el algoritmo de detecci
on.
Aplicaci
on de un nuevo modelo de datos que represente
el comportamiento de los usuario de forma eficiente.
Aplicaci
on del algoritmo de selecci
on negativa de un sistema inmune artificial al modelo de datos para la identificaci
on de comportamientos an
omalos de los usuarios.
Aplicaci
on del algoritmo KMP para la identificaci
on de
comportamientos an
omalos en nuevas secuencias de tareas.
Desarrollar una nueva forma de detecci
on de intrusos
din
amica y eficiente dirigido a sistemas inform
aticos.
En la siguiente secci
on se describen los metodos y materiales utilizados para el desarrollo del algoritmo.
B. Metodos
En esta secci
on se presentan los algoritmos aplicados
en el presente trabajo. Los algoritmos utilizados son Algoritmo de selecci
on negativa (NSA)y Algoritmo Knuth
Morris Pratt (KMP).
B.1 Sistema Inmune Artificial con Selecci
on Negativa
El algoritmo de selecci
on negativa define el self mediante la construcci
on de modelos de comportamiento normales de un sistema monitorizado. Este proceso genera
un n
umero finito de patrones aleatorios que se comparan
a cada modelo especfico de self como lo presenta [11].
B.2 Algoritmo de Knuth Morris Pratt
El objetivo principal de este problema es encontrar una
cadena dentro otra cadena. En un patr
on P para cada
posici
on i, spi(p) se dice que es la longitud del sufijo mas
largo de P[1; 2i], que coincide con el prefijo P. Es similar a navegar dentro de la cadena y que realiza sus comparaciones de izquierda a derecha. Tambien calcula los
desplazamientos m
aximos posibles de izquierda a derecha
para el patr
on P, [18].
JNIC2015

3
C. Materiales
Los datos con los que se ha realizado este trabajo fueron
proporcionados de un sistema real del gobierno de la
Rep
ublica de Ecuador. La informacion es confidencial y
por esta razon los datos se han codificado para proteger la
integridad de su informacion. El conjunto de datos se ha
recolectado mediante la captura de las tareas ejecutadas
por los usuarios en un perodo considerable de tiempo.
Estos datos constan de diez conjuntos diferentes de informaci
on sobre la ejecucion de las tareas de los usuarios.
Esta informacion esta agrupada tanto por usuarios y por
sesiones de usuario como se describe mas adelante. El conjunto de datos constan del perodo de 2011 a 2013 y son
15.571 registros de sesiones 5312 de registros de sesiones
an
omalas. La informacion que contienen todo el comportamiento normal de cada usuario de inicio de sesi
on del
sistema y las ejecuciones de tareas las cuales no tienen
un tama
no definido. El problema principal es distinguir
entre comportamiento normal y comportamiento anormal
porque las tareas ejecutadas por los usuarios depende de
la carga de trabajo, asignaciones o diferentes factores.
El sistema contiene siete tablas principales en la base
de datos (T b1 , T b2 , ..., T b7 ) y esta base de datos es posible
ejecutar las cuatro operaciones sql que son Insertar, Modificar, Eliminar y Buscar. La estructura de datos de una
sesi
on est
a conformada por un login (acceso al sistema) y
una o varias tareas ejecutadas en forma secuencial. Las
tareas estan codificadas con 28 tareas genericas m
as el
inicio de sesion. Cada tarea tiene un codigo T m
as un
n
umero para identificar cada tarea. El comportamiento de
cada usuario es dinamico y diferente de otro usuario. El
conjunto de tareas se define como T = {T1 , T2 , T3 , ..., Tm }
donde m es el n
umero de la tarea y el conjunto de posibles tareas ejecutadas por el usuario U se define como
T U = {T1 , T2 , T3 , ..., Tn } donde n es el n
umero de tareas ejecutadas. El conjunto de posibles sesiones se define
como S = {S1 , S2 , S3 , ..., Sn } donde Sn Hs. Todas
las sesiones grabadas del mismo usuario forman la base
de datos historica de ese usuario, estas sesiones se llama
Sesiones pasivas (HsU ),y una nueva sesion de usuario se
llama Sesi
on Activa AsU . Esta estructura no tiene tama
no
fijo como se muestra en la figura 1.
Para identificar las tareas ejecutadas por el usuario se
ha propuesto un modelo de datos en el cual se identifican
las tareas T mas ejecutadas y se crea una tabla que defina
si existe esa tarea en el sesion realizada S. En este trabajo
se ha comprobado que cada uno de los usuarios no realizan m
as de 13 tareas de las 28 existentes para su comportamiento normal. Por esta razon se ha tomado ese valor
como m
aximo de tareas ejecutadas para este nuevo modelo. El modelo de datos identifica si existe una o varias tareas T en una sesion S y asigna un valor de 1 al casillero
correspondiente de cada tarea y caso contrario 0 al no
existir dicha tarea. El modelo de datos esta presentado en
la tabla 1.
Si en el caso de existiese un n
umero mayor o menor de
tareas al establecido el modelo de datos es adaptable al
comportamiento de cada uno de los usuarios.
10
Fig. 1. Datos de sesiones Hist

oricas del comportamiento de usuario
en un sistema inform
atico.
T1
0
1
1
1
1
1
0
0
0
1
0
1
1
1
1
1
1
T2
0
1
1
1
1
1
0
1
1
0
1
1
0
1
1
1
1
T3
0
1
1
0
1
0
0
0
0
0
0
1
0
1
0
0
0
T4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
T5
0
1
1
1
1
1
0
0
1
0
1
1
0
1
1
1
1
T7
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
T9
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
T11
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
T12
0
0
0
0
0
0
0
0
0
0
0
1
0
1
0
0
1
T14
0
0
1
1
0
0
0
0
0
1
0
0
1
1
0
1
0
T16
0
1
1
1
1
1
1
0
0
1
1
1
0
1
1
0
0
T20
0
1
1
0
0
0
0
0
1
0
0
1
0
1
1
1
0
T21
0
1
1
1
1
1
0
1
0
1
0
1
0
1
1
1
1
TABLA I
Modelo de datos propuesto
n de
IV. Desarrollo del Algoritmo de Deteccio
Intrusos
Sobre el algoritmo de detecci
on de intrusos el cual se
basa en la nueva estructura de datos presentada anteriormente, adem
as en el algoritmo de selecci
on negativa y el
algoritmo KMP que fue descrito en los apartados anteriores. La detecci
on de tareas anormales podra resumir en
los siguientes pasos:
Paso 1. Generaci
on de secuencias anormales: En esta
secci
on utiliza el algoritmo de selecci
on negativa y KMP
para generar secuencias an
omalas utilizando el conjunto
de datos del modelo propuesto.
Paso 2. Detecci
on de Intrusos en Secuencias Activas:
Finalmente en este paso se identifica si la secuencia activa
AsU es an
omala o no utilizando el conjunto de datos resultante en el paso 1. De esta manera identificar de una
forma eficiente y din
amica si es intrusiva o normal.
A. Paso 1. Generaci
on de secuencias anormales
En este paso lo que se propone utilizar un sistema inmune artificial aplicando el algoritmo de selecci
on nega-
JNIC2015

4
tiva, el cual a partir de un conjunto de datos del modelo

propuesto genere sesiones anomalas para poder ser comparadas en el siguiente paso con una sesion activa. Este
paso consta de tres fases las cuales son:
Fase 1: Generar aleatoriamente la poblaci
on inicial B0
utilizando el modelo de datos propuesto con detectores
r que incluya los datos espaciales con las caractersticas,
donde r B0 . Estos detectores se basan en las secuencias
hist
oricas de tareas HsU , cada figura azul representa un
detector. Esta fase se ilustra en la figura 2a. En la generaci
on de la poblacion inicial n
umero de elementos B0
se calcula con la formula B0 = pv , donde p es el n
umero
de bits de posibilidades y v es la cantidad de tareas que
ejecuta el usuario, este valor permite crear un n
umero sesiones.
Fase 2: Con los datos de entrenamiento B0 una porci
on
del espacio se define como normal (itself) utilizando el
algoritmo KPM. Esta fase se ilustra en la figura 2b.El
algoritmo de b
usqueda local analiza cada registro de B0
buscando similitudes con los las sesiones del modelo de
datos de cada uno de los usuarios, si existe una similitud
los marca como normales, caso contrario los marca como
an
omalos denominados Dn .
Fase 3: Se elimina todos los detectores que se superponen con la region definida en itself, dejando el resto como
detectores anormales Dn . Esta fase se ilustra en la figura
2c.El algoritmo de seleccion negativa obtiene detectores
de comportamiento anomalo (rojo) para el siguiente paso
del sistema de deteccion, como se muestra en la Figura
2d.
Dn . Se introduce nueva sesi

on activa AsU para determinar
la similitud con los detectores Dn con el algoritmo KPM.Si
la similitud (umbral de estimulaci
on) Sth > 0 es igual a
T RU E el detector se activa y el antgeno se clasifica como
an
omalo, de lo contrario, se clasifica como normal.
Este paso es el que se repite de forma continua durante
el uso del sistema inform
atico determinando en que tarea
el usuario se desva a un comportamiento an
omalo. La
implementaci
on del IDS es en una capa intermedia entre
la interfaz del usuario y la ejecuci
on de las operaciones
en la Base de datos. Esto permite que las actividades del
usuario no queden bloqueadas sino solamente las tareas
que han sido detectadas como intrusivas, como se puede
apreciar en la figura 3.
Fig. 3.
Esquema de implementaci
on del IDS en el sistema inform
atico
En la siguiente secci
on se presentan los resultados de la
propuesta de forma detallada.
V. Resultados
Fig. 2. Fases del sistema de inmune con selecci

on negativa
En el siguiente paso se utilizan los detectores an

omalos
Dn para identificar si la sesion activa AsU es an
omala o
normal.
B. Paso 2. Detecci
on de Intrusos en Secuencias Activas
En este u
ltimo paso se analiza la secuencia activa AsU
y se compara con todo el conjunto de detectores an
omalos
11
En esta secci
on se presentan los resultados de las pruebas de detecci
on del IDS en fase incial, ya que para obtener
resultados definitivos es necesario tener pruebas m
as extensas para tener cifras definitivas. Para estas pruebas
se utiliza la informaci
on diez usuarios de un sistema inform
atico real.Durante el presente estudio se evidencio
muchas caractersticas que hacian de la propuesta tener
resultados de detecci
on eficiente, una de estas es el modelo
de datos y la aplicaci
on de selecci
on negativa del comportamiento normal de cada uno de los usuarios.
Los resultados de las pruebas de la aplicaci
on del algoritmo IDS muestran la tasa de clasificado correctamente
(CC), tasa clasificado incorrectamente (IC). Tambien presenta la detecci
on tiempo promedio (segundos) para cada
usuario del estudio. Por otro lado se presentan valores de
Verdaderos positivos (TP), Verdaderos negativos (TN),
Falsos positivos (FP), Falsos negativos (FN). Para valorar el desempe
no adecuado del IDS es necesario presentar
JNIC2015

5
valores de Precision, Tasa de Deteccion y Tasa de Falsas

alarmas las cuales se presentan a continuaci
on:
La precision (PR)se refiere a la proporci
on de datos
clasifica un tipo preciso en total de datos, a saber, la
situaci
on TP y TN, por tanto, la precision esta daba por
(T P +T N )
Precisi
on= (T P +T
N +F P +F N ) 100%.
Tasa de deteccion (DR) se refiere a la proporci
on de
comportamiento anomalo detectado entre todos los datos
de comportamiento anomalo, es decir, la situaci
on de los
TP, la tasa de deteccion es por lo tanto esta dada por
P)
Tasa de Deteccion= (T P(T+F
N ) 100%.
Tasa de falsas alarmas (FA) se refiere a la proporci
on
que los datos de comportamiento normal se detecta falsamente como un comportamiento anomalo, es decir, la
situaci
on de la FP, por lo tanto la tasa de falsas alarmas
es
P
Tasa de falsas alarmas= (F PF+T
N ) 100%.
Este analisis de deteccion de intrusos se ilustran en las
tabla 2 y 3.
Usr
1
2
3
4
5
6
7
8
9
10
CC
1943
1833
2049
2563
1909
2057
2116
2080
2218
1973
IC CC % IC % Tiempo Promedio
26
98.68
1.32
0.03
8 99.565 0.435
0.012
24 98.842 1.158
0.016
15 99.418 0.582
0.028
29 98.504 1.496
0.064
7 99.661 0.339
0.045
6 99.717 0.283
0.049
8 99.617 0.383
0.087
9 99.596 0.404
0.063
10 99.496 0.504
0.067
Media 99.3096 0.6904
0.0461
tante eficientes para pruebas iniciales con una tasa clasificado correctamente alta y podemos ver que la precisi
on de
99,31%, la tasa de detecci
on de 98,29%, y la tasa de falsas
alarmas son inferiores al 2%, lo que significa que la detecci
on tiene identificaci
on aceptable. El coste computacional es uno de el factor m
as importante a considerar,
tanto en el entrenamiento del algoritmo y en el proceso de
la detecci
on del comportamiento del usuario, como presenta la figura 4 y 5.
Fig. 4. Coste computacional en el entremamiento del IDS
TABLA II
Resultados de IDS propuesto en clasificado correctamente
(CC), clasificado incorrectamente (CC).
Usr
1
2
3
4
5
6
7
8
9
10
TP FP FN
689 25
1
468
4
4
456 13 11
549
4 11
347
2 27
393
4
3
571
1
5
504
3
5
582
2
7
674
5
5
TN
1254
1365
1593
2014
1562
1664
1545
1576
1636
1299
Media
% PR
98.68%
99.57%
98.84%
99.42%
98.50%
99.66%
99.72%
99.62%
99.60%
99.50%
99.31%
% DR
99.86%
99.15%
97.64%
98.04%
92.78%
99.24%
99.13%
99.02%
98.81%
99.26%
98.29%
% FA
1.95%
0.29%
0.81%
0.20%
0.13%
0.24%
0.06%
0.19%
0.12%
0.38%
0.44%
Fig. 5. Coste computacional en la detecci

on del IDS
TABLA III
n, Tasa
Resultados del IDS propuesto en valores de Precisio
n y Tasa de Falsas Alarmas.
de Deteccio
Dicho desempe
no del IDS en una estaci
on de trabajo es
bajo lo que es un punto a favor a la propuesta. El tiempo
promedio para detectar relativamente mnimo ya que con
solo registros de 2 a
nos facilita que la la rapidez de la
detecci
on pero no se puede obtener un perfil totalmente
eficiente. El costo del entranemiento no es un factor de
riesgo porque el entrenamiento se realiza solo una vez en
perodos semanales o mensuales lo que hace al sistema se
pueda adaptar al comportamiento del usuario.
Como se pudo apreciar los resultados obtenidos a traves

del Sistema de Deteccion de Intrusos propuesto son bas-
Este trabajo se ha propuesto y validado un sistema de

detecci
on de intrusos con un enfoque basado en la Sis-
VI. Conclusiones y Trabajos Futuros
12
JNIC2015

6
temas inmunes artificiales implementado en un sistema

inform
atico, lo que permitio que el trabajo pueda describir de una forma aproximada la creacion de perfiles de
usuario representados por el modelo de datos. La ventaja
de nuestro modelo es la generacion de comportamientos
an
omalos, aplicando seleccion negativa, a partir de comportamientos normales de cada uno de los usuarios. Esto
permite que el perfil de cada usuario sea u
nico y din
amico.
El IDS se aplico para comprobar el analisis de sensibilidad y definir el mejor rendimiento de parametros de detecci
on. Esta forma ofrece un mejor equilibrio entre la
tasa de deteccion y tasa de falsas alarmas, tambien comprueba su adaptabilidad al comportamiento humano para
la deteccion aplicando el enfoque propuesto.
Como lneas de trabajos fututos seran la implementaci
on de identificacion de comportamientos an
omalos
en secuencias temporales de las tareas ejecutadas por el
usuario aplicando reyes bayesianas u otras tecnicas de inteligencia artificial. Tambien,algoritmos de optimizaci
on
y big data para mejorar el desempeno de las detecciones
y reducir el tiempo de procesamiento y respuesta para ser
implementado de manera online y con varios sistemas a
la vez. Ademas de realizar la aplicacion a diferentes
areas
como la medicina y deteccion de problemas en sistemas
industriales.
Agradecimientos
Este trabajo ha sido parcialmente financiado por el Ministerio de Educacion Superior, Ciencia, Tecnologa e Innovaci
on (SENESCYT) del Gobierno de la Rep
ublica del
Ecuador bajo la beca Convocatoria abierta 2011 y 2012.
Referencias
[1]
Heady, Richard, et al. The architecture of a network level intrusion detection system. Department of Computer Science, College of Engineering, University of New Mexico, 1990.
[2] Scarfone, Karen, and Peter Mell. Guide to intrusion detection and prevention systems (idps). NIST special publication
800.2007 (2007): 94.
[3] Bace, Rebecca, and Peter Mell. NIST special publication on
intrusion detection systems. BOOZ-ALLEN AND HAMILTON
INC MCLEAN VA, 2001.
[4] Stavroulakis, Peter, and Mark Stamp, eds. Handbook of information and communication security. Springer Science & Business Media, 2010.
[5] Debar, Herv
e, Marc Dacier, and Andreas Wespi. Towards a
taxonomy of intrusion-detection systems. Computer Networks
31.8 (1999): 805-822.
[6] Debar, Herv
e, Marc Dacier, and Andreas Wespi. A revised taxonomy for intrusion-detection systems. Annales des telecommunications. Vol. 55. No. 7-8. Springer-Verlag, 2000.
[7] Kumar, Vipin, Jaideep Srivastava, and Aleksandar Lazarevic,
eds. Managing cyber threats: issues, approaches, and challenges. Vol. 5. Springer Science & Business Media, 2006.
[8] Murali, Adithyavairavan, and Madhav Rao. A survey on intrusion detection approaches. Information and Communication
Technologies, 2005. ICICT 2005. First International Conference
on. IEEE, 2005.
[9] DasGupta, Dipankar. An overview of artificial immune systems
and their applications. Springer Berlin Heidelberg, 1999.
[10] Kephart, Jeffrey O., et al. Biologically inspired defenses
against computer viruses. IJCAI (1). 1995.
[11] Kim, Jungwon, and Peter J. Bentley. Towards an artificial immune system for network intrusion detection: An investigation
of clonal selection with a negative selection operator. Evolutionary Computation, 2001. Proceedings of the 2001 Congress
on. Vol. 2. IEEE, 2001.
13
[12] Hofmeyr, Steven A., and Stephanie Forrest. Architecture for

an artificial immune system. Evolutionary computation 8.4
(2000): 443-473.
[13] Forrest, Stephanie, and Steven A. Hofmeyr. Immunology
as information processing. SANTA FE INSTITUTE STUDIES IN THE SCIENCES OF COMPLEXITY-PROCEEDINGS
VOLUME-. Reading, Mass.; Addison-Wesley; 1998, 2001.
[14] Garcia-Teodoro, Pedro, et al. Anomaly-based network intrusion detection: Techniques, systems and challenges. computers
& security 28.1 (2009): 18-28.
[15] Gong, Maoguo, et al. An efficient negative selection algorithm
with further training for anomaly detection. Knowledge-Based
Systems 30 (2012): 185-191.
[16] Aziz, Amira Sayed A., et al. Detectors generation using genetic
algorithm for a negative selection inspired anomaly network
intrusion detection system. Computer Science and Information
Systems (FedCSIS), 2012 Federated Conference on. IEEE, 2012.
[17] Peng, Lingxi, et al. Dynamically real-time anomaly detection
algorithm with immune negative selection. Applied Mathematics & Information Sciences 7.3 (2013): 1157-1163.
[18] Mandumula, Kranthi Kumar. Knuth-Morris-Pratt Algorithm. Posledn zmena 18 (2011).
JNIC2015
The Attack of the Clones: A Study of the Impact of

Shared Code on Vulnerability Patching
Antonio Nappa , Richard Johnson , Leyla Bilge , Juan Caballero , Tudor Dumitras,
IMDEA
Software Institute
Research Labs
Symantec
University
of Maryland, College Park

Politecnica de Madrid
Universidad
antonio.nappa@imdea.org, rbjohns8@cs.umd.edu,
leylya yumer@symantec.com, juan.caballero@imdea.org, tdumitra@umiacs.umd.edu
The full version of this paper appears at the proceeedings at 36th IEEE Symposium on Security and Privacy
AbstractVulnerabilities in client applications (e.g., browsers,
multimedia players, document readers and editors) are often exploited in spear phishing attacks and are difficult to characterize
using network vulnerability scanners. Analyzing their lifecycle
is challenging because it requires observing the deployment
of patches on hosts around the world. Using data collected
over 5 years on 8.4 million hosts, available through Symantecs
WINE platform, we present the first systematic study of patch
deployment in client-side vulnerabilities.
We analyze the patch deployment process of 1,593 vulnerabilities from 10 popular client applications, and we identify
several new threats presented by multiple installations of the
same program and by shared libraries distributed with several
applications. We find that the median fraction of vulnerable
hosts patched when exploits are released is at most 14%. While
patching starts within 7 days before or after disclosure for 77% of
the vulnerabilities, the median time to patch half of the vulnerable
hosts is 45 days. For the 80 vulnerabilities in our dataset that
affect code shared by two applications, the time between patch
releases in the different applications is up to 118 days (with
a median of 11 days). We demonstrate two novel attacks that
enable exploitation by invoking old versions of applications that
are used infrequently, but remain installed. Finally, we show that
the patching rate is affected by user-specific and applicationspecific factors; for example, hosts belonging to security analysts
and applications with an automated updating mechanism have
significantly lower median times to patch.
I. E XTENDED A BSTRACT
In recent years, considerable efforts have been devoted
to reducing the impact of software vulnerabilities, including
efforts to speed up the creation of patches in response to
vulnerability disclosures [1]. However, vulnerability exploits
remain an important vector for malware delivery [2], [3]. Prior
measurements of patch deployment [4][7] have focused on
server-side vulnerabilities. Thus, the lifecycle of vulnerabilities in client-side applications, such as browsers, document
editors and readers, or media players, is not well understood.
Such client-side vulnerabilities represent an important security
threat, as they are widespread (e.g., typical Windows users are
exposed to 297 vulnerabilities in a year [8]), and they are often
exploited using spear-phishing as part of targeted attacks [9]
[11].
14
One dangerous peculiarity of client-side applications is that

the same host may be affected by several instances of the same
vulnerability. This can happen if the host has installed multiple
instances of the same application, e.g., the default installation
and an older version bundled with a separate application. Multiple instances of the vulnerable code can also occur owing to
libraries that are shared among multiple applications (e.g., the
Adobe library for playing Flash content, which is included with
Adobe Reader and Adobe Air installations). These situations
break the linear model for the vulnerability lifecycle [1], [3],
[12], [13], which assumes that the vulnerability is disclosed
publicly, then a patch released, and then vulnerable hosts get
updated. In particular, vulnerable hosts may only patch one of
the program installations and remain vulnerable, while patched
hosts may later re-join the vulnerable population if an old
version or a new application with the old code is installed. This
extends the window of opportunity for attackers who seek to
exploit vulnerable hosts. Moreover, the owners of those hosts
typically believe they have already patched the vulnerability.
To the best of our knowledge, we present the first systematic study of patch deployment for client-side vulnerabilities.
The empirical insights from this study allow us to identify several new threats presented by multiple installations and shared
code for patch deployment and to quantify their magnitude.
We analyze the patching by 8.4 million hosts of 1,593 vulnerabilities in 10 popular Windows client applications: 4 browsers
(Chrome, Firefox, Opera, Safari), 2 multimedia players (Adobe
Flash Player, Quicktime), an email client (Thunderbird), a
document reader (Adobe Reader), a document editor (Word),
and a network analysis tool (Wireshark).
Our analysis combines telemetry collected by Symantecs
security products, running on end-hosts around the world, and
data available in several public repositories. Specifically, we
analyze data spanning a period of 5 years available through the
Worldwide Intelligence Network Environment (WINE) [14].
This data includes information about binary executables downloaded by users who opt in for Symantecs data sharing
program. This dataset provides a unique opportunity for studying the patching process in client applications, which are
difficult to characterize using the network scanning techniques
employed by prior research [4][7], [15].
JNIC2015
manually. However, only 28% of the patches in our study reach

95% of the vulnerable hosts during our observation period.
This suggests that there are additional factors that influence
the patch deployment process. In particular, users have an
important impact on the patch deployment process, as security
analysts and software developers deploy patches faster than the
general user population. Most of the vulnerable hosts remain
exposed when exploits are released in the wild. Our findings
will enable system administrators and security analysts to
assess the the risks associated with vulnerabilities by taking
into account the milestones in the vulnerability lifetime, such
as the patching delay and the median time-to-patch.
The analysis is challenging because each software vendor

has its own software management policies, e.g., for assigning
program versions, using program lines, and issuing security
advisories, and also by the imperfect information available
in public vulnerability databases. To address these challenges
we have developed a generic approach to map files in a host
to vulnerable and non-vulnerable program versions, using file
meta-data from WINE and VirusTotal [16], and the NVD [17]
and OSVDB [18] public vulnerability databases. Then, we
aggregate vulnerabilities in those databases into clusters that
are patched by the same program version. Finally, using a
statistical technique called survival analysis [19], we track
the global decay of the vulnerable host population for each
vulnerability cluster, as software updates are deployed.
Using this approach we can estimate for each vulnerability
cluster the delay to issue a patch, the rate of patching, and
the vulnerable population in WINE. Using exploit meta-data
in WINE and the Exploit Database [20], we estimate the
dates when exploits become available and we determine the
percentage of the host population that remains vulnerable upon
exploit releases.
We quantify the race between exploit creators and the
patch deployment, and we find that the median fraction of
hosts patched when exploits are released is at most 14%.
All but one of the exploits detected in the wild found more
than 50% of the host population still vulnerable. The start
of patching is strongly correlated with the disclosure date,
and it occurs within 7 days before or after the disclosure
for 77% of the vulnerabilities in our studysuggesting that
vendors react promptly to the vulnerability disclosures. The
rate of patching is generally high at first: the median time
to patch half of the vulnerable hosts is 45 days. We also
observe important differences in the patching rate of different
applications: none of the applications except for Chrome
(which employs automated updates for all the versions we
consider) are able to patch 90% of the vulnerable population
for more than 90% of vulnerability clusters.
Additionally, we find that 80 vulnerabilities in our dataset
affect common code shared by two applications. In these cases,
the time between patch releases in the different applications
is up to 118 days (with a median of 11 days), facilitating
the use of patch-based exploit generation techniques [21].
We demonstrate two novel attacks that enable exploitation by
invoking old version of applications that are used infrequently,
but that remain installed.
R EFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
II. C ONCLUSION
We investigate the patch deployment process for 1,593
vulnerabilities from 10 client-side applications. We analyze
field data collected on 8.4 million hosts over an observation
period of 5 years, made available through the WINE platform
from Symantec. We show two attacks made possible by the fact
that multiple versions of the same program may be installed
on the system or that the same library may be distributed
with different software. We find that the median fraction of
vulnerable hosts patched when exploits are released is at most
14%. For most vulnerabilities, patching starts around the disclosure date, but the patch mechanism has an important impact
on the rate of patch deployment. For example, applications
updated automatically have a median time-to-patch 1.5 times
lower than applications that require the user to apply patches
[15]
[16]
[17]
[18]
[19]
[20]
[21]
15
S. Frei, Security Econometrics: The Dynamics of (In)Security. PhD

thesis, ETH Zurich, 2009.
C. Grier et al., Manufacturing compromise: the emergence of exploitas-a-service, in ACM Conference on Computer and Communications
Security, (Raleigh, NC), Oct 2012.
L. Bilge and T. Dumitras, Before we knew it: an empirical study of
zero-day attacks in the real world, in ACM Conference on Computer
and Communications Security, pp. 833844, ACM, 2012.
D. Moore, C. Shannon, and K. C. Claffy, Code-red: a case study on
the spread and victims of an internet worm, in Internet Measurement
Workshop, pp. 273284, ACM, 2002.
E. Rescorla, Security holes... who cares, in Proceedings of the 12th
USENIX Security Symposium, pp. 7590, 2003.
T. Ramos, The laws of vulnerabilities, in RSA Conference, 2006.
Z. Durumeric, J. Kasten, D. Adrian, J. A. Halderman, M. Bailey,
F. Li, N. Weaver, J. Amann, J. Beekman, M. Payer, and V. Paxson,
The matter of Heartbleed, in Internet Measurement Conference,
(Vancouver, Canada), Nov 2014.
S. Frei and T. Kristensen, The security exposure of software portfolios, in RSA Conference, March 2010.
W. R. Marczak, J. Scott-Railton, M. Marquis-Boire, and V. Paxson,
When governments hack opponents: A look at actors and technology,
in USENIX Security Symposium, 2014.
S. Hardy, M. Crete-Nishihata, K. Kleemola, A. Senft, B. Sonne,
G. Wiseman, P. Gill, and R. J. Deibert, Targeted threat index: Characterizing and quantifying politically-motivated targeted malware, in
USENIX Security Symposium, 2014.
S. L. Blond, A. Uritesc, C. Gilbert, Z. L. Chua, P. Saxena, and E. Kirda,
A Look at Targeted Attacks through the Lense of an NGO, in USENIX
Security Symposium, August 2014.
W. A. Arbaugh, W. L. Fithen, and J. McHugh, Windows of vulnerability: A case study analysis, IEEE Computer, vol. 33, December 2000.
H. Okhravi and D. Nicol, Evaluation of patch management strategies,
International Journal of Computational Intelligence: Theory and Practice, vol. 3, no. 2, pp. 109117, 2008.
T. Dumitras and D. Shou, Toward a standard benchmark for computer
security research: The Worldwide Intelligence Network Environment
(WINE), in EuroSys BADGERS Workshop, (Salzburg, Austria), Apr
2011.
S. Yilek, E. Rescorla, H. Shacham, B. Enright, and S. Savage, When
private keys are public: results from the 2008 debian openssl vulnerability, in Internet Measurement Conference, pp. 1527, ACM, 2009.
Virustotal. http://www.virustotal.com/.
U.s. national vulnerability database. http://nvd.nist.gov/.
Osvdb: Open sourced vulnerability database. http://osvdb.org/.
D. G. Kleinbaum and M. Klein, Survival Analysis: A Self-Learning Text.
Springer, third ed., 2011.
Exploit database. http://exploit-db.com/.
D. Brumley, P. Poosankam, D. X. Song, and J. Zheng, Automatic patchbased exploit generation is possible: Techniques and implications, in
IEEE Symposium on Security and Privacy, (Oakland, CA), pp. 143157,
May 2008.
JNIC2015
Experiences on NFC Relay Attacks with Android:

Virtual Pickpocketing Revisited
Jose Vila
Ricardo J. Rodrguez
Department of Computer Science and Systems Engineering

University of Zaragoza, Spain
594190@unizar.es
Research Institute of Applied Sciences in Cybersecurity

University of Leon, Spain
rj.rodriguez@unileon.es
Paper accepted in the 11th International Workshop on RFID Security (RFIDsec), 2015. A live
demo was performed relaying a payment transaction from New York to Madrid in real-time.
AbstractNear Field Communication (NFC) is a short-range
contactless communication standard recently emerging as cashless payment technology. However, NFC has been proved vulnerable to several threats, such as eavesdropping, data modification,
and relay attacks. A relay attack forwards the entire wireless
communication, thus communicating over larger distances. In
this paper, we review and discuss feasibility limitations when performing these attacks in Googles Android OS. We also perform
an in-depth review of the Android implementation of the NFC
stack. We show an experiment proving its feasibility using off-theshelf NFC-enabled Android devices (i.e., no custom firmware nor
root required). Thus, Android NFC-capable malicious software
might appear before long to virtually pickpocket contactless
payment cards within its proximity.
I. I NTRODUCTION
Near Field Communication (NFC) is a bidirectional shortrange (up to 10 cm) contactless communication technology
based on the ISO-14443 [1] and the Sony FeLiCa [2] Radio
Frequency Identification (RFID) standards. It operates in the
13.56 MHz spectrum and supports data transfer rates of 106,
216, and 424 kbps.
NFC defines three operation modes: peer-to-peer,
read/write, and card-emulation mode. In peer-to-peer mode,
two NFC devices communicate directly with each other.
This mode is commonly used to exchange business cards,
or credentials for establishing a network link. Read/write
mode allows an NFC device to communicate with an NFC
tag. Finally, card-emulation mode enables an NFC device
to behave as a contactless smartcard, thus allowing to
communicate with an NFC reader/writer.
Nowadays, NFC technology is widely used in a disparity
of applications, from ticketing, staff identification, or physical
access control, to cashless payment. In fact, the contactless
payment sector seems the one where NFC has generated more
interest, accordingly to market studies [3], [4]. As Fischer
envisioned in 2009 [5], the confluence of NFC with smart
phones can be the reason behind this fact since NFC is a way
to bring cards to the mobile [6].
To date, almost 300 different smart phones are (or will be
soon) available at the market [7]. Most of them are based on
Googles Android OS (or Android for short), while other OS
such as Apples iOS, BlackBerry OS, or Windows Phone OS
are less representative. For instance, Apple has just started to
add NFC capabilities into its devices: Apples iPhone 6 is the

first model integrated with an NFC chip, although is locked to
work only with Apples contactless payment system [8]. As a
recent market research states [9], this trend will keep growing
up, expecting to reach more than 500 million of NFC payment
users by 2019.
Unfortunately, NFC is insecure as claimed by several
works [10][13], where NFC security threats and solutions
have been stated. Potential threats of NFC are eavesdropping,
data modification (i.e., alteration, insertion, or destruction),
and relay attacks. Eavesdropping can be avoided by secure
communication, while data modification may require advanced
skills and enough knowledge about RF transmission, as well as
ad-hoc hardware to perform the attack. A relay attack, defined
as a forwarding of the entire wireless communication, allows
to communicate over a large distance. A passive relay attack
forwards the data unaltered, unlike an active relay attack [14].
In this paper, we focus on passive relay attacks.
Relay attacks were thought to be difficult from a practical
perspective, mainly due to the physical constraints on the communication channel and the specialized hardware (or software)
needed. However, the eruption of NFC-enabled mobile phones
(or devices) completely changes the threat landscape: most
NFC communication can be relayed even NFC payment
transactions with NFC-enabled devices.
Mobile malicious software (i.e., malware) usually target user
data (such as user credentials or mobile device information),
or perform fraud through premium-rate calls or SMS, but
we believe that the rise of NFC-enabled devices put NFC
in the spotlight for malware developers [15]. To the best
of our knowledge, to date there not exist any malware with
NFC capabilities although they might appear before long. To
prove if an NFC-capable malware might exist nowadays, in
this paper we study the feasibility of passive relay attacks in
Android. Android is used since it leads the global smartphone
market [16] and provides a broad set of freely resources for
the developers.
The contribution of this paper is threefold: first, we provide
an in-depth review of Android implementation of the NFC
stack; second, we discuss the implementation alternatives
to perform NFC relay attacks in Android; and third, we
show a practical implementation of these attacks using two
16
JNIC2015
In brief, wide-scale botnet of Android devices running malicious applications continuously seeking contactless payment
cards can lead to several problematic situations. For instance,
consider a malware that once it detects a card within its
proximity, it iteratively communicates with it sending incorrect
PIN until it blocks. Similarly, instead of blocking the card the
malware can try to guess the cardholders PIN using a similar
technique as [17], which may lead to a very large scale fraud.
(a) Scenario 1: Distributed mafia fraud
ACKNOWLEDGMENTS
This work was partially supported by the University of Leon
under contract X43.
R EFERENCES
(b) Scenario 2: Hiding fraud locations

Figure 1. Threat scenarios of NFC passive relay attacks by Android malware.
NFC-enabled mobile phones running an off-the-shelf (OTS)

Android (i.e., no custom firmware nor root permissions). Our
findings put in evidence that these scenarios are nowadays
feasible, requiring permission only of NFC and relay communication link chosen (e.g., Bluetooth, WiFi, or GPRS). This
issue clearly supposes a high security risk: An NFC-capable
malware installed on an Android device can interact with
any contactless payment cards in its proximity, being able to
conduct illegal transactions. Current limitations and feasibility
of some malware attack scenarios are also introduced.
II. T HREAT S CENARIOS
Fig. 1 depicts a pair of threat scenarios. In Fig. 1(a), we
envisioned a network of Android infected devices (i.e., a
botnet) that communicate with the bot master when a contactless payment card is detected. The bot master can use this
smartcard to conduct illegal transactions with a honest verifier,
or even multiple transactions at the same time collaborating
with multiple dishonest verifiers. We named this attack as
distributed mafia fraud. Fig. 1(b) foresees the same scenario
than before, but with multiple dishonest provers committing
fraud at the same time, as a way to hide their real location.
Note that contactless payment cards implement security
mechanisms such as PIN after consecutive uses or checking
of atypical payment locations. These mechanisms clearly
minimise the impact of the second threat scenario envisioned.
Lastly, let us remark a limitation of these attacks performed
as an Android malware. Since read/write operation mode
in Android is only reachable by activities, an NFC-capable
Android malware detecting a smartcard in its proximity range
starts execution in foreground. That is, when the infected device is screen-locked, the malware cannot begin its execution
until screen is unlocked. However, note that a malware with
root permissions or behaving as a fake app can bypass this
limitation.
[1] International Organization for Standardization, ISO/IEC 18092:2013:

Information technology Telecommunications and information exchange between systems Near Field Communication Interface and
Protocol (NFCIP-1), Geneva, Switzerland, March 2013.
[2] Japanese Industrial Standard, JIS X 6319-4:2010: Specification
of implementation for integrated circuit(s) cards Part
4: High speed proximity cards, October 2010. [Online].
Available: http://www.webstore.jsa.or.jp/webstore/PrevPdfServlet?dc=
JIS&fn=pre jis x 06319 004 000 2010 e ed10 i4.pdf
[3] C. Oak, The year 2014 was a tipping point for NFC payments,
[Online], http://www.finextra.com/blogs/fullblog.aspx?blogid=10382.
[4] C. de Looper, Mobile Payment Boasts Rosy Future, But
Some Obstacles Remain in Play, [Online], January 2015,
http://www.techtimes.com/articles/24762/20150106/mobile-paymentsworth-130-billion-2020.htm.
[5] J. Fischer, NFC in Cell Phones: The New Paradigm for an Interactive
World, IEEE Commun. Mag., vol. 47, no. 6, pp. 2228, June 2009.
[6] A. Boysen, NFC is the bridge from cards to the mobile, [Online], January 2015, http://www.secureidnews.com/news-item/nfc-is-thebridge-from-cards-to-the-mobile/.
[7] NFC World, NFC phones: The definitive list, [Online], January 2015,
http://www.nfcworld.com/nfc-phones-list/.
[8] M. Reardon and S. Tibken, Apple takes NFC mainstream on
iPhone 6; Apple Watch with Apple Pay, [Online], September 2014,
http://www.cnet.com/news/apple-adds-nfc-to-iphone-6-with-apple-pay/.
[9] Juniper Research Limited, Apple Pay and HCE to Push NFC Payment
Users to More Than 500 Million by 2019, [Online], October 2014,
http://www.juniperresearch.com/viewpressrelease.php?pr=483.
[10] E. Haselsteiner and K. Breitfu, Security in Near Field Communication
(NFC) Strengths and Weaknesses, in Proceedings of the Workshop
on RFID Security and Privacy, 2006, pp. 111.
[11] G. Madlmayr, J. Langer, C. Kantner, and J. Scharinger, NFC Devices:
Security and Privacy, in Proceedings of the 3rd International Conference on Availability, Reliability and Security (ARES), 2008, pp. 642647.
[12] S. Timalsina, R. Bhusal, and S. Moh, NFC and Its Application to
Mobile Payment: Overview and Comparison, in Proceedings of the 8th
International Conference on Information Science and Digital Content
Technology, vol. 1, 2012, pp. 203206.
[13] G. V. Damme and K. Wouters, Practical Experiences with NFC Security
on mobile Phones, in Proceedings of the 2009 International Workshop
on RFID: Security and Privacy Issues, 2009, pp. 113.
[14] G. Hancke, K. Mayes, and K. Markantonakis, Confidence in smart
token proximity: Relay attacks revisited, Computers & Security, vol. 28,
no. 7, pp. 615627, 2009.
[15] A. P. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner, A Survey of
Mobile Malware in the Wild, in Proceedings of the 1st ACM Workshop
on Security and Privacy in Smartphones and Mobile Devices. ACM,
2011, pp. 314.
[16] International Data Corporation, Smartphone OS Market Share, Q3
2014, [Online], 2014, http://www.idc.com/prodserv/smartphone-osmarket-share.jsp.
[17] M. Emms, B. Arief, N. Little, and A. van Moorsel, Risks of Offline
Verify PIN on Contactless Cards, in Financial Cryptography and Data
Security, ser. LNCS, vol. 7859. Springer Berlin Heidelberg, 2013, pp.
313321.
17
JNIC2015

1
C ARONTE:
Detecting Location Leaks for

Deanonymizing Tor Hidden Services
Srdjan Matic, Platon Kotzias, and Juan Caballero
Universita degli Studi di Milano, srdjan.matic@unimi.it
IMDEA Software Institute, {platon.kotzias,juan.caballero}@imdea.org
The full version of this paper will appear in the Proceedings of the 2015 ACM SIGSAC Conference on
Computer and Communications Security.
Abstract
Anonymity networks as Tor are a critical privacy-enabling technology.
Tors hidden services provide both client and server anonymity. This paper presents C ARONTE, a tool to automatically identify location leaks in
hidden services, i.e., sensitive information served by the hidden service
that discloses the servers IP address. C ARONTE implements a novel approach that does not rely on flaws on the Tor protocol and assumes an
open-world, i.e., it does not require a list of candidate servers known in
advance. We apply C ARONTE to 1,974 hidden services, fully recovering
the IP address of 101 (5%) of them.
I. E XTENDED ABSTRACT
A. Motivation
The increasing surveillance of communications have made
anonymity networks a critical privacy-enabling technology.
Tor [1] is arguably the most popular anonymity network. It provides both sender anonymity and recipient anonymity for hidden services. Hidden services protect the location (i.e., IP address) of the server hosting the hidden service. In addition, they
further protect against network-level eavesdropping by providing encryption all the way from the client to the hidden service.
This includes the communication between the last Tor relay and
the hidden service, even when the application traffic is not encrypted.
Hidden services are used among others for storing whistleblowing documents that corporations or governments may
want to censor and for hosting political dissident blogs. They
are also abused for running malware command-and-control
servers [24] and for hosting black markets selling any kind
of goods including drugs and guns. Thus, censors and lawenforcement agencies have great interest in deanonymizing
hidden services, i.e., finding the hidden servers IP address.
Once the IP address is revealed, the hidden service can be taken
down, its content seized, and their owners identified and possibly arrested.
There have been some notorious takedowns of hidden services by law enforcement. In July 2013, law enforcement identified the location of the Silk Road marketplace, where products such as cocaine, heroin, LSD, and counterfeit currencies
were traded [5]. The service was taken down, its records captured, $25 million in Bitcoin seized (and later auctioned), and
the sites administrator and at least a dozen of the top sellers arrested [6]. After the Silk Road takedown other similar hidden
services took its place. In November 2014, an international
law-enforcement operation codenamed Onymous, took down
over 400 hidden services including the Silk Road 2.0, Cloud
9, and Hydra drug markets. The operation lead to the arrest

of at 17 people and the confiscation of $1 million in Bitcoin
and $250,000 in cash, gold, silver, and drugs [7]. In both takedowns the deanonymization method used by law enforcement
to locate the hidden services remains unknown [8, 9].
B. Related Work
Prior work has proposed attacks to deanonymize Tor hidden services through flaws on the Tor protocol [10, 11] and
clock-skew fingerprinting [12, 13]. Attacks on the Tor protocol are promptly fixed by the Tor project. For example, the
attack by verlier and Syverson [10] was fixed by introducing
guard nodes and the more recent attack by Biryukov et al. [11]
has also been fixed [14]. Attacks leveraging clock-skew fingerprinting assume a closed-world where a short list of possible candidate servers is known and the fingerprinting validates which candidate is the hidden server. Deanonymization
attacks have also been proposed for the equivalent of hidden
services in I2P (called eepSites) [15]. These attacks also assume a closed-world, where the IP addresses of I2P peers are
candidate servers for eepSites.
C. Contributions
This paper studies the problem of location leaks, i.e., information in the content or configuration of a hidden service
that gives away its location. Location leaks are introduced by
the hidden service administrators and cannot be centrally fixed
by the Tor project. Deanonymizing hidden services through
location leaks does not require the attacker to be part of the
anonymity network, but only to access the hidden services.
Such leaks are a well-known problem for hidden services,
but their extent is currently unknown. They are also likely candidates for the above takedowns. For example, the FBI claimed
in court that they located the server of the original Silk Road
through a leak of its IP address when visiting the site [16]. The
FBI story has been disputed [16, 17], but researchers still believe it is likely that the takedown was due to a leak in the
servers configuration [16]. Furthermore, while several drug
markets were taken down in operation Onymous, other leading hidden service drug markets (e.g., Agora, Evolution, Andromeda) as well as child pornography and financial fraud sites
were unaffected. This points to the problem being site-specific
rather than a Tor protocol compromise.
In this paper we propose a novel approach to deanonymize
hidden services using a subset of location leaks in an open-
18
JNIC2015

2
world, i.e., without previous knowledge of a set of candidate

servers. Our approach includes two steps. First, we propose techniques to extract candidate Internet endpoints (i.e.,
domains and IP addresses that may correspond to the hidden
server) from the content and configuration of a hidden service.
Our techniques examine endpoints and unique identifiers in the
content and the HTTPS certificates. This step allows moving
from an open-world to a closed-world. Then we validate each
candidate pair hhidden service, Internet endpointi, checking if the Internet endpoint corresponds to the Web server hosting the hidden service. Previous work that leverages leaks on
a servers clock skew [12, 13] or software version [15] assume
a closed-world and use the leaks only for validation. In contrast, our approach leverages location leaks to obtain also the
candidate servers.
We implement our approach in a tool called C ARONTE,
which takes as input the URL of a hidden service and tries
to deanonymize it through location leaks. C ARONTE can be
used by hidden service administrators to check their site for
a subset of content and configuration errors that can lead to
deanonymization. If it manages to recover the hidden services
IP address, it provides proof of the need to improve operational
security. However, it only tests for a subset of potential leaks
for which we can automate validation. Thus, it cannot guarantee the hidden service is free of location leaks.
content and configuration. C ARONTE implements a novel approach to deanonymize hidden services that does not rely on
flaws on the Tor protocol and assumes an open-world, i.e., it
does not assume a short list of candidate servers is known in advance. Instead, it implements novel techniques to identify candidate servers from the content and configuration of a hidden
service, which enable moving from an open-world to a closedworld.
Using C ARONTE we perform the first measurement study
on the prevalence of location leaks in hidden services. Out
of 1,974 live HTTP hidden services, C ARONTE successfully deanonymizes the location of 5% of them. Of the
deanonymized hidden services 21% are running on Tor relays.
The remaining 79% could not be deanonymzed in a closeworld.
D. Evaluation
[5]
To test C ARONTEs effectiveness we have applied it to 1,974

live HTTP and HTTPS hidden services, of which C ARONTE
recovers the IP address of 101 (5%). Our results can be considered the first measurement study of location leaks in Tor
hidden services. Since C ARONTE is designed to look only
for a small subset of location leaks and can only verify the
leaks in some server configurations, its results are conservative, i.e., some services not deanonymized could still be vulnerable. We cross-reference the hidden services C ARONTE
deanonymizes with the list of hidden services deanonymized
in operation Onymous [18]. We find 2 onion addresses in
common and another 5 hidden services that when C ARONTE
deanonymized them they were hosted on a different onion address. While we do not know if law enforcement used location
leaks to deanonymize those hidden services, we do know that
some of the deanonymized sites did not have strong operational
security. Those sites could have used C ARONTE to get an early
warning of their problems.
Our results also show that 21% of the deanonymized services are hosted on Tor relays. Hidden services on Tor relays
can easily be deanonymized, even in the absence of location
leaks, assuming a closed-world where relays IP addresses are
candidate locations for a hidden service. It also shows the importance of assuming an open-world, as 79% of hidden services C ARONTE deanonymizes cannot be deanonymized under
the closed-world assumption. C ARONTE also identifies 9 hidden services that redirect their users to Internet sites through
HTTP, negating the benefit of encryption in the last hop.
E. Conclusion
B IBLIOGRAPHY
[1]
[2]
[3]
[4]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
In this paper we have presented C ARONTE, a tool to

deanonymize hidden services through location leaks in their
19
1 Roger Dingledine and Nick Mathewson and Paul Syverson, Tor: The
Second-generation Onion Router, Proceedings of the 13th USENIX Security Symposium, 2004.
N. Hopper, Short Paper: Challenges in Protecting Tor Hidden Services
from Botnet Abuse, Proceedings of the 18thInternational Conference on
Financial Cryptography and Data Security, 2014.
Kaffeine, Guess who is back again, Cryptowall, http:
//malware.dontneedcoffee.com/2015/01/guess-whosback-again-cryptowall-30.html, January 2015.
D. H. Lipman, Mailing list post: [tor-talk] vwfws4obovm2cydl.onion?,
https://lists.torproject.org/pipermail/tortalk/2012-June/024565.html, June 2012.
Nicolas Christin, Traveling the Silk Road: A measurement analysis of a
large anonymous online marketplace, Proceedings of the 22nd international conference on World Wide Web, pp. 213224, 2013.
Kim Zetter, Wired: How the Feds Took Down the Silk Road
Drug Wonderland, http://www.wired.com/2013/11/silkroad/, November 2013.
Andy Greenberg, Wired: Global Web Crackdown Arrests 17, Seizes
Hundreds Of Dark Net Domains, http://www.wired.com/
2014/11/operation-onymous-dark-web-arrests/,
November 2014.
Tor Project, Tor and the Silk Road takedown, https://blog.
torproject.org/blog/tor-and-silk-road-takedown,
October 2013.
Tor Project, Thoughts and Concerns about Operation Onymous,
https://blog.torproject.org/blog/thoughts-andconcerns-about-operation-onymous, November 2014.
Lasse verlier and Paul Syverson, Locating Hidden Servers, Proceedings of the IEEE Symposium on Security and Privacy, 2006.
Alex Biryukov and Ivan Pustogarov and Ralf-Philipp Weinmann, Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization, Proceedings of the IEEE Symposium on Security and Privacy,
2013.
Steven J. Murdoch, Hot or Not: Revealing Hidden Services by Their
Clock Skew, Proceedings of the 13th ACM Conference on Computer
and Communications Security, 2006.
Sebastian Zander and Steven J. Murdoch, An Improved Clock-skew
Measurement Technique for Revealing Hidden Services, Proceedings
of the 17th USENIX Security Symposium, 2008.
Alex Biryukov and Ivan Pustogarov and Fabrice Thill and Ralf-Philipp
Weinmann, Content and Popularity Analysis of Tor Hidden Services,
Proceedings of the First International Workshop on Big Data Analytics
for Security, June 2014.
Adrian Crenshaw, Darknets and hidden servers: Identifying the true
IP/network identity of I2P service hosts, Black Hat DC, 2011.
Robert Graham,
Reading the Silk Road configuration,
http://blog.erratasec.com/2014/10/reading-silkroad-configuration.html, October 2014.
Bryan Krebs, Silk Road Lawyers Poke Holes in FBIs Story,
http://krebsonsecurity.com/2014/10/silk-roadlawyers-poke-holes-in-fbis-story/, October 2014.
Nik Cubrilovic, Large Number of Tor Hidden Sites Seized by the FBI
in Operation Onymous were Clone or Scam Sites, https://www.
nikcub.com/posts/onymous-part1/, November 2014.
JNIC2015
Prevencion de ataques ROP mediante

Instrumentacion Dinamica
Miguel Martn Perez , Ricardo J. Rodrguez , Vctor Vinals
de Informatica e Ingeniera de Sistemas, Universidad de Zaragoza
Instituto de Ciencias Aplicadas a la Ciberseguridad, Universidad de Le
on
{566966, victor}@unizar.es, rj.rodriguez@unileon.es
Departamento
W ORK IN PROGRESS
Return-Oriented Programming (ROP) es una

de las principales tecnicas de ataque de software del
panorama actual [1], ya que permite a un atacante
ejecutar codigo arbitrario existente en el espacio de
direcciones del programa. As, un atacante aprovecha una vulnerabilidad (por ejemplo, un desbordamiento de buffer) para inyectar una secuencia de
direcciones que apuntan a pequenos conjuntos de
instrucciones, llamados gadgets. Estos gadgets se
caracterizan por acabar en una instruccion de cambio de flujo, habitualmente un retorno de subrutina
que permite encadenar un gadget con otro, y por ser
codigo legtimo (es decir, perteneciente a la seccion
de codigo del programa o a la de cualquier otra
librera usada por el mismo).
Sin embargo, el hecho de que sea codigo legtimo
no implica que sea intencionado, ya que en las
arquitecturas con tamano variable de instruccion
todo byte perteneciente a la seccion de codigo es
susceptible de ser interpretado como el principio
de una instruccion. As, un atacante puede utilizar
estas instrucciones no intencionadas para localizar
los gadgets que necesita y no existen en el binario
original.
de paso correspondientes a dicha funcion. As, si

un programa es atacado, su traza de ejecucion no
coincidira con el automata y se detectara el ataque.
Se ha optado por DBI por las caractersticas de
portabilidad y adaptabilidad que aporta. Respecto a
la portabilidad, el uso de DBI permite la aplicacion
de la defensa sobre cualquier programa, ya que al
actuar sobre el binario no requiere el codigo fuente.
En lo referente a la adaptabilidad, la posibilidad
de analizar e instrumentar en ejecucion permite
que la defensa pueda adaptarse rapidamente a los
cambios, por ejemplo, obteniendo los puntos de
paso de una funcion creada en ejecucion mediante
codigo auto-modificable o instrumentando codigo
no intencionado direccionado desde un ataque. La
desventaja de usar DBI e instrumentar directamente
binarios es la dificultad de generar grafos de flujo
de las funciones (de los que se obtienen los puntos
de paso) ya que los binarios carecen de smbolos
o nombres de funciones incluso cuando estas son
exportadas. Esto implica que, antes de comenzar la
ejecucion de un fragmento de codigo, ha de hacerse
un analisis sintactico para obtener tanto los puntos
de paso como el principio y final de las funciones.
En este trabajo, tras analizar los ataques ROP,

se plantea una tecnica de deteccion de ataque en
ejecucion mediante instrumentacion dinamica de binarios (Dynamic Binary Instrumentation, DBI) [2].
La deteccion se realiza aplicando un Control de
Integridad de Flujo (CFI) mediante un automata
de pila [3], el cual ira consumiendo puntos de
paso conforme el programa pase por ellos. Con
cada llamada a una funcion en el programa, se
iran anadiendo en la pila del automata los puntos
El diseno que proponemos ofrece ciertas caractersticas que garantizan la robustez de la defensa
independientemente de la implementacion. Primero,
no se usa ningun dato pasado al programa para la
deteccion de los ataques, ya que el modo en que
se realizan los ataques es mediante estos datos y su
comprobacion o manipulacion podran ser origen de
una vulnerabilidad que permita atacar la defensa en
lugar de al programa. En su lugar, lo que se controla
y almacena son los estados del procesador (concre-
20
JNIC2015
Base (s)
Pin Null
PROPID
perlbench
484.3575
1.8491x
1.8532x
bzip2
763.5413
1.1887x
2.0960x
gcc
473.0578
1.5895x
4.1527x
gobmk
460.8152
1.4497x
4.1330x
hmmer
706.0565
1.1325x
1.1325x
sjeng
634.9261
1.4741x
1.4725x
libquantum
222.4177
1.2951x
1.2829x
h264ref
713.5450
1.8465x
1.8434x
omnetpp
515.4308
1.2059x
1.2063x
astar
534.0191
1.1124x
1.1307x
Xalan
344.2357
1.3941x
11.7568x
specrand
0.4091
6.2298x
6.2928x
1.8140x
3.1961x
Tabla I
S OBRECARGA INTRODUCIDA POR P IN Y PROPID.
tamente, el contador de programa). Segundo, se han

aislado las estructuras de control de la defensa de
las estructuras y datos propios del programa, para
evitar que una corrupcion de memoria intencionada
pudiera modificar la estructura de la defensa para
evadirla.
Hemos implementado esta idea sobre la arquitectura x86 de Intel/AMD usando PIN, una herramienta DBI de Intel [4]. Nuestro prototipo se denomina
PROPID (Prevencion de ataques ROP en ejecucion
mediante Instrumentacion Dinamica) y es efectivo
en la proteccion de ataques ROP verificando un
principio muy simple: la direccion a la que vuelve
una instruccion RET debe coincidir con la guardada
en el CALL correspondiente, respetando el nivel
de anidacion de la llamada. Para demostrar que
la defensa funciona se ha creado una prueba de
concepto con una vulnerabilidad preparada para su
explotacion y se ha buscado un software comercial
con una vulnerabilidad conocida, VLC 0.9.6 [5]. En
ambos casos PROPID detecta el ataque antes de la
ejecucion del primer gadget.
Por u ltimo, hemos ejecutado el benchmark SPEC
CPU 2006int con dos objetivos [6]. Primero, se
ha comprobado que PROPID no produce falsos
positivos. Y segundo, se ha medido la sobrecarga
introducida por Pin y por la defensa. Los resultados
se resumen en la Tabla I. El slowdown medio o
bajada de rendimiento medio, producido por Pin sin
instrumentacion es de 1.81x, que coincide con los
resultados descritos en [7]. Los programas con tiempos de ejecucion muy breves tienen una sobrecarga
mucho mayor por tener amortizar antes el tiempo consumido por Pin. Por ejemplo, el programa
specrand tarda 2.54s cuando se instrumenta con
Pin, teniendo un tiempo base de 0.4s. Las pruebas
preliminares de PROPID dan un slowdown medio
de 3.19x, con un maximo de 11.75x para Xalan.
En general consideramos que es un resultado prometedor que creemos poder mejorar.
Como posible trabajo futuro se plantea otro CFI

que asegure la ejecucion completa de las funciones,
evitando as la ejecucion de gadgets por no pasar
por el punto de entrada. Para garantizar la integridad
de las funciones, se puede usar una estructura de
marcas LIFO, de forma que al pasar por el punto
de entrada se anadiera a la estructura una marca
u nica y al final de cada funcion se verificara que
la u ltima marca existente es correcta y se eliminara.
R EFERENCIAS
[1] H. Shacham, The Geometry of Innocent Flesh on the Bone:
Return-into-libc Without Function Calls (on the x86), in
Proceedings of the 14th ACM Conference on Computer and
Communications Security (CCS). New York, NY, USA:
ACM, 2007, pp. 552561.
[2] K. Liu, H. B. K. Tan, and X. Chen, Binary Code Analysis,
Computer, vol. 46, no. 8, pp. 6068, 2013.
[3] D. Wagner and D. Dean, Intrusion detection via static
analysis, in Proceedings of the 2001 IEEE Symposium on
Security and Privacy, 2001, pp. 156168.
[4] C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S. Wallace, V. J. Reddi, and K. Hazelwood, Pin:
Building Customized Program Analysis Tools with Dynamic
Instrumentation, in Proceedings of the 2005 ACM SIGPLAN conference on Programming Language Design and
Implementation (PLDI), ser. PLDI 05. New York, NY,
USA: ACM, 2005, pp. 190200.
[5] Exploit Database, VLC Media Player < 0.9.6 - (.rt) Stack
Buffer Overflow Exploit, [Online], November 2008, https:
//www.exploit-db.com/exploits/7051/.
[6] SPEC, SPEC CPU 2006, https://www.spec.org.
[7] G.-R. Uh, R. Cohn, B. Yadavalli, R. Peri, and R. Ayyagari,
Analyzing dynamic binary instrumentation overhead, in
WBIA Workshop at ASPLOS, 2006.
21
JNIC2015

1
Robustenciendo Apache Frente a Ataques de

Desbordamiento de Pila
Hector Marco e Ismael Ripoll
Universitat Politènica de València
{hecmargi,iripoll}@upv.es http://cybersecurity.upv.es
Resumen Apache es el servidor web m
as utilizado, por
lo que encontrar un fallo afecta a muchos sistemas, lo que
alienta a los atacantes a explotar vulnerabilidades en estos
servidores.
Uno de los vectores de ataque m
as explotado es el desbordamiento de pila. Un ejemplo, es el reciente ataques
llamado Offset2lib, el cual bypasea tanto el SSP como el
ASLR en menos de un segundo. Por ello, es imperativo
aplicar mecanismos de protecci
on que prevengan ataques
de este tipo.
En este trabajo se estudia la viabilidad de aplicar la
t
ecnica renewSSP la cual elimina todo tipo de ataques de
fuerza bruta contra el SSP en servidores Apache. Se concluye que el renewSSP puede ser aplicado de forma transparente sin necesidad de modificar el c
odigo de Apache y
con un sobrecarga inapreciable.
n
I. Introduccio
Apache es un servidor web ampliamente conocido y actualmente sigue siendo el mas utilizado [1]. Desafortunadamente, esto hace que sea tambien uno de los m
as
atacados. Tanto Apache como el resto de servidores de
red deben ser a la vez robustos y rapidos. Es por ello que
en general solo se utilicen tecnicas de protecci
on con una
sobrecarga muy baja.
Uno de los vectores mas conocidos y utilizados por los
atacantes contin
ua siendo el clasico desbordamiento de
pila. Existen tecnicas de proteccion como el NX (NoneXecutable), SSP (Stack Smashing Protector) o Address
Space Layout Randomization (ASLR) que reducen en gran
medida el exito de los atacantes. Desgraciadamente, todava existen ataques que logran circunvalar estas protecciones. Un ejemplo es el reciente ataque llamado Offset2lib, el cual bypasea todas estas tecnicas de protecci
on.
Este ataque, en su version mas rapida y peligrosa, utiliza
un ataque de fuerza bruta conocido como byte-for-byte [2]
para derrotar al SSP, lograndolo en menos de un segundo.
En este papel se presenta un breve resumen de la tecnica
RenewSSP y como esta se puede utilizar en el servidor
Apache de dos formas diferentes: de forma transparente
sin modificar el binario de Apache (mediante la carga de
una librera previa, LD PRELOAD), y por otra parte, modificando los fuentes.
II. RenewSSP
RenewSSP [3] es una modificacion de la tecnica de protecci
on Stack Smashing Protector (SSP) la cual elimina
los ataques de fuerza bruta contra el canario de pila. La
tecnica consiste en renovar el valor del canario de un proFinanciado por la Universitat Polit`
ecnica de Val`
encia 2014-4186.
22
ceso hijo por un nuevo valor aleatorio cuando la llamada

fork() es invocada.
Volver a randomizar el canario en tiempo de ejecucion
fue planteado por H.Marco et al. [4] como medida preventiva frente a los ataques de fuerza bruta contra el canario
en ataques de desbordamiento de pila.
Puesto que el valor del canario que protege los datos
sensibles del marco de pila actual debe ser invariante al
inicio y la concluir la funci
on (de hecho, si el canario ha
sido modificado antes de retornar, el proceso se aborta),
solo se puede cambiar el valor de canario si y solo s se
dan las siguientes condiciones:
1. La funci
on del proceso hijo donde se cambia el canario
nunca vuelve a la funci
on llamadora, o
2. La funci
on donde se cambia el canario vuelve a la
funci
on llamadora (o alguna de sus antecesoras) pero no
comprueba el canario.
Puesto que la renovaci
on del canario se realiza una u
nica
vez al inicio de la ejecuci
on del proceso hijo y esta consiste en obtener un n
umero aleatorio, la sobrecarga es
pr
acticamente inapreciable.
RenewSPP es una ayuda efectiva para prevenir la infecci
on de sistemas frente spyware, adware y otros amenazas desconocidas. M
as detalles sobre est
a nueva tecnica
en [4].
III. Apache 2
El servidor web Apache puede ejecutarse en diferentes
modos dependiendo del grado de seguridad o rendimiento
que se desee. B
asicamente se pueden diferenciar dos modos de ejecuci
on: el modelo de hilos (threaded) y el modelo
de procesos (forking). En el primer caso, cada peticion
es atendida por un hilo lo cual tiene mayor rendimiento y
menor consumo de memoria, pero es m
as inseguro. Esto es
as por que si un hilo termina incorrectamente, la ejecucion
de los dem
as hilos, ser
a abortada. Como consecuencia,
todas las conexiones asociadas a cada hilo de ejecuci
on se
cerrar
an, aunque estos no hayan generado error, pudiendo
provocar una denegaci
on de servicio a otros usuarios.
En forking model, cada petici
on web es atendida por
un proceso, evitando as que un error (intencionado o no)
afecte a los dem
as clientes. Aunque el consumo de recursos
es un poco mayor, es el modelo m
as utilizado ya que se
consigue mayor grado de seguridad. Por otra parte, el
protocolo http es stateless lo que permite que cada peticion
se puede manejar de forma completamente independiente,
haciendo al modelo forking el m
as recomendable. En este
trabajo se considerar
a solo el modelo de procesos.
JNIC2015

2
que incrustar
a el c
odigo de las funciones make child()
y child main() en una sola funci
on. Por otra parte,
dado que la funci
on child main() termina llamando a
clean child exit(), se garantiza que no se vuelve a
la funciona llamadora con lo que el RenewSSP se puede
aplicar de manera transparente. Observese que aunque
solo una condici
on es necesaria, se cumplen las dos.
B. RenewSSP modificando Apache
Fig. 1: Multi-process model en Apache

Aunque el esquema forking model en principio proporciona m
as seguridad y estabilidad, abre las puertas a otros
vectores de ataques. En concreto, es susceptible a ataques
de fuerza bruta contra el canario (usado en la tecnica
SSP), siendo la variante conocida como byte-by-byte attack una de las mas peligrosas [2]. Por ello es interesante
disponer de nuevos mecanismos de protecci
on que eliminen la posibilidad de realizar este tipo de ataques. En
las pr
oximas secciones se describe como la tecnica de protecci
on RenewSSP se aplica a Apache.
La otra forma de aplicar la tecnica RenewSSP es modificando el c

odigo de la aplicaci
on. A continuaci
on se muestra cuales seran los cambios necesarios en el c
odigo fuente
de Apache para aplicar el RenewSSP.
+++
+++
+++
+++
+++
IV. RenewSSP en Apache 2

La tecnica RenewSSP puede ser usada por las aplicaciones bien de manera transparente o mediante mnimas
modificaciones del codigo fuente de la aplicaci
on. A continuaci
on se detallan estas dos formas aplicadas a Apache.
A. RenewSSP sin modificar Apache
La manera mas sencilla y rapida de usar RenewSSP en
una aplicacion es reemplazando las funciones involucradas
en la creacion de nuevos procesos: fork() o clone(). La
nueva funcion fork es un peque
no wrapper que despues de
llamar a la funcion fork nativa renueva el canario llamando
a la funci
on renewSSP() (ver el codigo 2) de referencia en
el proceso hijo.
+++
void renewSSP() {
unsigned long rnd = 0;
getrandom(&rnd, sizeof(rnd)-1, 0);
THREAD SET STACK GUARD(rnd);
}
static int make_child(...) {
if ((pid = fork()) == -1) {
...
}
if (!pid) {
...
renewSSP();
child_main();
}
}
Listing 2: Modificaciones de Apache

Como se puede apreciar en el c
odigo 2, tanto los cambios como sobrecarga temporal introducida son mnimos.
Solamente se necesita una llamada a renewSSP() justo
al principio de empezar a ejecutarse el nuevo hijo
creado. La funci
on renewSSP() es la que cambia el canario obteniendo un n
umero aleatorio mediante la syscall
getramdom().
V. Conclusiones
static void startup_children (int number_to_start) {

for (...) {
make_child(...);
}
...
}
static int make_child(...) {
if ((pid = fork()) == -1) {
...
}
if (!pid) {
...
child_main();
}
}
static void child_main(int child_num_arg){
...
clean_child_exit(0);
}
Se ha estudiado la viabilidad de la novedosa tecnica

RenewSSP en servidores Apache actuales (2.4.7). Se han
presentado dos metodos alternativos de aplicaci
on de la
tecnica de protecci
on.
Tal como era de esperar, la tecnica se ha podido aplicar
con exito sin necesidad de modificar la l
ogica de Apache.
La evaluaci
on experimental (no presentada en este
artculo corto) muestra que: 1) no es posible realizar
ataques de fuerza bruta; 2) no introduce sobrecarga medible.
Referencias
Listing 1: Creacion de procesos hijo en Apache 2

El c
odigo del listado 1 muestra las funciones de Apache
involucradas en la creacion de los procesos hijos. Todas estas funciones estan declaradas como static, por lo que el
compilador1 no generara una llamada a funci
on real, sino
1 Puesto que Apache est
a compilado el m
aximo nivel de optimizaci
on.
23
[1] (2015,
January)
Netcraft.
[Online].
Available: http://news.netcraft.com/archives/2015/01/15/january2015-web-server-survey.html
[2] A. pi3 Zabrocki, Scraps of notes on remote stack
overflow exploitation, November 2010. [Online]. Available:
http://www.phrack.org/issues.html?issue=67&id=13#article
[3] (2014,
April)
RenewSSP.
[Online].
Available:
http://renewssp.com
[4] H. Marco-Gisbert and I. Ripoll, Preventing brute force attacks
against stack canary protection on networking servers, in 12th
International Symposium on Network Computing and Applications, August 2013, pp. 243250.
JNIC2015

1
Prevencion de Explotacion de Vulnerabilidades

Mediante Diversificacion por Emulacion
Ismael Ripoll y Hector Marco
Universitat Politècnica de València
{iripoll,hecmargi}@upv.es http://cybersecurity.upv.es
Resumen
Las t
ecnicas de emulaci
on y virtualizaci
on se han utilizado en el campo de la seguridad como soporte a arquitecturas MILS (Multiple Independent Levels of Security/Safety). En este papel se presenta otra novedosa aplicaci
on de la emulaci
on como forma para conseguir diversificaci
on software, a partir de la cual se propone construir
una arquitectura N-modular-redundante software (Diversified Replication Infrastructure Though Architecture Emulation, DRITAE) capaz de detectar y evitar la explotaci
on
de fallos de programaci
on.
DRITAE es una soluci
on robusta en la medida que permite mantener la continuidad del servicio incluso ante
ataques de fuerza bruta. Por otra parte, impide la ejecuci
on
de c
odigo remota convencional: la mayora de los exploits
que emplean ROP (Return Oriented Programming) seran
bloqueados.
n
I. Introduccio
En la practica es imposible dise
nar e implementar un
sistema libre de fallos. Esto nos obliga a a
nadir mecanismos de tolerancia a fallos en aquellos sistemas utilizados en tareas sensibles (sistemas de alta integridad, infraestructuras crticas, manejo de datos confidenciales o
privados, etc.).
La tolerancia a fallos se basa en la redundancia. Un caso
particular son los sistemas TMR (Triple Modular Redundancy), donde el mismo dispositivo es replicado tres veces
y configurado de forma que los tres dispositivos operen en
paralelo junto con un votador/comparador que valida las
salidas. El objetivo de un TRM es el de tolerar los fallos derivados de los errores (errores fsicos o l
ogicos). La
tecnica TMR se aplica en casi todos los ambitos de los sistemas hardware, desde simples celdas de memoria hasta
procesadores completos, como por ejemplo la serie Leon*FT (empleado por la ESA en las misiones espaciales).
Desgraciadamente, una solucion tan sencilla, potente y
flexible no es aplicable directamente al software ya que
este no se estropea con el uso. Por otra parte, puesto
que el software debe ser determinista, esto es, varias ejecuciones del mismo programa deben dar los mismos resultado, la replicacion exacta del software a
nade poca o
ninguna mejora a la seguridad/fiabilidad del mismo.
En [1] Avizienis et al. propusieron la tecnica de programaci
on N-version, en la cual varios equipos de desarrolladores escriben de forma independiente varias aplicaciones a partir de una u
nica especificacion. Posteriormente, se ejecutaran los programas simultaneamente y se
compararan las salidas. Desafortunadamente, los resultados no fueron todo lo buenos que caba esperar. Por una
Financiado por la Universitat Polit`
ecnica de Val`
encia 2014-4186.
24
parte, el coste econ

omico se cuadruplicaba; y en el aspecto
tecnico se comprob
o que los humanos tendan a cometer el
mismo tipo de fallos ante los mismos problemas. La conclusi
on fue que no era pr
actica la diversificaci
on producida
por humanos.
En este papel se presenta un breve resumen de la
situaci
on de las tecnicas de diversificaci
on autom
atica de
software, y se esboza una posible lnea de investigacion
que dara (muy posiblemente) como resultado una arquitectura segura de alta integridad: DRITAE.
II. Conceptos y terminologa
Se denomina variante a cada uno de los ejecutable/procesos que se obtienen tras la diversificaci
on.
Las
propiedades que deben tener las variantes son:
Cuando las tres variantes reciben datos que no generan
fallo, las salidas deben ser equivalentes. Esto es, todas las
variantes deben ser sem
anticamente equivalentes.
Cuando los datos de entrada generan alg
un fallo, entonces las salidas deben ser distintas en cada m
odulo. En
caso contrario, las variantes no serviran para detectar
fallos.
Una vez se dispone de las variantes, se pueden dise
nar
varios esquemas redundantes: recovery blocks [2], nvariant [3], alternancia de variantes [4], etc.
Existen multitud de propuestas para lograr la diversificaci
on autom
atica. En general, podemos clasificarlas en
dos grandes grupos:
Diversificaci
on en tiempo de compilaci
on. Dado
un c
odigo fuente, se modifica el compilador o el linker para
que genere c
odigo binario diferente en cada compilacion.
Diversificaci
on durante la carga del proceso.
Ciertas caractersticas del proceso se modifican al cargarse
en memoria. ASLR (Address Space Layout Randomization) es, con diferencia, la tecnica m
as ampliamente utilizada, presente en la mayora de los sistemas actuales.
n Mediante Emulacio
n
III. Diversificacio
Recientemente los autores del presente artculo propusieron una nueva forma de generar variantes mediante el
uso de compiladores cruzados y emuladores [4]. La tecnica
consta de dos fases: 1) generaci
on de las variantes y 2) ejecuci
on de las mismas.
Las variantes se generan a partir de un u
nico c
odigo
fuente que se compila para distintos procesadores empleando para ello compiladores cruzados ya existentes. Gracias al amplio soporte de procesadores/targets del GCC
(Gnu C compiler) y a la portabilidad de Linux, es posible
libs
Syscall
translator
Host OS
(a)Platform
CPU
emulator
Source code
Crosscompiler
suite 1
...
Crosscompiler
suite N
Variant 1
libs
...
Variant N
libs
Syscall
translator
CPU 1
emulator
...
Syscall
translator
Virtualizer
Syscall interceptor
Monitor Consistency detector
Host OS
CPU N
emulator
Virtualizer
Startup
Policy
Syscalls
Fig. 2: Arquitectura N-variant DRITAE.
V. Conclusiones
Syscalls
(b)User-mode
Fig. 1: Modos de emulacion.

La tecnica DRITAE tiene las siguientes ventajas e inconvenientes:
+) Reaprovecha el amplio numero de arquitecturas target
soportadas por el GCC. Con lo que se evita la necesidad de
mantener modificaciones o parches sobre compiladores1 .
+) Se consigue una gran diversificacion entre las variantes. Existen substanciales diferencias entre ciertos
procesadores: direccion de la pila, estructura de los registros, opcodes, alineamientos, tama
no de palabra, etc.
+) Existente soporte fiable para la emulacion. La emulaci
on usermode de Qemu ofrece la posibilidad de ejecutar
distintos binarios sobre un u
nico sistema anfitri
on.
+) Efectividad alta frete a ataques complejos de detectar
como info leaks, no solucionados como ROP, incluyendo
ataques desconocidos tipo 0-day.
-) La sobrecarga introducida por la necesidad del emulador.
IV. N-variant DRITAE
Consiste en ejecutar concurrentemente varias variantes
de diferentes arquitecturas y comparar los resultados
de todas ellas para encontrar discrepancias en las salidas.
Los puntos de sincronizacion se establecen a la entrada de
1 Usado
las llamadas al sistema, donde se comprueba la equivalencia de las ejecuciones y se aplica la poltica de seguridad.
Se ha desarrollado una prueba de concepto en Linux,
consistente en un proceso monitor que intercepta las llamadas al sistema de las variantes mediante los servicios
de ptrace(). La figura 2 muestra un esbozo de la arquitectura N-variant DRITAE desarrollada.
Guest
applicaon
(variant)
Usermode
virtualizer
Oline
compilar un u
nico programa para muchos sistemas diferentes sin necesidad de adaptar el codigo. Como resultado se disponen de varios ejecutables en formato ELF
para distintas arquitecturas, siendo estos sem
anticamente
equivalentes.
La segunda parte de la tecnica consiste en ejecutar eficientemente estos programas. Para ello se emplea la emulaci
on a nivel de proceso usando Qemu (Qemu usermode).
Qemu dispone de dos formas de emulacion: 1) system
mode y 2) usermode. En la primera como muestra la
Fig. 1(a), se emula tanto el procesador (juego de instrucciones) como el hardware asociado a una plataforma fsica
(ROM, buses, perifericos,...). La emulacion usermode consiste en emular el procesador y traducir las llamadas al sistema . La Fig. 1(b) esboza esta forma de emaulaci
on; por
ejemplo un ejecutable ARM para Linux puede ejecutarse
en un Linux x86 puesto que los servicios ofrecidos por el
sistema operativo son compatibles.
Online
JNIC2015
en la mayora de las t
ecnicas de diversificaci
on.
25
La diversificaci
on de software requiere de potencia adicional de c
omputo, bien utilizando m
as procesadores o
bien ejecutando de forma concurrente cada una de las
variantes. Por suerte, la evoluci
on de la tecnologa de
los microprocesadores ha jugado a favor de soluciones Nvariant (m
ultiples cores, aumento de memoria, ...). Por
otra parte, gracias a las nuevas funcionalidades recientemente a
nadidas al n
ucleo de Linux, es posible simplificar
y optimizar substancialmente la sobrecarga del monitor.
Como resultado, podemos afirmar que es pr
actico construir un sistema monitor N-variant capaz de bloquear
muchos de los futuros ataques, especialmente aquellos que
se valen de la peligrosa ejecuci
on de c
odigo remota.
Una vez se disponga de un monitor generico, ser
a posible securizar cualquier aplicaci
on de forma completamente
autom
atica.
Referencias
[1] A. Avizienis, The n-version approach to fault-tolerant software, IEEE Transactions on Software Engineering, vol. 11, pp.
14911501, 1985.
[2] M. R. Lyu, Software fault tolerance. John Wiley & Sons, Inc.,
1995.
[3] B. Cox, D. Evans, A. Filipi, J. Rowanhill, W. Hu, J. Davidson,
J. Knight, A. Nguyen-Tuong, and J. Hiser, N-variant systems:
a secretless framework for security through diversity, in
Proceedings of the 15th conference on USENIX Security
Symposium - Volume 15, ser. USENIX-SS06. Berkeley,
CA, USA: USENIX Association, 2006. [Online]. Available:
http://dl.acm.org/citation.cfm?id=1267336.1267344
[4] B. Akhgar and H. R. Arabnia, Eds., Emerging trends in ICT
security. Elsevier Inc, Dic 2013, ch. 21, pp. 335357.
JNIC2015

1
Sistema Inmunitario Adaptativo para la Mitigacion

de Ataques de Denegacion de Servicio
Jorge Maestre Vidal, Ana Lucila Sandoval Orozco and
Luis Javier Garca Villalba, Senior Member, IEEE
Grupo de Analisis, Seguridad y Sistemas (GASS, http://gass.ucm.es)
Departamento de Ingeniera del Software e Inteligencia Artificial (DISIA)
Facultad de Informatica, Despacho 431, Universidad Complutense de Madrid (UCM)
Calle Profesor Jose Garca Santesmases, 9, Ciudad Universitaria, 28040 Madrid, Espa
na
E-mail: jmaestre@ucm.es, {asandoval, javiergv}@fdi.ucm.es
Resumen En este artculo se propone el uso de Sistemas Inmunitarios Artificiales (AIS) para la mitigaci
on de
ataques de Denegaci
on de Servicio (DoS) basados en inundaci
on. La propuesta se basa en la construcci
on de redes
de sensores distribuidos a lo largo del entorno protegido.
Estos componentes son capaces de identificar las amenazas
y reaccionar acorde al comportamiento de los mecanismos
biol
ogicos de defensa en los seres humanos. Para ello se
emula su reacci
on ante diferentes tipos de incidencias, y
se elabora una memoria inmunitaria. La experimentaci
on
realizada demuestra su eficacia y precisi
on al desplegarse
sobre redes de diferentes caractersticas.
n
I. Introduccio
El importante aumento de los ataques de Denegaci
on
de Servicio (DoS) observado en los u
ltimos a
nos ha puesto
sobre aviso a las principales organizaciones para la ciberseguridad. Seg
un informa la Agencia Europea de Seguridad
de las Redes y de la Informacion (ENISA) [1], desde el
a
no 2013 su capacidad de inundacion de redes ha experimentado un crecimiento promedio del 70% respecto al
del a
no 2013. La mayor parte de los ataques DoS identificados se han basado en la inundacion por medio de la
inyecci
on de un gran volumen de trafico, cuyo nivel de
congesti
on mas alto ha superado un 240% al observado en
2013 (agotando un ancho de banda de 325 Gbps). Esto es
debido principalmente a la mejora de su capacidad de reflexi
on, la sofisticacion de las botnets a partir de las cuales
son ejecutados, su cada vez menor dependencia de ellas,
la eficacia de los nuevos metodos para la evasi
on de sistemas de deteccion y el crecimiento de las estrategias de
ocultaci
on de su rastro. En consecuencia, la comunidad
investigadora se ha volcado en el estudio de esta amenaza y
el desarrollo de contramedidas [2]. Sin embargo, y dado el
continuo crecimiento de estas intrusiones, es evidente que
todava esta muy por detras de los atacantes. Este hecho
lleva a la necesidad de plantear enfoques innovadores, que
sean capaces de abrir futuras lneas de trabajo, abarcando
las principales carencias de la bibliografa.
De entre estas soluciones destacan los Sistemas Inmunitarios Artificiales (AIS). Los AIS son aproximaciones a
problemas de computacion inspirados en los principios y
procesos, involucrados en las defensas biologicas de los organismos vertebrados. Su implementacion habitualmente
26
ofrece un compromiso entre los beneficios obtenidos al detectar y mitigar el ataque, frente a la mera adopci
on de
estrategias preventivas. Esto hace que su aplicaci
on resulte especialmente eficaz en el
area de la seguridad de la
informaci
on, tanto en la detecci
on de malware [3] como
en la defensa frente a ataques de denegaci
on de servicio
[4]. Con esta motivaci
on, en este paper se propone una
estrategia para la mitigaci
on de ataques DoS de origen
dristribuido (DDoS) basados en inundaci
on. Para ello se
introduce el despliegue de una red de sensores que integra
un AIS inspirado en los mecanismos de defensa biol
ogicos
de los seres humanos. A diferencia de propuestas similares, no se han aplicado metodos convencionales de reconocimiento de patrones bioinspirados. En su lugar se
propone una combinaci
on de las estrategias de detecion
de DDoS basadas en el estudio de variaciones en la entropa y la construcci
on de umbrales predictivos, con la
adaptaci
on de las reacciones inmunitarias biologicas. De
este modo es posible la aplicaci
on en tiempo real de contramedidas, y la elaboraci
on de una memoria inmunitaria.
El resto del artculo est
a estructurado de la siguiente
manera: en la secci
on 2 se describen los trabajos relacionados con la denegaci
on de servicio, el sistema inmunitario
humano, y sistemas artificiales inmunitarios. En la seccion
3 se propone un AIS para la mitigaci
on de ataques DDoS.
En la secci
on 4 se describe la experimentaci
on realizada y
se discuten sus resultados. Finalmente, en la secci
on 5 se
presentan las conclusiones.
II. Trabajos relacionados
A. Denegaci
on de Servicio
En [2] se recopilan las principales tendencias de la defensa frente amenazas de denegaci
on de servicio, y son
agrupadas considerando diferentes ejes de clasificaci
on.
Uno de los m
as recurrentes es su manera de actuar. En
base a esto, los esquemas defensivos son divididos en tres
categoras: detecci
on, mitigaci
on e identificaci
on del origen.
La detecci
on de los ataques de denegaci
on de servicio a menudo desencadena el resto de tareas defensivas.
Con este fin, en los u
ltimos a
nos ha sido propuesta una
gran cantidad de estrategias, como modelos de Markov
JNIC2015

2
[5], matrices de correlacion [6], teora del Caos [7], modelos predictivos y CUSUM sobre series temporales [8], visualizaci
on [9] o logica difusa [10]. Uno de los metodos
de mayor proyeccion en la actualidad es el an
alisis basado
en la observacion de variaciones en la entropa del tr
afico.
En [11] se demuestra que ofrece mejor precisi
on que las
otras tecnicas al procesar datos procedentes de redes con
caractersticas muy heterogeneas, tal y como sucede en
las redes actuales. En [12] se recopilan diferentes aproximaciones relacionadas con la aplicacion de la entropa en
este tipo de problemas y se discuten posibles metodos de
evasi
on.
Las propuestas para la mitigacion de los ataques de
denegaci
on de servicio tienen como objetivo la reducci
on
total o parcial del da
no causado por la intrusi
on. De
entre los temas de mayor candencia destacan el uso de
puzles para el reconocimiento de usuarios no humanos
[13], trampas y se
nuelos [14], ampliacion del ancho de
banda, filtrado y protocolos de seguridad [15]. Los tres
u
ltimos tambien pueden ser desplegados como herramientas de accion preventiva. Por otro lado, la identificaci
on
del origen trata de desenmascarar la ruta que ha seguido
el ataque con el fin de llegar hasta su autor. Es una labor
que en los u
ltimos a
nos ha ganado complejidad, dado el
crecimiento de los metodos de ocultacion de rastros. En
[16] se discute este problema, se recopila una gran cantidad de aproximaciones actuales, y se introduce un nuevo
esquema de seguimiento uniforme. En [17] se estudia la
influencia de las caractersticas de la topologa de la red
en la eficacia de las estrategias de marcados de paquetes.
B. El Sistema Inmunitario Humano
Las distintas especies han desarrollado m
ultiples mecanismos inmunitarios, destacando entre ellos, y por su nivel
de sofisticacion, los de las especies vertebradas. Dichos
sistemas constan de muchos tipos de protenas, celulas,
organos y tejidos, los cuales se relacionan en una red elab
orada y dinamica. Como parte de esta respuesta inmunitaria mas compleja, el sistema inmunitario humano se
adapta con el tiempo para reconocer antgenos especficos
de manera mas eficaz. A este proceso de adaptaci
on se
le llama inmunidad adaptativa. A los mecanismos de defensa no adquiridos se les llama inmunidad innata, y habitualmente constituyen su primera lnea de defensa. En
la inmunidad innata cada agente es capaz de reconocer
y eliminar diferentes tipos de antgenos. Las reacciones
inmunitarias innatas son de rechazo, y se llevan a cabo
por barreras externas fsicas como la piel o mucosas, y de
elementos defensivos internos, como fagocitos o celulas asesinas naturales NK (del ingles Natural Killers). Carecen
de memoria inmunitaria, y u
nicamente es efectiva contra
pat
ogenos conocidos a priori.
Por otro lado, la inmunidad adaptativa presenta especificidad, es decir, tras aprender a rechazar un antgeno,
el conocimiento adquirido permite reaccionar con mayor
contundencia contra el. Las celulas mas importantes de
este proceso son los linfocitos y las celulas presentadoras.
Existe dos tipos de reacciones inmunitarias adaptativas:
humorales y celulares. En ambas participan agentes en-
27
cargados de reconocer al antgeno, y de su eliminaci

on. En
la reacci
on humoral, los anticuerpos Ac detectan y eliminan la amenaza por degluci
on. Los restos de este proceso
son capturados por linfocitos Th , y estos estimulan a los
linfocitos Tb para generar una cantidad a
un mayor de Ac
especializada en reconocer esa amenaza. Sin embargo, en
la respuesta celular los propios linfocitos Th detectan la
intrusi
on. Entonces atraen a citotoxinas Tc para su eliminaci
on. Al igual que en el caso anterior, los restos estimulan su generaci
on, especializ
andolas contra la nueva
amenaza. Los nuevos linfocitos podr
an identificar y detectar directamente el antgeno.
En ambas reacciones, el incremento de las medidas defensivas es temporal. Pasado un periodo de cuarentena,
el sistema se regula mediante la eliminaci
on del exceso
de efectivos. Estos est
an programados para desaparecer mediante apoptosis o muerte celular. La inmunidad
adquirida es la base de la vacunaci
on en los seres humanos.
Al detectarse muestras de un antgeno es posible desarrollar contramedidas temporales y especficas para su eliminaci
on. De este modo la respuesta es m
as r
apida y mas
efectiva.
C. AIS en la Ciberseguridad
La adaptaci
on de las defensas biol
ogicas a la seguridad de la informaci
on habitualmente se lleva a cabo mediante el despliegue de sistemas multiagente [18], y la emulaci
on de la actividad en las celulas inmunitarias. Estas
a menudo aplican cuatro tipos de algoritmos: seleccion
negativa, selecci
on clonal, redes inmunitarias artificiales y
teora del peligro (DT).
La selecci
on negativa es el proceso mediante el cual los
agentes inmunitarios aprenden a distinguir antgenos del
resto de celulas del propio organismo. En aproximaciones
como [19] se aplica en la detecci
on de anomalas. Pero tal y
como apuntan sus autores, es una metodologa que tiende
a la generaci
on de altas tasas de falsos positivos, situacion
que frecuentemente lleva a su complementaci
on mediante
algoritmos de selecci
on clonal [20]. Estos parten de asumir
que cada linfocito en su etapa de crecimiento debe de ser
capaz de reaccionar contra un antgeno concreto antes
de ser liberado en el organismo. La selecci
on clonal es
una soluci
on eficaz a problemas de reconocimiento y optimizaci
on [21]. En propuestas como [22] tambien se aplica
a la identificaci
on de malware.
Las redes inmunitarias parten de las bases de la selecci
on clonal, extendidas al
ambito de redes. Suele utilizarse para que los distintos actores de los AIS interact
uen
entre s. Por ejemplo, en [23] se usa para relacionar agentes
que implementan tecnicas de selecci
on negativa, mientras
que en [24] se combina con la teora del peligro.
La teora del peligro tiene en cuenta los u
ltimos avances
de la investigaci
on medica. En consecuencia, y al contrario
que sus predecesores, rechaza la idea de que los organismos tengan capacidad de distinguir entre celulas propias
y antgenos. En su lugar postula que la activaci
on de
las reacciones inmunitarias tiene su origen en se
nales de
alerta procedentes de tejidos en contacto con la amenaza.
Se trata de uno de los algoritmos m
as frecuentes en la bib-
JNIC2015

3
liografa. Las bases para su adaptacion a la detecci

on de
intrusiones son propuestas en [25]. En [26] se aplica en la
detecci
on de intrusiones mediante el estudio de llamadas
al sistema.
No todos los AIS se basan en procesos concretos de los
esquemas inmunitarios. Algunas aproximaciones imitan
las caractersticas de las reacciones inmunitarias innatas
y adaptativas de los seres vertebrados. En [27] esto se
aplica a la deteccion de anomalas en el trafico de redes.
Su respuesta inmunitaria adaptativa implica la clonaci
on
de un mayor n
umero de agentes anticuerpos en las regiones
amenazadas. En [28] los anticuerpos son agentes m
oviles
que recorren una red en busca de indicios de da
no.
III. AIS para la defensa frente a DDoS
A. Caractersticas del Dise
no
Las principales caractersticas del sistema inmunitario
biol
ogico han sido asumidas, y adaptadas a la defensa
frente a DDoS de la siguiente manera:
Respuesta innata y adquirida. la propuesta tiene capacidad de reaccion frente a ataques DDoS no reconocidos con anterioridad. Una vez detectados, fortalece
las medidas defensivas contra futuras replicas.
Especificidad. En la naturaleza cada c
elula inmunitaria reacciona contra un u
nico tipo de antgeno. En
esta aproximaci
on, la respuesta innata es com
un ante
cualquier tipo de amenaza detectada. Sin embargo, la
reacci
on inmunitaria u
nicamente afecta a la detecci
on
del ataque de inundacion que la ha desencadenado.
Clonalidad. Al detectarse un ant
geno desconocido, la
respuesta adaptativa biologica clona las celulas que han
sido capaces de reconocerlo. De este modo aumentan las
posibilidades de identificar sus replicas. En esta aproximaci
on sucede lo mismo al detectarse ataques DDoS
desconocidos.
Memoria inmunitaria. Tanto en la naturaleza como en
la propuesta, al detectarse una amenaza las contramedidas adoptadas son conservadas durante un periodo
de tiempo. Esto permite reaccionar con mayor eficacia
ante futuras replicas.
Autorregulaci
on. Tras la respuesta adaptativa, el sistema inmunitario humano es regulado por la apoptosis
de gran parte las nuevas celulas. En esta propuesta, las
nuevas medidas defensivas tambien son reducidas tras
pasar un determinado periodo de tiempo sin detectarse
replicas de la misma amenaza.
Autonom
a. En ambos casos las entidades del esquema
defensivo operan sin un control centralizado.
Diversidad. El conjunto de agentes inmunitarios debe
de ser capaz de detectar cualquier tipo de antgeno.
Por lo tanto, el dise
no debe de ser capaz de identificar
cualquier tipo de DDoS basada en inundaci
on.
B. Comportamiento del Sistema
Se han considerado dos tipos de agentes: detectores H
o DH y detectores A o DA . Los DH se involucran tanto
en la respuesta inmunitaria innata como en la adaptativa.
En consecuencia permiten la deteccion y el bloqueo de
28
nuevos ataques y participan en la elaboraci

on de la memoria inmunitaria. Finalmente los DA tienen la capacidad de
detectar y mitigar ataques previamente identificados por
los DH . Sus comunicaciones internas se llevan a cabo en
un canal diferente del protegido, con el fin de fortalecer al
sistema de ser inutilizado y reducir su impacto en la calidad de servicio de la red. El AIS act
ua en las siguientes
etapas:
1. Inicialmente los DH analizan el tr
afico que fluye a
traves de ellos. Los DA permanecen en inactividad
hasta ser activados. Cuando los DH identifican amenazas procedentes de un nodo intermedio, bloquean su
conexi
on (respuesta innata). A continuaci
on envan
se
nales a los DA de las proximidades para proceder a
su activaci
on frente a esa amenaza (respuesta adaptativa).
2. Cuando los DA son activados, analizan el tr
afico procedente del atacante. A diferencia de DH , el nivel de
restricci
on de su umbral de decisi
on es incrementado
proporcionalmente a las caractersticas del ataque.
Tambien bloquean las amenazas identificadas. De este
modo, si el ataque sigue rutas alternativas tambien es
mitigado.
3. Cuando diferentes DH emiten se
nales de activacion
para contrarrestar un ataque, los DA tienen en cuenta
la m
as restrictiva. Los DA se desactivan u
nicamente
cuando ha pasado un periodo de tiempo de cuarentena,
o no han recibido se
nales de activaci
on. Los DH permanecen continuamente en estado de monitorizaci
on.
En Fig. 1 se muestra un ejemplo del comportamiento
del AIS frente a un ataque DDoS. Este parte de la
situaci
on mostrada en Fig. 1(a), donde S es el nodo origen, T el nodo destino y Ni el nodo i intermedio. En
el caso de que el sensor DH no sea capaz de reconocer
la amenaza, se propagar
a a lo largo de la red protegida,
debido a sus polticas de balanceo de carga (Fig. 1(b)).
Pero si el ataque es detectado con exito, DH reacciona
de manera innata, descartando el tr
afico procedente del
origen, y alertando a los DA vecinos (Fig. 1(c)). Estos
activar
an su respuesta adaptativa cada vez que el ataque
intente trazar caminos alternativos (Fig. 1(d)), mitigando
completamente la amenaza.
A pesar de su sencillez, este esquema presenta una serie de ventajas muy efectivas. En primer lugar, permite
aumentar las medidas defensivas al reconocerse una amenaza. Esto hace que su sobrecarga sea proporcional al
nivel de riesgo de la red. Adem
as, la propiedad de especificidad de los sistemas biol
ogicos hace que s
olo se apliquen
en conexiones concretas, sin afectar al an
alisis del resto del
tr
afico. Por otro lado, la presencia de dos tipos de agentes
permite adaptar el despliegue defensivo al entorno de monitorizaci
on. Los sensores con mayor capacidad de c
omputo
actuar
an como DH y el resto como DA . N
otese que un
mismo nodo podra desempe
nar ambas funciones. Finalmente, el nivel de restricci
on del sistema se autorregula
por medio de la desactivaci
on de los sensores pasado un
tiempo de cuarentena. Mientras la activaci
on frente a una
amenaza concreta pertenezca activa, esta formar
a parte
de la memoria inmunitaria.
JNIC2015

4
N3
DA
DH
DA
N5
DA
DA
DH
DA
N5
DA
N5
U Sup(t) = p0 + K
N3
DA
donde Bt es la estimaci
on base en t, Tt es la estimaci
on de
la tendencia y St la estimaci
on del factor estacional. Los
par
ametros , y est
an comprendidos en el intervalo
0 < , , < 1, y permiten ajustar el alisado. El valor
estimado corresponde con Ht+1 = Bt + Tt + St , ya que se
ha aplicado su versi
on aditiva. El intervalo de prediccion
se calcula por el metodo habitual en este tipo de sistemas,
y es limitado por los siguientes umbrales:
(b)Ataque depu
es de balanceo.
S
DH
St = (Ht Bt ) + (1 )Btn
N3
(a)Ataque original.
DA
U inf (t) = p0 K
N3
DA
DA
DH
DA
N5
DA
(c)Intercepci
on del ataque. (d)Respuesta adaptativa.
Fig. 1
Ejemplo de comportamiento del AIS ante un ataque DDoS.
C. Detecci
on de ataques basados en inundaci
on
El an
alisis del volumen de trafico es llevado a cabo a partir de las variaciones en su entrop
a, y a las cotas estableci1
1
das mediante umbrales de prediccion. La entropa es una
medida de variacion para variables cualitativas, definida
como el grado de impredicibilidad de su comportamiento.
Sea la variable X cualitativa con el conjunto de valores
finito x1 , x2 , , xn de probabilidades p1 , p2 , , pn , la
entropa de X se define como:
H(X) =
n
X
i=1
pi loga
n
X
1
pi loga pi
=
pi
i=1
(1)
Dado que se satisface loga b logb x = loga x, entonces

1
1
H(x) = 0 cuando la variable es determinstica. Para la
detecci
on de ataques de inundacion X es definida como
el volumen de trafico entre los nodos A y B, dirigido al
puerto C. La probabilidad P implica que cada pi representa el porcentaje de aparicion de paquetes con un origen,
destino y puerto concretos, en el trafico auditado.
Las reacciones inmunitarias solo deben producirse
cuando se observan fluctuaciones suficientemente representativas. Esto es decidido mediante la estimaci
on de la
entropa en el proximo periodo de observacion, teniendo en
cuenta la serie de entropas observada en los u
ltimos t instantes de tiempo. Por motivos de eficiencia, la predicci
on
se ha llevado a cabo mediante el modelo predictivo propuesto por Holt-Winters [29], que corresponde con la siguiente ecuacion recursiva:
Bt = (Hi StN ) + (1 )(Bt1 + Tt1 )
(2)
Tt = (Bt Bt1 ) + (1 )Tt1
(3)
29
(4)
var(Et )
(5)
var(Et )
(6)
donde Et es el error de predicci

on en t y p0 es la
predicci
on en el la u
ltima observaci
on realizada. El error de predicci
on viene dado por la diferencia entre la
predicci
on y la observaci
on en t. La varianza es calculada
a partir del error de predicci
on en las u
ltimas t observaciones realizadas.
Asimismo, la expresi
on incluye un par
ametro de ajuste
K, el cual permite regular el nivel de restricci
on del sistema. En los agentes DH el par
ametro K toma su valor
por defecto, donde Z 2 . Esto es debido a que son dos intervalos con un margen del tipo 100(1 ). Sin embargo,
como parte de la respuesta inmunitaria adaptativa, los
agentes DA adquieren la capacidad de aumentar su nivel
de restricci
on en funci
on de la actividad detectada en DH .
En este caso, el par
ametro K es definido por la siguiente
expresi
on:
K(t) = Kprev (1
V olactual
)
V olprevio
(7)
Donde Kprev es el par

ametro K anterior, V olprevio el
volumen de tr
afico auditado antes de detectarse el ataque
y V olactual es el volumen de tr
afico auditado durante el
ataque.
n y resultados
IV. Experimentacio
Para evaluar la propuesta se ha desarrollado un simulador capaz de generar diferentes redes y distribuciones
de sensores DH y DA aleatoriamente, en base a los siguientes par
ametros: n
umero de nodos, volumen de tr
afico
legtimo, factor de ramificaci
on, y factor cclico. Los dos
u
ltimos determinan la cantidad de conexiones asociadas a
cada nodo y el n
umero de ciclos de la red cuando se representa como un grafo de dimensiones finitas. Por otro lado
se ha construido un generador de ataques de inundacion.
Dada una red generada con la herramienta previamente
descrita, el simulador elegir
a arbitrariamente el nodo de
origen, el nodo vctima y un puerto. A continuaci
on inyectar
a un volumen de tr
afico arbitrario, teniendo en cuenta
las indicaciones de [30].
Se han generado 220 redes aleatoriamente, y en cada
una de ellas se ha estudiado el comportamiento de ataques
de denegaci
on de servicio de diferentes magnitudes, dirigidos entre cada posible par de nodos de origen y destino.
A continuaci
on se discuten los resultados obtenidos.
JNIC2015

5
0.8
0.8
0.6
0.6
TPR H
TPR A
FPR H
FPR A
0.4
0.2
0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
0.4
0.2
0
Fig. 2
n la localizacio
n de los agentes.
Eficacia en funcio
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Fig. 4
n la congestio
n de la red.
Eficacia en funcio
1
0.8
TPR H
TPR A
0.8
0.6
0.6
0.4
0.4
0.2
0.2
TPR H
TPR A
FPR H
FPR A
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Resp. Innata
Resp. Adaptativa
10 20 30 40 50 60 70 80 90 100
Fig. 5
n la longitud del ataque
Eficacia de la propuesta en funcio
Fig. 3
n la potencia del ataque.
Eficacia en funcio
A. Localizaci
on de sensores
En Fig. 2 se muestra la importancia de la ubicaci
on
de los sensores DH y DA activados a la hora de reconocer con exito la amenaza. El eje Y indican la tasa de
acierto TPR(True Positive Rare) o la tasa de falsos positivos FPR(False Positive Rate), y el eje Y el porcentaje
del recorrido en que se ubica el detector. Cuando los DH
reconocen las amenazas por primera vez, el TPR promedio
es de 0.85 y el FPR es 0.072. No obstante, se observa como
cerca de los extremos la tasa de acierto se aproxima al
100%, mientras que en los puntos equidistantes disminuye
hasta el 70%. Esto es debido a que el ataque tiende a distribuirse, concentrandose en un menor n
umero de canales
al llegar a los extremos. Al activarse la inmunidad adaptativa, el TPR promedio aumenta un 7%, siendo igual a
0.92. La mayor mejora se observa en las distancias intermedias, donde su peor valor es de 0.82, mejorando un 12%.
La implementacion de inmunidad adaptativa apenas tiene
impacto en la FPR. Su valor promedio en DH es de 0.071
y asciende a 0.077 en DA , es decir, solo empeora un 0.6%.
Adem
as depende muy poco de la ubicacion del sensor.
congesti
on total. Esta ha sido ponderada en funci
on del
porcentaje del ancho de banda de la vctima que es capaz de congestionar, independientemente del volumen de
tr
afico legtimo. Cuando el ataque es de potencia mayor
a 0.5, en ambos casos el TPR es pr
acticamente 1. Sin
embargo en el resto de casos se observa una importante
mejora al iniciarse la reacci
on adaptativa. Su incremento
m
as alto es del 26.5% cuando la potencia vara entre el 0.3
y el 0.4.
C. Congesti
on de la red
En Fig. 4 se muestra la capacidad de detecci
on en
funci
on del volumen de tr
afico legtimo que circula por
las redes. Cuando hay poco tr
afico, la estrategia propuesta resulta muy precisa. Los ataques resultan mucho
m
as visibles. Sin embargo cuando la congesti
on es alta,
especialmente a partir del 0.7, la tasa de acierto disminuye, y la tasa de falsos positivos aumenta. La activacion
de la reacci
on adaptativa suaviza este problema. Consigue
incrementar hasta un 13.7% el TPR en el caso de mayor
desnivel (congesti
on entre 0.6 y 0.7) y disminuir el FPR
hasta un 11.4% (congesti
on entre 0.9 y 1).
B. Capacidad de inundaci
on
D. Longitud del ataque
Otro aspecto a considerar es la repercusion de las caractersticas de la red y los ataques. En Fig. 3 se observa la precision del sistema en funcion de la potencia
del ataque, siendo 0 el estado de no congesti
on, y 1 el de
Finalmente queda por determinar la capacidad de mitigaci

on de los ataques. En Fig. 5 se observa la tasa de
ataques iniciados que no han alcanzado su objetivo, en
funci
on del n
umero de conexiones entre nodos que recor-
30
JNIC2015

6
ren. Cuando act

ua u
nicamente la respuesta innata, se ha
bloqueado el 81.4% de los ataques. Sin embargo, la respuesta adaptativa ha sido capaz de evitar el 95.5% de
ellos, es decir, ha mejorado su eficacia un 14.1%. De la
gr
afica tambien se deduce que a mayor n
umero de conexiones, mayor es la probabilidad de exito del ataque.
V. Conclusiones
En este artculo se ha propuesto una nueva estrategia de
defensa frente a ataques de denegacion de servicio basados en inundacion. Para ello se ha emulado el comportamiento de las reacciones inmunitarias de los organismos
vertebrados, por medio del despliegue de un sistema inmunitario artificial. Cada uno de sus agentes ha combinado
sus funciones basicas, con estrategias de procesamiento de
informaci
on propias de la deteccion y mitigaci
on de este
tipo de amenazas; en concreto, mediante el estudio de la
entropa del trafico de la red, y la deteccion de anomalas
capaces de sobrepasar sus umbrales de predicci
on.
El sistema ha sido evaluado en un entorno de experimentacion simulado, que ha implicado diferentes
topologas de red, congestion y ataques. Los resultados han demostrado una importante mejora al considerar
mecanismos de reaccion adaptativos, frente a considerar
s
olo respuestas innatas (de manera similar a las propuestas
convencionales). Las lneas de investigacion futuras estudiar
an su comportamiento en entornos reales, y aplicar
an
diferentes estrategias de modelado del trafico, lo que permitir
a sustituir el parametro de ajuste de la restrictividad
de los sensores DA , por metodos mas precisos.
Agradecimientos
Los autores agradecen el apoyo brindado por el Programa de Financiacion de Grupos de Investigaci
on UCM
validados de la Universidad Complutense de Madrid Banco Santander.
Referencias
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
L. Marinos, A. Sfakianakis, ENISA (2015), Threat Landscape

2014. Available: https://www.enisa.europa.eu/
S.T. Zargar, J. Joshi, D. Tipper, A Survey of Defense Mechanisms Against Distributed Denial of Service (DDoS) Flooding
Attacks, IEEE Communications Surveys & Tutorials, vol. 15,
no. 4, pp. 2046-2069, 2013.
C. Zheng, D.C. Sicker, A survey on biologically inspired algorithms for computer networking, IEEE Communications Surveys & Tutorials, vol. 15, no. 3, pp. 1132-1191, 2013.
N.B.I. Al-Dabagh, I.A. Ali, Design and implementation of artificial immune system for detecting flooding attacks, in Proceedings of the International Conference on High Performance
Computing and Simulation (HPCS), Istanbul, Turkey, 2011,
pp. 381-390.
S. Shin, S. Lee, H. Kim, S. Kim, Advanced probabilistic approach for network intrusion forecasting and detection, Expert
Systems with Applications, vol. 40, no. 1, pp. 315-322, 2013.
S.M. Lee, D.S. Kim, J.H. Lee, J.S. Park, Detection of DDoS
attacks using optimized traffic matrix, Computers & Mathematics with Applications, vol. 63, no. 2, pp. 501-510, 2012.
Y. Chen, X. Ma, X. Wu, A Rank Correlation Based Detection
against Distributed Reflection DoS Attacks, IEEE Communications Letters, vol. 17, no. 5, pp. 1052-1054, 2013.
C. Callegari, S. Giordano, M. Pagano, T. Pepe, WAVECUSUM: improving cusum performance in network anomaly
detection by means of wavelet analysis, Computers & Security, vol. 31, no. 5, pp. 727-735, 2012.
Y. Cai, R.M. Franco, M. Garca-Herranz, Visual latency-based
interactive visualization for digital forensics, Journal of Computational Science, vol. 1, no. 2, pp. 115-120, 2010.
31
[10] P.A.R. Kumar, S. Selvakumar, Detection of distributed denial

of service attacks using an ensemble of adaptive and hybrid
neuro-fuzzy systems, Computer Communications, vol. 36, no.
3, pp. 303-319, 2013.
[11] M.H. Bhuyan, D.K. Bhattacharyya, J.K. Kalita, An empirical
evaluation of information metrics for low-rate and high-rate
DDoS attack detection, Pattern Recognition Letters, vol. 51,
no. 1, pp. 1-7, 2014.
[12] I. Ozcelik, R.R. Brooks, Deceiving entropy based DoS detection, Computers & Security, vol. 48, no. 1, pp. 234-245, 2015.
[13] B.B. Zhu, J. Yan, G. Bao, M. Yang, N. Xu, Captcha as Graphical Passwords-A New Security Primitive Based on Hard AI
Problems, IEEE Transactions on Information Forensics and
Security, vol. 19, no. 6, pp. 891-904, 2014.
[14] K.E. Heckman, M.J. Walsh, F.J. Stech, T.A. OBoyle, S.R.
DiCato, A.F. Herber, Active cyber defense with denial and
deception: A cyber-wargame experiment, Computers & Security, vol. 37, pp. 72-77, 2013.
[15] S. Khanna, S.S. Venkatesh, O. Fatemieh, F. Khan, C.A.
Gunter, Adaptive selective verification: an efficient adaptive
countermeasure to thwart DoS attacks, IEEE/ACM Transactions on Netwowking, vol. 20, no. 3, pp. 715-728, 2012.
[16] N.M. Alenezi, M.J. Reed, Uniform DoS traceback, Computers & Security, vol. 45, no. 1, pp. 17-26, 2014.
[17] A.R. Kiremire, M.R. Brust, V.V. Phoha, Using network motifs
to investigate the influence of network topology on PPM-based
IP traceback schemes, Computer Networks, vol. 72, no. 1, pp.
14-32, 2014.
[18] C.M Ou, Host-based intrusion detection systems adapted from
agent-based artificial immune systems, Neurocomputing, vol.
88, no. 1, pp. 78-86, 2012.
[19] P. Mostardinha, B.F. Faria , A. Z
uquete, F.V. Abreu, A
Negative Selection Approach to Intrusion Detection, in Proc.
11th International Conference on Artificial Immune Systems
(ICARIS), Taormina, Italy, 2012. Lecture Notes in Computer
Science, vol. 7597, pp. 178-190, 2012.
[20] R. Ligeiro, Monitoring applications: An immune inspired algorithm for software-fault detection, Applied Soft Computing,
vol. 24, pp. 1095-1104, 2014.
[21] L.N. Castro, F.J.V. Zuben, Learning and Optimization Using
the Clonal Selection Principle, IEEE Transactions on Evolutionary Computation, vol. 6, no. 3, pp. 239-251, 2002.
[22] K.A. Sheshtawi, H.M. Abdul-Kader, N.A. Ismail, Artificial
Immune Clonal Selection Classification Algorithms for Classifying Malware and Benign Processes Using API Call Sequences,
International Journal of Computer Science and Network Security, vol. 10, no. 4, pp. 31-39, 2010.
[23] N.A. Seresht, R. Azmi, MAIS-IDS: A distributed intrusion
detection system using multi-agent AIS approach, Engineering Applications of Artificial Intelligence, vol. 25, pp. 286-298,
2014.
[24] H. Yang, J. Guo, F. Deng, Collaborative RFID intrusion detection with an artificial immune system, Journal of Intelligent Information Systems, vol. 36, no. 1, pp. 1-26, 2011.
[25] U. Aickelin, P. Bentley, S. Cayzer, J. Kim., J. McLeod, Danger
Theory: The Link between AIS and IDS, in Proc. 2nd International Conference on Artificial Immune Systems (ICARIS),
Edinburgh, UK, 2013. Lecture Notes in Computer Science, vol.
2787, pp. 147-155, 2003.
[26] R. Azmi, B. Pishgoo, SHADuDT:secure hypervisor-based
anomaly detection based on danger theory, Computers & Security, vol. 39, part B, pp. 268-288, 2013.
[27] A. Boukerche, R.B. Machado, K.R.L. Juca, J.B.M. Sobral,
M.S.M.A. Notare, An agent based and biological inspired realtime intrusion detection and security model for computer network operations, International Journal of Computer Communications, vol. 30, pp. 2649-2660, 2007.
[28] B.Chen, Agent-based artificial immune system approach for
adaptive damage detection in monitoring networks, Journal
of Network and Computer Applications, vol. 33, no. 6, pp. 633645, 2010.
[29] S. Gelper, R. Fried, C. Croux, Robust forecasting with exponential and Holt-Winters smoothing, Journal of Forecasting,
vol. 29, no. 3, pp. 285-300, 2010.
[30] S. Bhatia, D. Schmidt, G. Mohay, A. Tickle, A framework
for generating realistic traffic for Distributed Denial-of-Service
attacks and Flash Events, Computers & Security, vol. 40, no.
1, pp. 95-107, 2013.
JNIC2015
La utilizacin de herramientas de monitorizacin de

usuarios como base para el perfilado de identidades
en fuentes abiertas: OSRFramework
Yaiza Rubio y Flix Brezo
yaiza_rv@hotmail.com y felixbrezo@gmail.com
Resumen-Las herramientas para la investigacin sobre perfiles
presentes en la red surgen como resultado de la utilizacin masiva
de la red por parte de los usuarios. Partiendo de la premisa de que
gran parte de los usuarios comparten alias en diferentes
plataformas, OSRFramework es una herramienta de software libre
que integra diferentes utilidades de investigacin en fuentes abiertas
orientadas a la identificacin de usuarios. Su funcionalidad

principal consiste en la posibilidad de realizar bsquedas de
usuarios en ms de 200 plataformas diferentes.
I. INTRODUCCIN
obtencin de atributos y caractersticas asociados a un mismo

perfil que puedan abrir nuevas lneas de investigacin.
En este contexto, el presente documento est estructurado
como sigue. En la Seccin II, se identificarn las necesidades
de investigacin que motivan la creacin de un framework
capaz de recabar informacin de diferentes plataformas. En la
Seccin III, se recoge el proceso de configuracin e instalacin
de la herramienta. En la Seccin IV, se definir un mtodo de
trabajo utilizando las diferentes funcionalidades de dicha
herramienta y definiendo el proceso de integracin del
framework con una herramienta de investigacin como
Maltego. En la Seccin V, se propondrn casos prcticos
concretos de investigacin en los que se explotan las
posibilidades que ofrecen las herramientas incluidas. En la
Seccin VI se definen lneas de trabajo futuras que
complementarn la evolucin de la herramienta. Por ltimo, en
la Seccin VII se detallarn las conclusiones a extraer de este
trabajo relativas a la utilizacin indiscriminada de este tipo de
herramientas y a cmo la informacin personal que los
usuarios exponen en la red es valiosa en s misma para la
adecuacin de ataques contra objetivos concretos como los
propios usuarios.
La proliferacin de herramientas destinadas a la

monitorizacin de la actividad en internet es el resultado de la
aparicin de nuevas formas de utilizar la red en sociedades que
se encuentran cada vez ms interconectadas. Para los grupos
que operan en la red la eleccin de las herramientas es
fundamental de cara a contar con un mayor control sobre su
informacin con una capa adicional de anonimato a un coste
razonable. En este sentido, las organizaciones que centran sus
esfuerzos en realizar acciones de presin harn uso de la web
de superficie (redes sociales, blogs, plataformas de recogida de
firmas, etc.) para garantizar la difusin de su mensaje hacia un
pblico ms amplio [1].
Tanto las compaas tecnolgicas como las fuerzas y cuerpos
de seguridad han identificado un mercado que demanda de
forma reiterada mecanismos que faciliten tanto la deteccin de
posibles actividades fraudulentas como ataques a activos
fsicos o tecnolgicos corporativos. En este sentido, partiendo
de la necesidad de asociar la realizacin de una accin en
internet a una persona concreta para dirimir su atribucin, por
ejemplo, en delitos asociados al blanqueo de capitales
cometidos a travs de internet [2], se hace necesario contar con
herramientas que permitan identificar nuevos usuarios en otras
plataformas potencialmente afines teniendo en cuenta la forma
en que se organizan estas y el uso que se hace de ellas.
Pese a ello, no es corriente encontrar soluciones que
permitan la identificacin de perfiles en mltiples plataformas
o la reduccin de la complejidad de la identificacin de
potenciales usuarios de inters cuando, por un lado, se parte de
una situacin en la que se desconocen los usuarios objeto de
estudio pero, por otro, s se cuenta con cierta informacin sobre
ellos. Por tanto, el objeto de este artculo es la presentacin de
una herramienta que, siguiendo una metodologa de
investigacin en la red, sea capaz de identificar usuarios a
partir de unos requisitos mnimos de informacin para la
Palabras clave- fuentes abiertas, herramientas de investigacin,

perfilado de usuarios, redes sociales
II. CONSIDERACIONES GENERALES

La investigacin sobre cualquier evento que ocurra en
internet obliga a tener una completa comprensin de cmo se
encuentra estructurada. A continuacin, se enumeran una serie
de conceptos generales que servirn para comprender la
estructura de la herramienta propuesta de cara a investigar
perfiles en la red.
A. Naturaleza de la red
Atendiendo a la naturaleza de la conectividad fsica, se
puede hablar de la existencia de dos grandes tipos de redes: de
inters a la hora de monitorizar:
32
JNIC2015
Internet, como conjunto de redes de comunicacin

interconectadas que utilizan la familia de protocolos
TCP/IP, lo cual hace que las redes fsicas heterogneas
que la componen funcionen como una red nica.
Dark internet. Dentro como categora dentro de la que
se agrupan todas aquellas redes fsicas separadas del
interior y que hacen uso de infraestructuras fsicas al
margen del internet convencional y que, por tanto,
requieren de un acceso fsico separado del anterior.
En cualquier caso, en este trabajo se va a hacer referencia a
diversas fuentes de internet que habitualmente se deben
diferenciar entre internet de superficie (o surface) e internet
profunda (o deep).
Surface. Se considera surface a aquel contenido
indexado por los buscadores convencionales, por lo
que se encuentran en esta categora las redes sociales
(exceptuando los perfiles privados), los foros
(exceptuando aquellas partes que establezcan
mecanismos de proteccin como usuario y
contrasea) y las plataformas de pastes (exceptuando
aquellos que se hayan borrado previamente a la
indexacin por parte de los buscadores).
Deep. Es aquel contenido al que no se puede acceder a
travs de un buscador convencional. La ausencia de
contenidos indexados en dichos buscadores puede
venir motivada por la necesidad de autenticar el
acceso mediante un usuario y contrasea o por el uso
de una tecnologa adicional entre otras razones. En
esta ltima categora, se puede diferenciar entre redes
annimas y redes no annimas.
Las redes annimas se utilizan para compartir informacin y
contenidos digitales. En ellas se toman medidas para preservar
el anonimato de las identidades de quienes intercambian
informacin. Este tipo de redes pueden dividirse en redes
(peer-to-peer) P2P, aquellas en las que las relaciones entre
todos sus miembros son de igual a igual, y no P2P, que cuentan
con distintos tipos de nodos en funcin de su funcionalidad. En
este sentido, la monitorizacin de estos contenidos requiere del
desarrollo de interfaces que permitan su consulta, por ejemplo,
a travs de Tor.
Por su parte, las redes P2P se pueden dividir en friend-tofriend (F2F), aquellas redes P2P annimas en donde los nodos
tienen la capacidad de conectarse nicamente con nodos
amigos conocidos y, por tanto, limitando la exposicin de los
mismos y las redes no F2F. Las primeras presentan grandes
inconvenientes para su monitorizacin, dada la necesidad de
que ambos nodos consensuen la comunicacin y requiriendo
contacto directo previo entre sus participantes. Desde el punto
de vista de la monitorizacin, esta circunstancia obligara al
despliegue de capacidades de Human Intelligence (HUMINT)
en el mundo virtual que permitan formalizar estos contactos.
B. Aproximaciones para identificar usuarios
Al margen de la identificacin de usuarios a partir de los

contenidos publicados, para consultar los usuarios registrados
en una plataforma existen dos aproximaciones: una de carcter
proactiva aprovechando las posibilidades que se ofrecen en
muchas de ellas para llevar a cabo una enumeracin de
usuarios (o user enumeration) de la plataforma en cuestin y
otra de carcter reactiva, tratando de identificar si un
determinado perfil existe o no en la plataforma (la
implementada en el framework bajo el nombre de usufy.py).
Dados los requerimientos concretos de la monitorizacin
que se plantean en la red, es necesario definir mtodos
adecuados para su monitorizacin. A continuacin, se recogen
conceptos generales a considerar en la investigacin de
perfiles, las dos aproximaciones diferentes consideradas en el
marco de este trabajo y los tipos de plataformas ya
identificados.
A la hora de identificar un usuario en una plataforma existen
dos aproximaciones: una de carcter proactiva aprovechando la
posibilidad que ofrecen para llevar a cabo una enumeracin de
usuarios (o user enumeration) de la plataforma y otra de
carcter reactiva, tratando de identificar si un determinado
perfil existe o no en la plataforma (en adelante, usufy).
La enumeracin de usuarios se puede realizar para
aquellas plataformas que permiten la consulta de sus
perfiles a partir de ndices consecutivos. El
procedimiento, una vez identificada la direccin URL
en la que se puede llevar a cabo dicha operacin,
consistir en incrementar de forma consecutiva dicho
ndice. En este framework se recoge un script a modo
de prueba de concepto que permite la realizacin de
estas operaciones una vez identificada la direccin
URL de los perfiles1. En cualquier caso, para
optimizar futuras consultas contra el material
recuperado, conforme se vaya incrementando el
tamao de las bases de datos, ms necesario ser
contar con una infraestructura de indexacin de
contenidos como Solr o ElasticSearch.
Para identificar si una plataforma tiene o no usufy es
necesario identificar la URL de la plataforma en la
que se pueden realizar dichas consultas por nombre de
usuario. El procedimiento seguido es el siguiente:
partiendo de una URL genrica de la plataforma
(http://twitter.com/<usufy>) se sustituye la parte
marcada por el nombre del perfil a identificar (por
ejemplo, i3visio) generando como salida la direccin
URL http://twitter.com/i3visio.
Seguidamente, se consulta si se ha producido un error
en la resolucin de la plataforma, buscando dicho
mensaje de error que habitualmente suele ser un aviso
1
Para ejecutar la prueba de concepto utilizando algunas de las plataformas
ya
identificadas
por
los
autores
en
el
fichero
osrframework/util/enumeration_config.txt. Por ejemplo, para ejecutarlo sobre
la plataforma de stackoverflow se puede realizar: python enumeration.py p
stackoverflow.
33
JNIC2015
de que el perfil no existe o un 404. La ventaja que

ofrece esta aproximacin es que, como se ver ms
adelante, la creacin de mdulos que consulten en
nuevas plataformas no es compleja.
Adems, para agilizar el trmite, en usufy.py se cuenta
con una opcin2 que, a partir de un dominio y en base
a las frmulas ms empleadas en otras plataformas, se
comprueba si existe o no la posibilidad de generar una
URL vlida a partir de un alias.
En ambos casos, se podr procesar cada perfil para la
extraccin de atributos concretos de la pgina, incluso en
plataformas y otros foros que no cuentan con API de consulta,
de los que se podr extraer con expresiones regulares algunos
atributos de cada perfil. Como se ha visto, cada aproximacin
tiene sus ventajas e inconvenientes tal y como se recoge en la
Tabla I.
Tabla I. Ventajas e inconvenientes de las dos aproximaciones para investigar
perfiles de usuario en la red.
Ventajas
- Bsqueda avanzada sobre
miles de perfiles
Inconvenientes
- Importante capacidad de
almacenamiento
- Tiempo requerido para
enumeration
- Seguimiento de la actividad
realizar un ciclo completo de
del perfil hacia atrs
monitorizacin
- Cliente ligero
- Sin posibilidad de hacer
- Almacenaje requerido
Usufy
seguimiento previo a la
limitado
investigacin
- Resultados inmediatos
User
III. INSTALACIN Y CONFIGURACIN DE LA HERRAMIENTA

Para poder utilizar la herramienta es necesario contar con la
versin de Python 2.7 instalada en el equipo 3. Opcionalmente,
si se quiere contar con la interfaz grfica de Maltego ser
necesario contar con dicha plataforma. La versin Community
se puede descargar desde la pgina de Paterva [3]. El resto de
dependencias sern gestionadas por el propio script de
instalacin.
A. Instalacin de la aplicacin
La herramienta puede descargarse desde la pgina del
proyecto en Github [4]. Tras descomprimir el fichero, la
instalacin tanto en sistemas Windows como en Linux requiere
la ejecucin de los siguientes comandos desde la carpeta raz
del proyecto:
python setup.py build
python setup.py install
algunos sistemas puede ser necesario, bien incluir entre las

variables de entorno la ruta a un intrprete de Python 2.7, bien
establecer un enlace simblico a la ubicacin real de la
instalacin de Python 2.7 o bien ejecutar dichos comandos
como python2.7 en lugar de solamente como python. A
efectos de este documento, se asumir en adelante una
instalacin de Python que reconozca por defecto la versin 2.7.
Tras descomprimir la carpeta y realizar la instalacin, se
puede comprobar que esta se ha hecho correctamente
ejecutando:
python c import osrframework
Si no aparece ningn error, las aplicaciones y libreras

contenidas en el framework podrn ser utilizadas tanto desde
otros programas como dentro de la carpeta osrframework. La
estructura de dicha carpeta es la siguiente:
patterns. Directorio que recoge los mdulos de
expresiones regulares utilizados por la aplicacin de
extraccin de entidades entify.py.
thirdparties. Directorio que recoge las llamadas a
aplicaciones de terceros. En dicha carpeta se recogen
tambin scripts que pueden ejecutarse de forma
independiente y que realizan consultas sobre dichas
API.
transforms. Directorio en el que se definen las
transformadas de Maltego y los ficheros de
configuracin necesarios para su ejecucin.
utils. Directorio en la que se encuentran distintas
mdulos necesarios para el resto de aplicaciones.
wrappers. Directorio en la que se encuentran las clases
en las que se definen las operaciones de bsqueda en
las plataformas.
entify.py. Aplicacin para identificar entidades con
expresiones regulares en texto y archivos.
mailfy.py. Aplicacin para verificar la existencia o no
de un correo electrnico.
phonefy.py. Aplicacin para identificar la vinculacin
de un nmero de telfono con llamadas de spam
telefnico.
searchfy.py. Aplicacin para realizar bsquedas en
distintas plataformas, tanto de la web de superficie
como de redes annimas.
usufy.py. Aplicacin para la identificacin de la
existencia de usuarios.
B. Creacin de nuevos wrappers
Se asumir en todos los casos de este documento que el

comando python asume un intrprete de Python 2.7. En
2
Ejemplo de ejecucin: python usufy.py fuzz ejemplo.txt. En donde
ejemplo.txt ser un archivo en el que la primera columna (separadas entre s
por un tabulador) de cada fila ser el dominio a analizar y la segunda el alias de
un usuario que se sabe que existe en la plataforma.
3
Las versiones de Python 3.0 y posteriores no son vlidas por cuestiones de
incompatibilidad de algunas libreras.
El proceso de creacin de nuevos wrappers para la

herramienta de usufy.py se enumera a continuacin:
Paso 1. Identificar la direccin URL genrica de la
plataforma que se quiere aadir y si requiere de
credenciales o no para realizar la consulta.
Paso 2. Identificar el mensaje de error que aparece
cuando el usuario no existe. Este texto ser el que se trate
34
JNIC2015
de identificar en el cdigo fuente de la pgina para

confirmar la no existencia del perfil.
Paso 3. [Opcional] Identificar las expresiones regulares
con las que se extraer la informacin de los perfiles.
Paso 4. Copiar el archivo __demo.py.sample de la carpeta
osrframework/wrappers y cambiar el nombre y la
extensin del archivo a .py.
Paso 5. Editar al menos las siguientes lneas si se quiere
crear un wrapper para usufy:
a. Lneas 32, 34 y 40. Actualizacin del nombre de
la plataforma.
b. Lnea 41. Modificacin de los tags de la
plataforma. Esto permitir la realizacin de
consultas en plataformas etiquetadas con ellos.
c. Lnea 48. Puesta a True del valor
self.isValidMode["usufy"].
d. Lnea 57. Descomentar la lnea (eliminando el
# inicial) y modificar la URL base en la que se
encuentran los perfiles. Es importante que la
cadena de texto que se introduzca contenga el
tag <usufy> en el lugar en el que se colocar el
usuario de la consulta. Habitualmente, se coloca
al final de la direccin URL, pero no
necesariamente ha de ser as.
e. Lnea 65. Descomentar y poner a True si procede
del valor self.needsCredentials["usufy"].
f. Lnea 75. [Opcional] Por cuestiones de
rendimiento, se pueden determinar los caracteres
que puede contener la direccin URL utilizada
para obviar, por ejemplo, la utilizacin de alias
en Twitter que tengan el carcter .. Para ello
habr que definir una expresin regular vlida y
descomentar dicha lnea. En caso de que no se
sepa, puede dejarse como tal lo que aceptar
cualquier tipo de alias realizando la peticin en
lugar de acelerar el proceso descartndolo de
antemano.
g. Lnea 84. Descomentar e introducir en la lista la
cadena de texto que aparece cuando una pgina
muestra un aviso de que la pgina solicitada no
existe. Este texto debe venir incluido como tal en
el .html que devuelve la pgina, con lo que es
necesario comprobar que el contenido aparece en
el cdigo fuente de las pginas de error. Por
ejemplo:
self.notFoundText["usufy"] = [Error 404]
h. Lnea 98 y siguientes. [Opcional] Incluir en este

apartado los campos a extraer de dicha pgina.
Es una tarea que es recomendable dejar para ms
adelante una vez que se confirme el
funcionamiento del wrapper.
Paso 6. Aadir en el archivo platform_selection.py de la

carpeta osrframework/utils el mdulo recin creado en
orden alfabtico preferiblemente.
Paso 7. Reinstalar la aplicacin desde la carpeta principal
y confirmar que el mdulo est operativo tanto con
perfiles que existen como con perfiles que no existen.
Dado que algunas plataformas requieren de autenticacin
previa del usuario, usufy.py contempla la posibilidad de que el
investigador se autentique en ellas con un perfil propio para
realizar las peticiones y recuperar el contenido que, de otra
manera, sera inaccesible. En los casos que proceda, se adirn
las credenciales en el fichero config_credentials.py de la
carpeta osrframework/utils.
Por su parte, la configuracin de los wrappers para hacerlos
compatibles con la herramienta de searchfy.py es muy similar.
En ese caso, ser necesario modificar algunos parmetros como
la direccin URL de la consulta y dejar por defecto el valor de
su valor self.notFoundText:
self.notFoundText["searchfy"] = []
Una aproximacin de estas caractersticas facilitar la
inclusin de nuevas funcionalidades futuras sobre los wrappers
ya creados basadas en la verificacin de la informacin
retornada tras una consulta a direcciones URL propias de cada
plataforma.
C. Modelo de datos
Este framework de investigacin est compuesto por
herramientas de desarrollo propio que adems interactan con
API de terceros y otras herramientas de software libre para
agregar contenidos. Para realizar esta comunicacin se ha
propuesto un modelo de datos basado en la estructura de un
JSON (principalmente, por la facilidad con la que estas
estructuras pueden ser serializadas y accedidas) y que hace que
cada objeto est compuesto por tres campos:
type. Hace referencia al tipo de objeto del que se trata.
Para evitar problemas de incompatibilidades con
entidades creadas por otros equipos de trabajo, todos
los tipos de datos de este framework empiezan con la
etiqueta i3visio.<tipo>.
value. Contiene el valor del campo en cuestin, por
ejemplo un nombre de dominio o un alias.
attributes. Es una lista de objetos creados de igual
manera con campos type, value y attributes lo que
hace posible que un objeto complemente a otro.
IV. METODOLOGA DE TRABAJO CON EL FRAMEWORK
En esta seccin se recoge la metodologa de trabajo
propuesta para trabajar con las diferentes utilidades incluidas
en el framework. En primer lugar, se partir de la generacin
de alias candidatos a partir de la informacin de contexto
conocida, se proceder a la identificacin de dichos alias en
distintas redes sociales y, en caso de no obtener resultados
satisfactorios, se propondr la utilizacin de aproximaciones
35
JNIC2015
ms amplias. Posteriormente, se propondr una primera

aproximacin de anlisis de la informacin recuperada y se
integrar dicha informacin con la extrada de otras
herramientas utilizando como elemento de representacin una
herramienta como Maltego.
Los resultados obtenidos generan entidades del mismo tipo que

las entidades de usufy.py que se pueden integrar en los mismos
ficheros de salida y pueden venir determinados por la bsqueda
de nombres y apellidos junto con otros trminos.
A. Generacin de alias candidatos a partir de informacin conocida
Al margen de las capacidades de visualizacin de

informacin implementadas a partir de transformadas de
Maltego y que se comentan en el apartado G de esta seccin, se
cuenta con la posibilidad de, adems de visualizar los
resultados por consola, exportar los resultados obtenidos en
diferentes formatos.
Formato JSON. Utilizado ampliamente en los
formatos de respuesta a llamadas a API, es til para la
representacin de informacin estructurada y,
especialmente, por la facilidad de mapear la
informacin en estructuras de diccionario en
diferentes lenguajes de programacin.
Formatos tabulares: CSV, ODS, XLS. La utilizacin
de estos formatos viene dada por la facilidad que
ofrecen los paquetes ofimticos para interactuar con
formatos tabulares en forma de tablas dinmicas y
filtros. Esta sencillez permitir al analista la
realizacin de un filtrado de informacin interactivo
empleando estas herramientas as como la agrupacin
de los datos obtenidos entre otras operaciones.
En determinadas situaciones, puede no contarse con un alias

concreto al disponer solamente de algunos datos del perfil
objeto de estudio. Para dichos casos, se ha configurado un
script que genera una lista de posibles alias a partir de la
informacin suministrada por el usuario y empleando una serie
de transformaciones observadas en el proceso de generacin de
nuevos alias. En este caso, para lanzar su ejecucin en modo
interactivo bastara con escribir:
python alias_generator.py
Este modo de empleo preguntar a continuacin datos del

usuario objeto de estudio y almacenar los resultados en un
fichero cuya localizacin se puede especificar utilizando el
parmetro opcional -o.
B. Identificar la existencia de otros perfiles con el mismo alias
En el caso de disponer de un alias o lista de ellos , se puede
consultar la existencia de perfiles que los utilicen en todas las
plataformas integradas. Se puede utilizar para ello la
herramienta usufy.py de diferentes formas. Existen diferentes
formas de interactuar con la misma, algunas de las cuales,
aunque no de forma extensiva se recogen a continuacin:
Para identificar la utilizacin del usuario test_user en
todas las plataformas:
python usufy.py n test_user p all
Para identificar la utilizacin de dos o ms usuarios se

puede configurar a travs de la misma lnea de
comandos:
python usufy.py n test_user1 test_user2 p all
Para identificar usuarios incluidos en un fichero de

texto:
python usufy.py l fichero_nicks.txt p all
Adems, la aplicacin concibe la posibilidad de configurar

opciones de exportacin, seleccin de bsquedas en
plataformas concretas, eleccin por tags o configuracin del
nmero de hilos lanzados de forma simultnea.
C. Identificar la existencia de perfiles asociados a determinadas
bsquedas
Utilizando el script searchfy.py, se pueden realizar consultas
contra los servicios de bsqueda de usuarios de diferentes
plataformas. Esta funcionalidad extiende la capacidad de
usufy.py al permitir aglutinar la existencia de perfiles en
diferentes buscadores bajo una misma consulta. Un ejemplo de
ejecucin sera el siguiente:
python searchfy.py p all -q <name> <surname>
D. Exportacin y anlisis preliminar de la informacin obtenida
E. Identificacin de informacin adicional de entidades presentes en

recursos web
Paralelamente a las capacidades de deteccin, en el
framework se han desarrollado aplicaciones destinadas a la
identificacin de informacin adicional que complemente los
datos recabados de los perfiles.
Utilizando el script entify.py, se ha facilitado la
extraccin de entidades a partir de expresiones
regulares conocidas. Los mdulos generados se
incluyen en la carpeta osrframework/patterns. Un
ejemplo de ejecucin sera el siguiente:
python entify.py r all w http://i3visio.com
Aunque se pueden configurar nuevas expresiones tanto por

lnea de comandos como a modo de extensiones, el framework
trae consigo definidas las, siguientes expresiones regulares a
extraer integradas: bitcoinaddress, dni, dogecoinaddress, email,
ipv4, litecoinaddress, md5, namecoinaddress, peercoinaddress,
sha1, sha256 y uri.
Identificar la existencia de un correo electrnico
asociado a un alias o un correo electrnico a partir del
script mailfy.py4. Existe la posibilidad de verificar la
existencia de un determinado alias en distintas
plataformas, as como verificar la existencia o no de
un correo dado.
4
Por razones derivadas de la utilizacin de la librera de terceros pythonemailahoy [5], la funcionalidad de esta aplicacin solamente se ha podido
confirmar en sistemas bajo Linux.
36
JNIC2015
python mailfy.py n usuario1
Identificar posibles casos de spam telefnico

asociados a un nmero de telfono empleando la
aplicacin phonefy.py. La filosofa seguida es similar
a la de usufy.py. Los resultados retornados en este
caso devolvern incidencias asociadas a prcticas
abusivas en diferentes fuentes.
python phonefy.py n 910000000 920000000
F. Obtencin de informacin adicional consultando API de terceros

Con la informacin consultada en pasos anteriores, se
pueden establecer relaciones a partir de consultas realizadas
contra servicios de terceros. Actualmente, en la herramienta se
puede buscar informacin sobre cuentas de Bitcoin en la
cadena de bloques de blockchain.info, consultar si un correo
electrnico ha sido filtrado en haveibeenpwned.com, verificar
la existencia de informacin telefnica en internet, consultar la
API gratuita de ip-api.com sobre geoubicacin de direcciones
IP y dominios, consultar la informacin de md5crack.com (si
se ha configurado el acceso a travs de config_api_keys.py en
la carpeta osrframework/utils) y consultar la existencia de
perfiles asociados a personas, emails o usuarios de Skype si se
cuenta con un cliente autenticado (funcionalidades incluidas
tambin incluidas en searchfy.py y usufy.py). Estos scripts que
hacen uso de servicios de terceros se encuentran en el
directorio osrframework/thirdparties.
G. Visualizacin de transformadas a travs de Maltego
Pese a que cada una de las herramientas pueden utilizarse
por separado, existe la posibilidad de consumir los resultados a
travs de transformadas de Maltego. Opcionalmente, se pueden
generar los ficheros de configuracin que podrn importarse
desde Maltego y que crearn los enlaces a las diferentes
transformadas y entidades que se pueden utilizar en dicha
herramienta.
python configure_maltego.py
Esta operacin generar un fichero .mtz de configuracin de

Maltego en la carpeta osrframework/transforms/lib/ y que ser
necesario importar desde la plataforma. Con ello se generan no
solamente las entidades de Maltego sobre las que las
transformadas se podrn utilizar.
Las transformadas son procedimientos que reciben como
entrada una entidad de un tipo determinado (un alias, un email,
unas coordenadas, una direccin IP, etc.) y que generan como
salida otra entidad o un conjunto de ellas relacionadas con la
original visualizando la relacin a travs de una interfaz
grfica.
En el caso de OSRFramework, se han aprovechado las
posibilidades de configurar herencia entre entidades para
establecer una jerarqua de entidades que facilite la gestin de
las transformadas. De esta manera, cualquier transformada que
permita recibir un elemento de un tipo determinado, tambin
podr ser ejecutada sobre un tipo de entidad hijo del anterior.
Esta herramienta facilita el establecimiento de relaciones

visuales entre entidades utilizando cualquier lenguaje de
programacin que genere salidas en un formato .xml
comprensible por ella. En este caso, para implementar dicha
compatibilidad se ha empleado tambin cdigo Python.
V. CASOS DE ESTUDIO
En base a la informacin facilitada por las diferentes
herramientas facilitadas dentro del framework, se plantean los
siguientes casos de estudio para los siguientes pblicos
objetivos:
Para aquellas fuerzas y cuerpos de seguridad
dedicadas a la investigacin de usuarios radicalizados
que pudieran estar utilizando las oportunidades que
ofrecen las redes sociales tanto para comunicarse
como publicitar su actividad y captar ms personas.
Para aquellos gabinetes de comunicacin de las
empresas dedicados a proteger la imagen de marca de
la empresa. Con este framework podrn identificar
aquellos perfiles destinados a la suplantacin de su
identidad o a la utilizacin no autorizada de sus
nombres corporativos en diferentes plataformas.
Para los departamentos de Recursos Humanos de las
empresas que tengan el inters de contextualizar la
actividad en red de los candidatos a incorporarse a una
empresa.
Para los auditores de seguridad que deseen medir el
nivel de concienciacin en materia de ciberseguridad
de los empleados de una empresa. Este framework les
sirvir para obtener informacin de sus vctimas en
numerosas plataformas para realizar los ataques.
En cualquier caso, las capacidades de la herramienta pueden
ser ampliadas tanto para ampliar las posibilidades de xito en
investigaciones planteadas en los casos anteriores como para
proponer otros nuevos en funcin de la naturaleza de las
fuentes que sean incorporadas a herramientas como usufy.py o
searchfy.py.
VI. LNEAS DE TRABAJO FUTURAS
Como herramienta de software libre bajo licencia GPLv3+
[6], es una herramienta en continuo desarrollo susceptible de
seguir ampliando capacidades en funcin de las necesidades de
desarrolladores actuales y futuros. En cualquier caso, hay una
serie de lneas de accin que quedan ya definidas por las
necesidades actuales:Integracin de nuevas plataformas para la
identificacin de usuarios. Dada La inclusin de nuevos
wrappers no es costosa aunque s requerira de un
mantenimiento, ya que la actualizacin de elementos de la
pgina puede derivar en la identificacin incorrecta de nuevos
perfiles.
Extraccin de campos de cada una de las plataformas
identificadas empleando expresiones regulares, de
modo que puedan ser correlados con parmetros de
otras plataformas. El framework en su versin v0.9.0
37
JNIC2015
no cuenta con una integracin completa de todos los

mtodos de extraccin de campos. Sin embargo, el
proceso de extraccin de campos utilizando
expresiones regulares y su posterior integracin en los
wrappers ha sido igualmente considerado de cara a
dotar en futuros versiones de cierta flexibilidad a la
plataforma.
Ampliacin de las capacidades para la realizacin de
bsquedas dentro de las plataformas empleando
searchfy.py. En la versin v0.9.0, solamente est
integrada la URL de consulta de Twitter, Facebook y
otras plataformas que cuentan con buscadores de
perfiles concretos. pero la lgica interna ha tenido en
cuenta la posibilidad de incluir nuevos wrappers de
forma flexible.
Integracin de nuevas API de terceros que permitan el
enriquecimiento de la informacin identificada con
bases de datos adicionales adecuadas al modelo de
datos propuesto por el framework. Este proceso de
integracin ms all de la realizacin de la consulta,
conlleva la adecuacin de los tipos de datos recibidos
al modelo normalizado utilizado en el resto de
aplicaciones.
Adicin de nuevas transformadas y formas de
representacin de la informacin tanto si son a travs
de Maltego como de otras herramientas. Los autores
son conscientes de que una parte importante de todo
proceso de investigacin tiene que permitir la
visualizacin lo ms clara posible de los resultados de
cara al establecimiento de relaciones y a la
presentacin de la informacin.
La informacin obtenida en los pasos anteriores es til
de cara a la mejora de la eficacia de las tcnicas
ofensivas
convencionales,
integrndola
con
parmetros que personalizan dichos ataques para cada
usuario. Una de las lneas de trabajo concibe la
integracin de las entidades recuperadas en un
escenario de explotacin que hace uso de dicha
informacin de una forma que no necesariamente
requiera conocimientos tcnicos avanzados para la
ejecucin de los ataques. En este sentido, el aterrizaje
de propuestas concretas para la utilizacin de dicha
informacin en ataques de ingeniera social y spear
phishing contra usuarios es una lnea de trabajo a
considerar.
Hasta el momento, estas tareas son llevadas a cabo por los
autores quienes estn al tanto de su mantenimiento, pero una
comunidad de desarrolladores ms amplia podra dotar de
tiempos de respuesta ms cortos ante modificaciones en las
plataformas, errores, incidencias y otras mejoras susceptibles
de ampliar las funcionalidades del framework.
VII. CONCLUSIONES
Las unidades de inteligencia necesitan herramientas que les
permitan identificar de forma automatizada la creacin de
ciertos usuarios en plataformas de internet de cara a poder
atribuir una accin que, o bien ha tenido lugar en la red, o bien
ha tenido ramificaciones que derivan en ella. Sin embargo, la
ausencia de soluciones que permitan satisfacer este tipo de
requerimientos de informacin es un problema de cara a
resolver cuestiones asociadas a la atribucin.
Por este motivo, las herramientas necesitan ser modulares
para poder integrar sin demasiado esfuerzo y con suficiente
flexibilidad nuevas fuentes de inters de cara a una
monitorizacin automtica de lo que est ocurriendo en foros y
plataformas sobre los que se tiene un inters concreto. Dadas
estas necesidades, se ha diseado una herramienta de software
libre que permite identificar usuarios y perfiles acordes a unos
requisitos previos en diferentes tipos de sitios de internet
permitiendo a los analistas la creacin de nuevos wrappers en
lapsos de tiempo lo ms reducidos posibles.
AGRADECIMIENTOS
Agradecemos a los miembros de las Fuerzas y Cuerpos de
Seguridad del Estado, a Thiber, The Cybersecurity Think Tank,
a ISACA y a otras personas que a ttulo personal han facilitado
recomendaciones y comentarios, colaborando en la maduracin
y desarrollo de este proyecto.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
38
F. Brezo Fernndez y Y. Rubio Viuela, Herramientas de apoyo a la

infraestructura tecnolgica de los grupos organizados que operan en la
red, Cuad. Guard. Civ., vol. 50, pp. 27-47, feb. 2015.
Y. Rubio Viuela y F. Brezo Fernndez, Futuras lneas de trabajo para la
prevencin de blanqueo de capitales en las plataformas de juego en
lnea, Doc-ISIe, ene. 2013.
Paterva, Maltego Chlorine Community Edition. 2015.
F. Brezo Fernndez y Y. Rubio Viuela, OSRFramework. i3visio, 2014.
V. Neekman, python-emailahoy. 2012.
Free Software Foundation (FSF), GNU General Public License v3.0.
29-jun-2007.
JNIC2015
Neural Networks applied to the learning process of

Automated Intrusion Response systems
Pilar Holgado, Vctor A. Villagra
Departamento de Ingeniera y Sistemas Telemticos, Universidad Politcnica de Madrid Avenida Complutense, 30, 28040,
Madrid
pilarholgado@dit.upm.es, villagra@dit.upm.es
Abstract- The architecture for an Automated Intrusion
Response System (AIRS) has been proposed in the RECLAMO
project. This system infers the most appropriate response for a
given attack, taking into account the attack type, context
information, and the trust of reports from IDSs. Also, it is
necessary to evaluate the result of previous responses, in order to
get feedback for following inferences. This paper defines an
algorithm to determine the level of success of the inferred
response. The objective is the design of a system with adaptive
and self-learning capabilities. Neural Networks are able to
provide machine learning in order to get responses classification.
I.
INTRODUCTION
Security is an important issue for any corporation. They have

to keep their systems safe from external attacks to maintain the
service levels. Also, they must provide to costumers inside
information and correct operation of applications.
As the number of security incidents increases, becoming
more sophisticated and widespread [1], Intrusion Detection
Systems (IDSs) [2] have evolved rapidly and there are now
very mature tools based on different paradigms (statistical
anomaly-based [3], signature-based and hybrids [4]) with a
high level of reliability. IPSs (Intrusion Prevention Systems)
have also been developed by combining IDS with a basic
reactive response, such as resetting a connection. IRSs
(Intrusion Response Systems) leverage the concept of IPSs and
provide the means to achieve specific responses according to
some predefined rules.
Nowadays, IRSs are playing an important role in the security
architecture. These systems mitigate the impact of attacks in
order to keep integrity, confidentiality and availability of the
resources. Automated Intrusion Response Systems (AIRS)
provide the best possible defense, as well as shortening or
eliminating the delay before administrators come into play.
AIRSs are security technologies with the goal of choosing
and triggering automated responses against intrusions detected
by IDSs, in order to mitigate them or reduce their impact [5].
Metrics are defined to measure different parameters
necessary for response selection, such as the IDS confidence,
the network activity level, the reliability of intrusion reports,
and the importance of network components. Also, it is very
relevant taking into account the complexity, severity, cost and
efficiency of responses.
Current AIRSs have a fixed approach to response metrics, so

that the metric cannot be dynamically chosen. We propose a
security architecture to be able to dynamically select the most
appropriate response. It takes into account factors such as the
systems context, cost of responses, importance of resources,
and efficiency of responses.
In this scope, the RECLAMO project (Virtual and
Collaborative Honeynets based on Trust Management and
Autonomous Systems applied to Intrusion Management), an
R&D project funded by the Spanish Ministry of Science and
Innovation, defines an AIRS able to dynamically interpret
metrics. In particular, it is achieved with an adaptive
autonomous system based on assessment of the harm caused
for the intrusion and the cost of the responses.
The autonomous system is developed based on information
formal models defined by ontologies [6]. It is used to represent
intrusion information, parameters of self-evaluation,
confidence and reputation of IDSs, and others. The security
metrics use this information to infer the most appropriate
response. These metrics are represented in the formal language
SWRL (Semantic Web Rule Language) [7].
IDMEF-based Ontologies (Intrusion Detection Message
Exchange Format) [8] are used to homogenize information.
IDMEF format provides a common language to generate alerts
about suspicious events and are stored in Ontology classes [9].
The Ontology have been defined using OWL (Web Ontology
Language) [10]. It takes advantages of Semantic Web, such as
information inference.
Our goal is to analyze the response efficiency triggered after
the arrival of an intrusion. Moreover, we want the AIRS to
automatically learn from previous responses. Specifically, we
propose the use of Neural Networks for this task.
Artificial Neural Networks are a branch of Artificial
Intelligence called Machine Learning. In this group, there are a
lot of learning techniques [11]. The purpose of our algorithm is
to classify the success of the triggered response. Thus, the
AIRS is able to accomplish a self-learning process through a
response rate for future incidences of same kind.
The remainder of this paper is organized as follows. Section
II outlines the current state of the art in evaluation response and
Neural Network. The architecture of the AIRS is presented in
section III. Section IV gives an overview of the inference
process of the response system. The Neural Network proposed
is shown in section V along with its topology and parameters.
39
JNIC2015
The mathematical algorithm of artificial neural network is

detailed in section VI. Section VII explains how to calculate
the response efficiency and finally, conclusion and future
works are included in section VIII.
II.
RELATED WORKS
Nowadays, Automatic Learning is a key concept in the

prevention, detection and response systems against intrusions.
In this section we show some current research in response
effectiveness.
MAIM [12] is an adaptive intrusion response system based
in artificial immune. This approach implements a policy
according to global risk, rather than focusing on individual
attacks. Like us, they use a bio-inspired algorithm. Specifically
they are based on the immune system. They learn about the
dangerous states of the network to detect false positives. Then
a more or less strict response to an attack based on predefined
policies is triggered. In contrast, we use bio-inspired learning
for assessment of triggered response to a given attack. In
addition, we perform context analysis for false positives
detection and we launched a more or less strict response based
on the attack and response costs in terms of the significance of
the assets.
In [13], multi-step attacks are mitigated through several
executions of responses sets. At the end of each response set, a
mechanism that measures the effectiveness of such responses is
launched. In particular, the online risk assessment measures the
risk index of an applied round of responses instead of one
applied response. This affects the order in which the responses
are triggered within the set in a determinate level. In our case,
the measurement of response effectiveness is entirely
individual based on system and network contexts.
COSIRS [14] is based in three factors for response
assessment: cost of intrusion damage, cost of automatic
response and operational cost. In contrast with the system
proposed in this paper, they have not taken into account the
effectiveness against the attack in progress. That is, whether
the selected response has been successful against intrusion at
this time. Moreover, we have also taken into account in our
metrics the intrusion cost, response cost and deployment cost
[18].
Also, neural networks have been used in network security,
specifically, there are approaches using supervised and
unsupervised algorithms in intrusion detection systems. For
example, [15] and [16] use Backpropagation algorithm for
IDSs.
III.
Fig. 1. Architecture of AIRS based Ontology
The AIRS receives a set of inputs including the intrusion

reports, context information, policies of security metrics and
intrusion response ontology. The policies specify different
metrics that will be chosen depending on the context and type
of intrusion.
The Reasoner runs inference process to choose the best
response based in other modules (Policies, Alerts Receiver,
Context Receiver and Intrusion Response Ontology). OWL is
used to define all the information of the response process.
The Intrusion Response Ontology defines the concepts and
relationships needed in the autonomous system. The ontology
is based on the IDMEF structure including classes and
properties. There are two main classes related with the
evaluation system: Response and Result. Each of these classes
have properties related with this objective. The Response class
has two properties associated, executionTimes and
sucessFactor. responseEfficiency is the property included in
the Result class. They are defined in section VII.
The Intrusion Response Evaluation module evaluates the
responses triggered by the AIRS and is the scope of the main
contribution of this paper. We propose to get response
efficiency evaluation by using a pre-trained neural network.
IV.
AIRS INFERENCE PROCESS
The response efficiency is an essential factor to achieve an

adaptive AIRS. This factor is used in the inference process that
performs the AIRS reasoning to select the best response.
Furthermore, the inference is based on metrics that are defined
and analyzed in [18].
Inference process has the following steps:
ARCHITECTURE
Fig. 1 represents the modules of AIRS proposed in [17]. The

goal of this architecture is to choose the optimal response of a
set of available responses.
40
1.
2.
Collecting information from intrusion when it arrives:

System context, network context and reports from
IDSs.
Inference of a recommended set of responses:
a. If the intrusion is similar to a previous one,
the previously selected response is executed
if the proposed neural network algorithm
indicated that this response was satisfactory.
b. In other case, recommended responses are
inferred based on polices, metrics, intrusion
type and context parameters.
JNIC2015
3.
real values and not using thresholds, so that after calculating

the total satisfaction of the response, the AIRS makes the
decision of whether or not the response is good enough.
Optimal response according to the importance of the

asset committed is selected. For significant and
critical assets, we consider the response efficiency
measured with the values given by neural network in
previous executions of the response.
V. NEURAL NETWORK
Artificial Neural Networks are interconnected networks in

parallel with a hierarchical organization. These Neural
Networks attempt to interact with real world objects in the
same ways as nervous system does [19].
Neurons are interconnected by their synapses, allowing
transmission of information. The connections are not all equal,
A. Topology
The generic topology of a multi-layer neural network is
represented in Fig. 2. Neural Networks always have an input
layer and an output layer with one or more neurons per layer.
In this figure, the input layer has five neurons, taking into
account the bias neuron and the output layer has one neuron.
The subsection B explains the input layer for our goal. The
output layer has one neuron to represent response efficiency.
Furthermore, the number of hidden layers and neurons should
be chosen considering the total number of neurons, the
generalization error and the overfitting, as explained below.
The relationship between number of parameters and patterns
must be within 10% or 20% so that we need enough patterns
for generalization. Therefore, we must take into account this
relationship to select the number of neurons in the hidden layer
(or several hidden layers):
-
so you have to assign weights to the connections, (Wi,j,k).

Fig. 2. Multi-layer topology of Artificial Neural Networks
The weights obtained after the learning phase determine the

network output so they become the memory of neural
networks.
Neural networks are particularly useful to solve problems
that cannot be expressed as step by step problems, such as
pattern recognition and classification. In our case, it will be
used for intrusions response classification.
In particular, a Backpropagation algorithm is used to
evaluate the response selected by the AIRS. This algorithm
solves our problem because it determines the satisfaction of the
response for any system or intrusion.
Moreover, we propose the use of a Backpropagation
algorithm, as it is possible to have a training set. Supervised
learning provides the following benefits:
-
The network converges

unsupervised algorithm.
faster
than
using
an
Learning is based on previous observations collected

by a set of instances classified during experimentation
on a test system.
A trained neural network takes input samples and sorts them

into groups. These can be fuzzy, i.e. the boundaries are not
clearly defined, or with defined borders if thresholds are
selected. The proposed system is evaluating the response with
Few neurons in the hidden layer will lead to higher

training and generalization error due to underfitting.
In contrast, if there are many neurons in the hidden
layer then a low training error is obtained, but it has a
high generalization error due to overfitting.
The number of hidden layers should be taken in account,

since increasing the layers number can greatly increase the
number of parameters. In addition, most problems can be
solved optimally with one or two hidden layers.
Thus normally, the optimal neurons number in the hidden
layer is 2/3 of total neurons corresponding to sum of neurons in
both input and output layers.
The implementation of a Neural Network is parameterized in
numbers of neurons and layers to find the best topology. This
analysis will be realized in an initial training phase.
B. Input parameters
The input parameters could be the system and network
context, but normal context depends on the device or system.
Therefore, the selected input parameters correspond to the
anomaly degree of system and network context. This allows
the algorithm to be independent and it can be installed on all
hosts. Anomaly degree corresponds to system and network
context after executing a response compared to normal
context. Context Anomaly Degree is calculated by entropy
variance based on Shannons Information Theory.
The context parameters taken into account in our algorithm
are: Status, latency, CPU usage, disk space, number of active
processes, number of users, number of zombie processes and
network assessment.
It is necessary to normalize the results of entropy variance
calculated for use it in the Backpropagation algorithm, since
very high values may impair algorithm effectiveness.
41
JNIC2015
Fig. 3. Virtual test scenario
C. Transfer function
A sigmoid function will be used as activation function and
thus to determine the level of success of the inferred response.
Specifically, we use bipolar functions to achieve faster
stabilization error.
We will prove two sigmoid functions:
-
Backpropagation algorithm is based on gradient descent

method to approach the Mean Square Error.
Bipolar logistic sigmoid function:

=
VI. LEARNING ALGORITHM
2
1
1 + !!
(3)
Hyperbolic tangent function:

=
! !!
! + !!
(4)
D. Stop condition
Stop condition is determined from Mean Square Error
(MSE):
=
(!"# !" )!
!" + 1 = !" + !"
(6)
!" = ! !
(7)
Where ! is the propagated error, ! is the input value and

is the learning factor.
However, the error function usually has many local minima.
Synaptic weights may depend on the mean gradient of the
environment points, rather than relying on a single point, to
avoid getting trapped on a local minimum. But this
modification requires a large computational effort and is not
efficient. Therefore, we have implemented two improvements
of the algorithm to prevent local minimum: adaptive learning
factor and backpropagation with momentum [20].
(5)
Where !"# is the desired output and !" is the generated

output by the algorithm.
Thus, the Backpropagation algorithm tries to find the neuron
weights that minimize MSE value, in order to obtain the most
accurate classification.
E. Validation
Validation is the last step and it is very important because it
determines whether the algorithm requires additional training.
To validate the generalization of neural network is necessary to
have a test set.
If the training set has too much information then the neural
network can suffer overlearning. Therefore, we use crossvalidation method to avoid overfitting. That is, available
sample is divided into two sets, training and test, with
examples of all pattern types.
VII. INTRUSION RESPONSE EVALUATION MODULE

The trained neural network evaluates the response triggered
by the AIRS. A satisfactory response is represented by 1, and
an unsatisfactory response with a value of -1. The output in
real value is taken to give more detail to the result instead of
using a step function. Thus, the improvement achieved by the
response against the intrusion is shown in an interval [1, -1]
and its named SuccessLevel. After that, the response
efficiency is calculated as follows:
!!!
!
!!!
ResponseEfficiency =
!"##$%%&'#()*
!"#$%&'()*'+#,
(8)
(9)
Executiontimes and j are the times that this response was

triggered.
42
JNIC2015
VIII.
VALIDATION
Neural Networks need a training phase to construct network

topology and select the best values for weights of the
connections. For facilitate this task, the implementation has
been made in a parameterized form. Moreover, this
implementation form allows studies of efficiency of distinct
architectures of Neural Network. Thus we can obtain the best
result for the partial response efficiency in real time.
The validation is taken place by integrating this module in
the AIRS. Then, the system will be executed in a controlled
virtual environment. The virtual scenario is simulating a small
organization with different servers, firewall and hosts (Fig. 3.).
This scenario has been constructed using the VNX tool [21].
To collect the necessary samples of system and network
context, the validation prototype uses the Nagios and Sancp
tools to monitor system parameters and network traffic. Also,
we will attack servers or hosts of the virtual scenario to create
real alarms in the IDSs using Kali Linux and attack scripts. For
example, we attack a virtual web server with DoS (Denegation
of Service) using slowloris script from the attacker host [22].
In our case, we need a minimum of about 200 samples of
context to train the neural network with one layer. For it, we
will implement an automatic script to execute different attacks.
Once we have all the patterns, they will be presented to
different topologies of the neural network. The best topology
will be selected for use in the calculation of the effectiveness of
the response.
This neural network will be represented as several
mathematical functions based in backpropagation algorithm
and the calculated weights. SucessFactor will be the output of
this neural network when the AIRS launches a response.
Finally, the response efficiency will be calculated as we
explain in subsection VII.
ACKNOWLEDGMENT
This work has been partially funded with support from

Spanish MICINN (project RECLAMO, Virtual and
Collaborative Honeynets based on Trust Management and
Autonomous Systems applied to Intrusion Management, with
codes TIN2011-28287-C02-01 and TIN2011-28287-C02-02)
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
IX. CONCLUSION AND FUTURE WORK

In this paper we propose to use Automatic Learning to train
an Automated Intrusion Response System. Specifically, we
have chosen Backpropagation Algorithm to measure response
efficiency and thus, to provide adaptability to the AIRS.
This technology classifies any type of response, regardless of
the type of intrusion detected by the system. That is, the system
can obtain good results even to unknown intrusions because we
have made the algorithm independent of the intrusion type.
First, it is necessary obtain patterns of system and network
context for studying intrusion types. Last, we will analyze
different topologies using cross-validation method with the
training and test sets. Once the best neural network is selected,
the system is prepared to evaluate efficiency of the triggered
response for the AIRS.
We propose to use other improvements of the
backpropagation learning algorithm as future work:
-
Using SAB method that combines adaptive learning

factor and backpropagation with momentum.
Using others bio-inspired algorithms as immune
system.
[12]
[13]
[14]
[15]
[16]
[17]
Randomly initializing weights based on range.
43
Symantec Corp., Internet Security Threat Report, Vol. 17, Abril 2012.
Anderson, James. Computer Security Threat Monitoring and
Surveillance. Washing, PA, James P. Anderson Co. 1980.
H. J. Mattord. Principles of Information Security Course Technology.
2008. ISBN 9781423901778: 290-301.
Ali Aydin M, Halim Zaim A, Gkhan Ceylan K. A hybrid intrusion
detection system design for computer network security. Comput Elect
Eng, 2009; 35(3):51726.
Stakhanova N, Basu S, Wong J. A taxonomy of intrusion response
system. Int J Inform Comput Secur. 2007; 1(1/2):16984
J. E. Lpez de Vergara, E. Vzquez, A. Martin, S. Dubus, M. N.
Lepareux. Use of ontologies for the definition of alerts and policies in
a network security platform, Journal of Networks, Vol. 4, Issue 8
(2009) pp. 720-733
I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M.
Dean, SWRL: A semantic web rule language combining OWL and
RuleML. W3C Member Submission, 21, 2004.
H. Debar, D. Curry, B. Feinstein. The Intrusion Detection Message
Exchange Format (IDMEF). IETF Request for Comments 4765, 2007
J.E. Lpez de Vergara, V.A.Villagr, J.I. Asensio, J. Berrocal.
Ontology-based network management: study cases and lessons
learned. J Network Syst Manage 2009; 17(3):23454.
D. L. McGuinness, F. van Harmelen. OWL Web Ontology Language
Overview. W3C Recommendation 2004
Hu, Xunlei Rose, and Eric Atwell. "A survey of machine learning
approaches to analysis of large corpora." Proceedings of the Workshop
on Shallow Processing of Large Corpora, Lancaster University, UK.
2003.
Ling-xi Peng, Dong-qing Xie, Ying Gao, Wen-bin Chen, Fu-fang Li,
Wu Wen. An Inmune-inspired Adaptative Automated Intrusion
Response System. International Journal of Computational Intelligence
Systems, 2012, 5:5, 808-815
Alireza Shameli-Sendi, Julien Desfossez, Michel Dagenais, Masoume
Jabbarifar. A Retroactive- Burst Framework for Automated Intrusion
Response System, Journal of Computer Networks and
Communications, Volume 2013.
Justina, Aderonke, and Adesina Simon. A credible cost-sensitive model
for intrusion response selection. In Computational Aspects of Social
Networks (CASoN), 2012 Fourth International Conference on, pp. 222227. IEEE, 2012.
Z. Mahmood, C. Agrawal, S. S. Hasan, S. Zenab, Intrusion Detection
in Cloud Computing environment using Neural Network. International
Journal of Research in Computer Engineering & Electronics, 2012. 1(1),
19-22.
[20] R. S. Naoum, Abid, N. A., Z. N. Al-Sultani, An Enhanced
Resilient Backpropagation Artificial Neural Network for Intrusion
Detection System. IJCSNS, 2012. 12(3), 11.
V. Mateos, V.A. Villagr, F. Romero. Ontologies-Based Automated
Intrusion Response System. Computacional Intelligence in Security
for information Systems 2010. Volume 85/2010. 2010:99/106
JNIC2015
[18]
[19]
[20]
[21]
[22]
V. Mateos. V. A. Villagr, F. Romero, J. Berrocal. Definition of

response metrics for an ontology-based Automated Intrusion Response
Systems. Computers & Electrical Engineering. 2012.
J. Heaton. Introduction to Neural Networks for Java. 2nd Edition.
Rumelhart, D.E., Hinton, G.E. y Williams, R.J. (1986). Learning
internal representations by error propagation. En: D.E. Rumelhart y J.L.
McClelland (Eds.). Parallel distributed processing (pp. 318-362).
Cambridge, MA: MIT Press
Galn F, Fernndez D, Lpez de Vergara JE, Casellas R. Using a
model-driven architecture for technology-independent scenario
configuration in networking testbeds. IEEE Commun Mag 2010:132
141.
KATKAR, Vijay, et al. Detection of DoS/DDoS Attack against HTTP
Servers Using Naive Bayesian. En Computing Communication Control
and Automation (ICCUBEA), 2015 International Conference on. IEEE,
2015. p. 280-285.
44
JNIC2015

1
Spam Honeypots in Cloud Services

Carlos Cilleruelo Rodrguez1 , Alberto Cuesta Parejo1 , Manuel Sanchez Rubio2
1
Department of Computer Science, Universidad de Alcala
2
Lead Researcher in Cibersecuritics Research Group, Universidad Internacional de La Rioja
carlos.cilleruelo@edu.uah.es, alberto.cuesta@edu.uah.es, manuel.sanchezrubio@unir.net
Abstract Spam capture and analysis via spam honeypots
on cloud servers. The present document exposes the detailed architecture and configuration of cloud servers which
purpose is capture spam. This purpose was arranged deploying three servers and capturing spam for a month. Some
of the data obtained is presented in this paper, more than
32 millions of email addresses and 32.800.820 spam mails
has been logged in this period of time.
Keywords Spam, Honeynet, Shiva, Modern Honey Network(MHN), Snort, Cloud
n
I. Introduccio
La finalidad de este trabajo es el estudio de las campa
nas de spam actuales para su posterior an
alisis. Esto
puede servir para detectar nuevas campa
nas de phishing
o malware, as como los patrones usados para tal prop
osito, permitiendo posteriormente su estudio.
Actualmente existen dos aproximaciones para el estudio de las campa
nas de spam mediante spam traps. Una
primera aproximacion consiste en la creacion de diversas
cuentas de correo en diferentes dominios, esperando correos de spam para capturarlos, pudiendo existir dos vertientes de esta aproximacion:
Spam traps puras: en este caso las cuentas de correo se crean explcitamente para la captura de spam,
de forma que la direccion se pueda obtener por utilizar nombres comunes (i.e. pedroperez@email.com, josegarcia@email.com...). Estas cuentas no deber
an ser filtradas, ni deberan enviar correos o recibirlos, de modo que
todo lo que llegue a ellas solo sera spam, producido por la
inferencia del nombre de la cuenta para el envo de spam.
Spam traps recicladas: consiste en utilizar cuentas de correo que ya han sido usadas para envo y recibo de correos
electr
onicos o que han podido ser filtradas en Internet,
como ocurre con muchas cuentas filtradas en p
aginas de
pastes como la conocida PasteBin.
En este trabajo se ha optado por una segunda aproximaci
on basada en honeypots habilitados como servidores
SMTP. Para la captura de spam se han desplegado varias
spam honeypots en la nube y de esta forma poder comprobar la viabilidad del proyecto. Una spam honeypot no
deja de ser un tipo de honeypot que tiene como finalidad
la captura de spam.
Por un lado tendremos Shiva [1] como servidor de correo
SMTP abierto para recibir y analizar mensajes, junto con
Shiva se ha desplegado un sistema de detecci
on de intrusiones SNORT [2] para detectar escaneos y ataques. Como
panel de control y centralizacion de datos se ha utilizado
Modern Honey Network [3]. Ademas para almacenar los
datos obtenidos de correos spam se ha optado por el uso
de una base de datos MySQL.
45
II. Software utilizado Spam Traps

A. Shiva Spam Honeypot
Shiva es una honeypot programada en lenguaje Python
cuyo proyecto se encuentra liberado bajo licencia GNU general public license, lo que permite realizar modificaciones
del c
odigo.
Al instalar y configurar Shiva se habilita un servidor de
correo. En nuestro caso este servidor SMTP se ha dejado
sin autenticaci
on y en el puerto por defecto, el 25.
En el caso de que se enve un correo a traves de nuestro
servidor con Shiva se almacenar
a la informaci
on en una
base de datos, pudiendose mantener en local o remoto, este proceso se llevar
a a cabo mediante el m
odulo Reciever
de Shiva. El propio Shiva analiza los correos recibidos obteniendo los archivos adjuntos y el texto enviado. Shiva
compara los mensajes nuevos con los existentes mediante
fuzzy hashing, de modo que si existe una similitud mayor al 85 % en la comparaci
on de dos mensajes se tomara
el mensaje como el mismo, de esta parte se encargar
a el
m
odulo Analyzer de Shiva.
B. Snort
Snort es un sistema de detecci
on de intrusos (IDS), un
proyecto de software libre que permite analizar tr
afico en
tiempo real.
El uso de este IDS permite enviar datos a un servidor
central ya que Snort soporta hpfeeds gracias a un proyecto
realizado por la empresa Threatstream [4].
Snort tambien permite crear nuevas reglas y alertas respecto al tr
afico que pasa a traves del servidor. En este caso
se han creado y aplicado reglas asociadas a detectar tr
afico
en el puerto 25.
C. Modern Honey Network
Modern Honey Network (MHN) es un proyecto de software libre que permite desplegar una honeynet de forma
sencilla y r
apida. Consta de un servidor central, el cual recibir
a informaci
on de los m
ultiples honeypots que se desplieguen.
La informaci
on de cada honeypot es recibida a traves de
hpfeeds [5] y se guardar
a en una base de datos MongoDB.
MHN tambien dispone de una REST API a traves de
la cual podemos acceder a los datos obtenidos y permite su integraci
on con Honeymap [6] para ver los ataques
realizados a las m
aquinas en directo.
La arquitectura puede verse esquem
aticamente en Fig.
11 .
1 Imagen
obtenida de http://threatstream.github.io/mhn/
JNIC2015

2
Fig. 1. Arquitectura de MHN
III. Uso de la nube y Arquitectura

Fig. 2. Arquitectura
A. Por que usar la nube?

El uso de servidores en la nube viene motivado por la escalabilidad. Los servicios en la nube permiten crear im
agenes de los servidores, una vez se ha configurado una spam
honeypot podran levantarse nuevos servidores en segundos
a partir de esa imagen [7].
Gracias a esta flexibilidad se podra escalar el n
umero de
honeypots desplegados o reducirlos en muy poco tiempo.
En este caso se ha optado como proveedores Digital
Ocean y Amazon Web Services.
B. Arquitectura
La arquitectura no es de excesiva complejidad, por un
lado se configuran las spam honeypots con Shiva que
envan los datos obtenidos a una base de datos MySQL,
centralizando de esta forma los datos obtenidos.
Al tener una base de datos centralizada se puede liberar
de carga a los servidores de correo y disponer de los datos
de las spam honeypots en una u
nica base de datos para
un posterior manejo de los datos mas sencillo.
Por otra parte cada Snort instalado en los servidores
enva informacion al Servidor MHN que permite tener un
control en tiempo real de los posibles escaneos o conexiones a los servidores.
Esta base de datos es gratuita durante todo el primer a

no
de uso.
El coste total que ha supuesto el despliegue de los servidores ha sido de 20$ al mes.
n y securizacio
n de Spam
IV. Configuracio
Honeypots
A. SSH
Al no tener acceso fsico a las m
aquinas en la nube,
todos los servidores tienen acceso a traves de ssh. Todas
las m
aquinas cuentan con acceso exterior a Internet, por
esa raz
on se considera necesario fortificar el servicio ssh.
En primer lugar se generan un par de claves RSA y se
copia la clave p
ublica al servidor. De esta forma se evita
el acceso con contrase
na.
1
2
Posteriormente se modifica el archivo sshd config cambiando el puerto por defecto e impidiendo la autenticacion
con contrase
nas:
1
2
C. Especificaci
on de Servidores
sshkeygen t r s a
sshcopyi d i . s s h / i d r s a . pub root@X .X.X.X
Port 2222
P a s s w o r d A u t h e n t i c a t i o n no
Finalmente se puede activar f

acilmente un segundo factor de autenticaci
on como el de Google [9].
Ubuntu 14.04 x64 bits

RAM: 512 MB
Disco SSD: 20 GB
Digital Ocean Droplets
RAM: 1 GB
Disco: 20 GB
Amazon Web Services RDS
B. MHN Server
Aunque MHN es un software que actualmente se encuentra en fase beta, la instalaci
on no supone ning
un problema. Utilizando el script install.sh del proyecto instalaremos todo lo necesario y si todo es ejecutado de forma
correcta se tendr
a la aplicaci
on operativa.
D. Coste
Cada servidor alojado en Digital Ocean tiene un coste de 5$. En las pruebas realizadas estos servidores han
funcionado perfectamente. Se han desplegado 3 spam honeypots y el servidor MHN en Digital Ocean.
La base de datos MySQL se encuentra alojada en Amazon Web Services, siendo de tipo RDS Free Usage Tier [8].
46
C. Snort
Instalar Snort en los servidores es un proceso sin complicaciones gracias a MHN. Desde la secci
on de deploy
podr
a seleccionarse Snort, lo que generar
a un comando
como este:
JNIC2015

3
wget h t t p : / /X.X.X.X/ a p i / s c r i p t /? t e x t=t r u e&

s c r i p t i d =8 O d e p l o y . sh && sudo bash
d e p l o y . sh h t t p : / /X.X.X.X tLGQ77cf
Si se ejecuta este comando en el servidor en el cual que

se pretende instalar Snort, se instalara el sistema de detecci
on de intrusiones y automaticamente se configurar
a
para reportar los datos al servidor MHN.
Esto se puede realizar m
ultiples veces aunque, tras cada instalacion, se debe generar un nuevo comando desde
MHN.
Llegados a este punto ya se encuentra Snort instalado
pero con las reglas open version 2.9.0 [10]. Gracias a estas reglas podran detectarse m
ultiples ataques, pero sobre
todo ser
a de interes el estudio de las conexiones al puerto
25, que es donde estara el servidor SMTP abierto.
Para que se produzca un aviso cada vez que haya una
comunicacion externa con el puerto 25 es necesario a
nadir
una nueva regla a Snort. Al final del archivo local.rules
que se encuentra en la ruta /opt/snort/rules, se a
nade la
siguiente regla:
1
a l e r t t c p $EXTERNAL NET any > $HOME NET 25 (

msg : SMTP AUTH LOGON ;
classtype :
s u s p i c i o u s l o g i n ; s i d : 1 0 0 0 0 0 1 ; r e v : 5 ; )
Una vez agregada la regla debera reiniciarse Snort para

que empiece a aplicar la nueva regla creada:
1
sudo s u p e r v i s o r c t l r e s t a r t s n o r t
Tras estos pasos ser

a necesario modificar el fichero de
configura.ci
on shiva.conf que se encuentra en la carpeta
Shiva generada por el script install.sh.
Los campos a modificar de forma imprescindible seran:
listenhost: IP del servidor que va a crear un servidor
SMTP
1
2
listenport: Cambiar el puerto del servidor SMTP al 25.

Se recomienda usar el puerto 25 ya que es el puerto por
defecto para el protocolo SMTP.
1
2
[ receiver ]
l i s t e n p o r t : 25
Sensor: Se otorga un nombre al servidor para poder distinguirlo del resto de spam honeypots. En la base de datos
centralizada quedar
a registrado con este nombre.
sensorname : r h a e g a l
Relay: En un principio se mantendr

a la opci
on de Relay
activada, de este modo nuestro servidor enviar
a los emails
que le lleguen. Si posteriormente se detecta un envio masivo de spam desde nuestro servidor es recomendable desactivar la opci
on para evitar acabar en listas negras.
r e l a y : True
Schedulertime: Con este par

ametro se indica cada cuanto tiempo se har
an inserciones en la base de datos centralizada desde la spam honeypot.
D. MySQL Server
La arquitectura planteada consta de un servidor
MySQL donde se volcara la informacion relativa al Spam
capturado. Para que los datos sean introducidos en el servidor MySQL sera imprescindible crear las bases de datos
que necesita Shiva. Su creacion se puede realizar sin problemas gracias a dos scripts .sql que proporciona Shiva.
[ receiver ]
l i s t e n h o s t : X.X.X.X
s c h e d u l e r t i m e : 120
Localdb: Ya que se va a utilizar una base de datos es

importante tener esta opci
on. Aunque se llame localdb es
la que permitir
a usar una base de datos, ya sea local o
remota.
1
2
[ database ]
l o c a l d b : True
Host: En este campo se indicar

a la direcci
on de la base
de datos MySQL
mysql h HOST u USER password=PASSWD <

tempdb . s q l
mysql h HOST u USER password=PASSWD <
maindb . s q l
h o s t : s h i v a mysql . euwest 1. r d s . amazonaws .

com
User y password: Tambien se deben indicar las credenciales a la base de datos.
Con esto se creara una base de datos temporal, en la

que almacenar de manera inmediata el spam, y otra base
de datos principal, en la que se introduciran datos desde
la base de datos temporal.
Tras introducirse datos en la base de datos temporal,
estos se comparan con los datos almacenados en la base
de datos principal. Si hay datos nuevos se agregar
an a la
base de datos principal y si no son nuevos se actualizar
an
los valores.
E. Shiva
Tras esto se deben arrancar los componentes receiver y

analyzer de Shiva mediante:
La instalacion de Shiva no supone un proceso complicado. Existe un script llamado install.sh que permitir
a
instalar los componentenes necesarios. Antes de ejecutar
este script es necesario instalar una serie de paquetes:
1
2
u s e r : userExample
password : 1234 Example
El resto de opciones se podr

an dejar por defecto.
Llegados a este punto solo quedara arrancar Shiva. En
la primera ejecuci
on ser
a necesario arrancar exim, que permite enviar el correo entrante:
1
1
2
3
4
. / s e t u p e x i m 4 . sh
cd s h i v a R e c e i v e r /
source bin / a c t i v a t e
cd r e c e i v e r /
lamson s t a r t
5
1
aptg e t i n s t a l l y g i t pythondev exim4

daemonl i g h t g++ pythonv i r t u a l e n v
l i b m y s q l c l i e n t dev make l i b f f i dev
l i b f u z z y dev automake a u t o c o n f
6
7
8
9
47
cd s h i v a A n a l y z e r /
source bin / a c t i v a t e
cd a n a l y z e r /
lamson s t a r t
JNIC2015

4
Para el proceso de arrancado es facil crear un script que

automatice todo el proceso.
Llegados a este punto se tendra un servidor SMTP operativo sin autenticacion que cada dos horas enva los datos
capturados a una base de datos MySQL.
E.1 Bug Inodes en Shiva
f i n d . t y p e f p r i n t d e l e t e
X.X.X.X/ a p i / f e e d /? a p i k e y=KEY&c h a n n e l=s n o r t .

a l e r t s&h o u r s a g o=X
Ataques contra una spam honeypot las u

ltimas X horas.
X.X.X.X/ a p i / s e s s i o n /? a p i k e y=KEY&h o u r s a g o=X&
hostname=drogon
Las respuestas que proporciona MHN son en formato

JSON.
1
2
3
4
5
6
7
8
9
10
11
V. Consulta de los Datos
12
A. HoneyMap
13
MHN despliega un mapa donde es posible ver los ataques. Gracias a esto se consigue tener una monitorizaci
on
en tiempo real de los ataques recibidos, ya que Snort est
a
monitorizando las conexiones.
En nuestro caso el mapa es totalmente accesible desde
http://46.101.24.221:3000/.
B. MySQL Server
La consulta de los datos podra realizarse desde cualquier dispositivo con alg
un gestor para bases de datos,
como pueden ser MySQL Workbench, HeidiSQL o desde
consola, mediante autenticacion a la base de datos remota.
En la base de datos temporal se almacenar
an los datos
relativos a:
Archivos adjuntos
Enlaces del mensaje
Spam honeypot del que proceden los datos
La base de datos temporal tambien cuenta con una tabla
con datos pertenecientes al spam detectado, con un identificador y el fuzzy hash (basado en ssdeep), que identificar
a
el mensaje seg
un el contenido del mismo entre otros datos.
En la base de datos principal los datos que m
as interes
suscitan para su estudio seran:
Archivos adjuntos
Direcciones IP
Spam honeypot del que proceden los datos
Direcciones de correo de los destinatarios
Direcci
on de correo que enva estos correos
Mensaje enviado
C. MHN API
MHN mantiene una base de datos MongoDB donde se
almacenan los ataques detectados por Snort. Esta base de
datos es accesible a traves de una API REST.
Se pueden hacer peticiones para saber las IPs que m
as
han atacado en las u
ltimas X horas:
1
Se ha comprobado que debido al uso intensivo del servidor de correo el volumen de archivos generado en la carpeta /queue/new de Shiva se dispara.
Este problema se materializa en la necesidad de limpiar
peri
odicamente esta carpeta ya que, aunque tengamos espacio en disco, podemos llegar a quedarnos sin inodes.
Situ
andonos en la ruta anteriormente mencionada podremos eliminar los archivos de la cola mediante el comando:
1
Obtener los ataques detectados por Snort en las u

ltimas
X horas.
X.X.X.X/ a p i / t o p a t t a c k e r s /? a p i k e y=KEY&
h o u r s a g o=X
48
14
data : [
{
i d : 55 b217db3018557366476ca9 ,
d e s t i n a t i o n i p : X.X.X.X ,
d e s t i n a t i o n p o r t : 25 ,
honeypot : s n o r t ,
i d e n t i f i e r : b6376a8c 308b11e5a1b5
04015 f 2 2 c 4 0 1 ,
p r o t o c o l : TCP ,
source ip : 111.243.57.232 ,
s o u r c e p o r t : 1915 ,
timestamp : 20150724T10
:47:53.978000
},
Tambien es posible consultar estos datos desde la interfaz web que proporciona MHN. Desde el panel web sera
posible ver una enumeraci
on de los ataques y payloads
mostr
andose los pases de origen de los ataques y sus IPs,
los puertos utilizados para realizar el ataque o el patron
de ataque que se detecta a traves del IDS.
lisis de Datos Obtenidos
VI. Ana
Tras la instalaci
on de los servidores se ha podido comprobar que, en un plazo menor a 48 horas de tener en funcionamiento los mismos, se han empezado a enviar mensajes de spam desde IPs provenientes de Taiwan. Este caso
tan r
apido se dio en un servidor y sorprendio que esta
m
aquina se localizara tan r
apido, sin haber sido detectado por Shodan [11] en esos momentos.
Sin embargo, si se piensa en las nuevas herramientas
que existen para el escaneo de puertos como Zmap [12]
o Masscan [13], es factible encontrar r
apidamente nuevos
servidores con puertos abiertos. Estos nuevos esc
aneres
pueden mandar 10 millones de paquetes por segundo, pudiendo escanear todo el rango de direcciones IPv4 en 5
minutos.
Semanas despues las otras dos spam honeypots empezaron a ser usadas por los mismos Taiwaneses, lo que implica
la constante monitorizaci
on de Internet por parte de este
grupo, o al menos de servidores con el puerto 25 abierto.
Este grupo, tras comprobar que el servidor SMTP funciona, inicia agresivas campa
nas de spam teniendo como
objetivo cuentas de correo con dominio localizado en Taiwan en su mayor parte.
En un mes se han detectado 32.800.820 intentos de envo
de spam. No todas las peticiones de envo de correo se
envan finalmente con objeto de no saturar al servidor.
Se han enviado 34.797 correos, lo que supone un 010 %
del total.
El email m
as enviado ha sido uno cuyo contenido es
c
odigo HTML con los hipervnculos mostrados en Fig. 3.
JNIC2015

5
TABLA I
Dominios de correo a los que fue enviado Spam.
Fig. 3. Mensaje de Spam m

as enviado
Este mensaje se ha recibido 7.686.676 veces, siendo su

contenido enlaces a una tienda online de juguetes er
oticos.
Gracias al analisis recogido en el servidor con MHN se
han detectado en torno a 7.000 ataques al da. Desde el
primer momento en que la spam honeypot tiene acceso al
exterior empieza a recibir m
ultiples escaneos.
A. Direcciones de Correo Donde el Spam se Dirige
Se han obtenido 466.637 direcciones de correo electr
onico de 151 dominios de correo distintos. La mayora de direcciones de correo pertenecen al dominio yahoo.com.tw,
representado el 957 % con 446.537 de ellas. Siendo el resto
solamente 20.100, lo que representa un 43 %. En la Tabla
I se pueden apreciar los dominios de correo utilizados, se
han omitido los dominios con menos de 20 apariciones.
Se ha omitido el dominio yahoo.com.tw en Fig. 4 para
poder mostrar el resto de resultados de forma m
as representativa.
Fig. 4. Dominios de correo con m

as de 1000 ocurrencias
49
Dominio de Correo Cantidad

yahoo.com.tw
446537
163.com
5667
kimo.com
2265
sina.com
2183
hotmail.com
1878
sohu.com
1372
21cn.com
944
tom.com
929
163.net
840
126.com
501
263.net
445
eyou.com
434
ymail.com
393
sina.com.cn
272
yahoo.com.cn
200
yeah.net
130
vip.sina.com
126
yahoo.com.hk
113
263.com
68
citiz.net
54
yahoo.com
54
163.com
54
rocketmail.com
42
mail.china.com
40
china.com.cn
38
21cn.net
29
sina.com
27
msn.com
27
inhe.net
25
vip.163.com
24
qq.com
21
VII. Conclusiones
Tras haber probado varias configuraciones y arquitecturas para el estudio de la captaci
on de Spam finalmente se
lleg
o a la soluci
on presentada en la investigacion por ser
la que mejor datos ha proporcionado.
Nuestra finalidad a la hora de realizar esta investigaci
on era comprobar la viabilidad de usar servicios en la
nube para recolectar Spam. Esto ha demostrado ser posible, lo cual ha llevado a desarrollar una metodologa y
arquitectura para llevarlo a cabo.
Ya que se siguen obteniendo datos, nuestra idea es ampliar la red y empezar a recolectar m
as informaci
on. La
informaci
on presentada en este trabajo es muy limitada ya
que supone s
olo un mes de obtenci
on de informaci
on y solamente 3 spam honeypots. La idea es ampliar el n
umero
de spam honeypots e incluir la aproximaci
on de la creaci
on de cuentas de correo, dispuestas para recibir spam
y as tener un entorno m
as completo en el que basar el
an
alisis.
A su vez, el an
alisis de los datos ha abierto un abanico de posibilidades de cara al futuro, pudiendose llegar a
JNIC2015

6
utilizar este tipo de trampas para la obtenci

on de correos
electr
onicos y, en manos de alg
un ente malicioso, realizar
nuevas campa
nas de spam, phising o venta de direcciones
de correo electronico obtenidas.
Tambien se esta estudiando la posibilidad de publicar
las direcciones IP de los servidores en foros o webs. La
finalidad de esto sera aumentar el n
umero de correos recibidos, atrayendo a atacantes distintos a los taiwaneses
que copan el uso de los servidores. Llegados a este punto
en el que se dispusiera de distintos atacantes se podran
utilizar listas grises para evitar usos abusivos de nuestros
servidores y filtrar los datos que resulten m
as relevantes,
ya que los resultados obtenidos quedan desvirtuados a causa del uso abusivo de las campa
nas de Spam provenientes
de Taiwan.
Referencias
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
Rahul Binjve (2015). Spam Honeypot with Intelligent Virtual Analyzer (Shiva). Disponible en: https://github.com/
shiva-spampot/shiva
Martin Roesch (2015). Snort NIDS. Disponible en: https://
www.snort.org/
ThreatStream (2015). Modern Honey Network. Disponible en:
https://github.com/threatstream/mhn
ThreatStream (2014). Snort hpfeeds, collector for shipping
snort alerts using hpfeeds. Disponible en: https://github.com/
threatstream/snort_hpfeeds
Mark Schloesser (2015). Hpfeeds, Honeynet Project generic authenticated datafeed protocol. Disponible en: https://github.
com/rep/hpfeeds
Florian Weingarten(2013). Web application which visualizes a
live stream of GPS locations on a SVG world map. Disponible
en: https://github.com/fw42/honeymap
Digital
Ocean
Guide
(2014).
How
To
Migrate
Droplets
Using
Snapshots.
Disponible
en:
https:
//www.digitalocean.com/community/tutorials/
how-to-migrate-droplets-using-snapshots
Amazon(n.d). Capa gratuita de Amazon RDS. Disponible en:
http://aws.amazon.com/es/rds/free/
Digital Ocean Guide (2013). How To Protect SSH
With
Two-Factor
Authentication.
Disponible
en:
https://www.digitalocean.com/community/tutorials/
how-to-protect-ssh-with-two-factor-authentication
Emerging Threats (2015). Snort Open Rules 2.9.0. Disponible
en: http://rules.emergingthreats.net/open/snort-2.9.0/
John Matherly (2015). First search engine for Internetconnected devices(Shodan) Disponible en: https://www.
shodan.io/
University of Michigan (2015). Open-source network scanner
(Zmap) Disponible en: https://zmap.io/
Robert David Graham (2015). MASSCAN: Mass IP port scanner. Disponible en: https://github.com/robertdavidgraham/
masscan
50
JNIC2015

1
Security via Underwater Acoustic Networks:

the Concept and Results of the RACUN Project
Paolo Casari? , Joerg Kalwa, Michele Zorzi, Stefano Nasta, Sabrina Schreiber, Roald Otnes,
Paul van Walree, Michael Goetz, Arwid Komulainen, Bernt Nilsson, Jan Nilsson, Tommy Oberg,
Ivor Nissen, Henrik Strandberg, Henry Dol, Geert Leus, Francesco Pacini
? Corresponding
author, email: paolo.casari@imdea.org
AbstractThis paper presents the European Defence Agency

project Robust Acoustic Communications in Underwater Networks (RACUN), aimed at demonstrating underwater acoustic
communications and networking for tactical and security-related
scenarios such as intelligence, mine counter-measures, and antisubmarine warfare. The project involved communications among
static and mobile underwater nodes deployed at different depths,
acoustic/radio gateways, as well as ships. We describe the
hardware employed in the project, outline the selected physicallayer schemes and networking protocols, and present results from
the final RACUN sea trial. The RACUN project demonstrated
a working underwater network of heterogeneous nodes, both
static and mobile, in typical tactical scenarios, and laid solid
foundations for the networking of underwater assets in Europe.
Index TermsUnderwater acoustic networks; tactical missions; channel soundings; channel simulations; modulation
schemes; network protocols; network simulations; heterogeneous
networks; sea trials; RACUN project; EDA.
I. T HE RACUN P ROJECT
Many navies across Europe see effectively networked underwater communications as an enabling technology to make
progress in security-related and tactical scenarios encompassing at-sea environments. The RACUN project answers this
need via the design of rapidly deployable underwater networks
of autonomous sensors and underwater vehicles (AUVs). A
consortium of partners from five European nations developed
and demonstrated the capability to establish a robust underwater multi-purpose acoustic network with moving and stationary
nodes, as well as its operational value in tactical scenarios.
Paolo Casari (corresponding author) is with IMDEA Networks Institute,
Spain, and with Consorzio Futuro in Ricerca (CFR), Italy. Joerg Kalwa is
with ATLAS Elektronik (ATLAS), Germany. Michele Zorzi is with CFR,
Italy. Stefano Nasta is with Centro di Supporto e Sperimentazione Navale
(CSSN), Italy. Sabrina Schreiber is with L-3 Communications ELAC Nautik
(ELAC), Germany, Roald Otnes and Paul van Walree are with the Norwegian
Defence Research Establishment (FFI). Michael Goetz is with Fraunhofer
Institute for Communication Information Processing and Ergonomics (FKIE).
Arwid Komulainen, Bernt Nilsson, Jan Nilsson and Tommy Oberg

are with
the Swedish Defence Research Agency (FOI). Ivor Nissen is with the German
Research Department for Underwater Acoustics and Marine Geophysics
(WTD71/FWG) Henrik Strandberg is with Saab Dynamics (SAAB). Henry
Dol is with the Netherlands Organization for Applied Scientific Research
(TNO). Geert Leus is with the Delft University of Technology (TUD).
Francesco Pacini is with Whitehead Sistemi Subacquei (WASS).
The work described in this publication was done under a multi-national
four-year project with the name Robust Acoustic Communications in Underwater Networks (RACUN) under the EDA Project Arrangement No. B0386-ESM1-GC. The authors are indebted with all collaborators from all
participating institutions whose work and dedication made the RACUN project
a success. The co-authors are sorted by their affiliation (short names).
The RACUN project was funded by the national ministries

of defense of the participating nations as a key area of
the European Defence Agency (EDA)s Unmanned Maritime
Systems (UMS) program, which aims to deliver advanced
maritime mine counter-measures (MCM) and related technologies by 2020. The partnership involved companies and
research institutions from Germany, Italy, the Netherlands,
Norway and Sweden. RACUN contributed to explore the
theoretical background for the development and advance the
maturity level of robust underwater networking, especially
with respect to end-to-end communications. A survey of
existing physical layer (PHY) and networking technologies
has been performed and related to the envisaged development
targets. A number of gaps between the project objectives
and the available technologies were identified and bridged
via a combination of theoretical studies, simulation studies,
and several sea trials. Suitable physical-layer methods and
networking protocols have been developed and implemented
in programmable modems, which were integrated into AUVs,
gateway buoys, and bottom/moored nodes.
Simulation proved to be an invaluable tool to reduce the
number of sea trials required when developing new systems [1], [2]. Candidate PHY methods, network protocols and
combinations thereof have been thoroughly evaluated thanks to
acoustic channel models aided by channel measurements taken
during the first RACUN sea trial campaign in diverse European
coastal waters (Sea Trial 1), and by a discrete-event simulation
package fed with statistical representations of physical-layer
performance. An intermediate sea trial campaign in the Netherlands coastal waters (North Sea; Sea Trial 2) with an integrated
system was used to test and confirm the work done in the
project up to that time, and provided experience to improve
the system further. In a final sea trial in Italian coastal waters
(Mediterranean Sea; Sea Trial 3), the full RACUN system has
been demonstrated and evaluated against criteria defined early
in the project.
The project was organized through five workpackages
(WPs) and many sea trial preparation camps. Different partners
focused on different aspects of the physical, network (NET)
and application (APP) layers. Most of the PHY and APP
software was integrated into the wet end of the modems.
Additional flexibility was provided for the NET layer, which
could be run as a stand-alone piece of software, or by
reusing simulation code written for the ns2 software and the
DESERT Underwater framework [3], via a hardware-in-the-
51
JNIC2015

2
Figure 1. The hardware employed in the RACUN projects Sea Trial 3 (ST3). (a) NILUS nodes (FFI, Norway); (b) gateway buoy (ELAC, Germany); (c)
moored nodes (SAAB, Sweden); (d) SeaCat AUV (ATLAS, Germany); and (e) NEREUS node (FWG, Germany).
loop configuration. A new Generic UnderWater Application

Language (GUWAL) [4] was applied to support the creation
and execution of relevant underwater applications via data
requests, data replies, command and control and text messaging functions. Finally, a methodology for simulation and
experiment analysis was developed to evaluate results and
measure the robustness of the network. Overall, the RACUN
project developed and successfully demonstrated several new
physical-layer schemes and ad hoc network protocols running
on heterogeneous hardware platforms, and employed such
assets to carry out operations in intelligence, surveillance, and
reconnaissance (ISR) as well as MCM scenarios of tactical
relevance.
In the remainder of this paper, we will outline the major components of RACUN: the hardware (Section II), the
physical-layer schemes (Section III), and the network protocols (Section IV). Section V summarizes results from
RACUNs final demonstration sea trial, and Section VI draws
our conclusions.
II. AVAILABLE H ARDWARE AND ACOUSTIC M ODEMS
We start by describing the design and functionalities provided by the main hardware employed in the RACUN project
(see Fig. 1). Given the scope and objectives of the RACUN
project, the chosen communications band is 48 kHz.
A. Develogic modem
Acoustic communications in RACUN were mainly delivered
by the software-defined Develogic Hydro-Acoustic Modem
HAM.Base [5]. The HAM.Base is a low-energy underwater

modem that can be exploited in commercial applications or
reprogrammed to support scientific research. The architecture
makes it possible to also run stand-alone C code implementing
other functionalities, e.g., the networking (NET) and error
control (EC) layers, and was designed to be installed in
underwater nodes of limited size. This made it possible to
equip Develogic modems in all RACUN nodes, except the
SAAB nodes (see Section II-B), which included a different
software-defined modem.
B. SAAB modem and node
The SAAB modem design approach aimed at providing
research project partners and national research establishments
with a (generic) reconfigurable platform, as opposed to commercial modems which are usually not available for firmware
customization and (embedded) reprogramming. A founding
principle of the SAAB modem is the lack of processing in
the wet-end unit: processing is delegated to a PC unit in
the dry-end part, which communicates with the wet end via
a cable comprising Ethernet data and power links. The PC
unit carries out all signal processing phases. All software
components run in the SAAB software-defined framework.
The wet end contains electronics and modules for performing
analog/digital/analog conversions. During the RACUN sea
trials, the SAAB modem was deployed on two moored nodes
and one ship node. For the moored node configuration, a
battery/PC buoy was developed. A real-time reconfiguration
capability via a separate acoustic signaling channel was im-
52
JNIC2015

3
plemented to avoid recovering and redeploying the nodes to

change physical-layer schemes and networking protocols.
C. NILUS and NEREUS bottom nodes
Networked InteLligent Underwater Sensors (NILUS) is a
demonstrator system developed by FFI prior to RACUN, for
the concept of easily deployable underwater sensor networks.
A NILUS bottom node contains, among other things, passive
acoustic and magnetic sensors, onboard signal processing
on an embedded Linux computer, and an acoustic modem.
For RACUN, two NILUS nodes were fitted with Develogic
modems and an extra Gumstix processor board to run additional networking software. Two other NILUS nodes were used
only to record acoustic data.
Four NEREUS (NEtworked REconfigurable Underwater
Sensor) bottom nodes, with similar functionality as the
NILUS, were provided by WTD71/FWG. One difference from
NILUS is that NEREUS uses an embedded Windows computer, which could only run network protocols as standalone
applications. WTD71/FWG also provided one Develogic BottomLander bottom node, which for RACUN was fit with the
same Gumstix processor board as NILUS and could hence run
network protocols either standalone or under ns2/DESERT.
D. Atlas SeaCat AUV
Atlas Elektronik provided the AUV SeaCat to represent a
mobile node. The SeaCat is a system capable of carrying a
variety of payloads in a fully flooded nose section. A compact
NetDCU9 processor board had been integrated to host the
networking software and application layer. The latter was
responsible to work as an interface between the communication systems and the AUVs capabilities, which included
an automatic detection of objects and reactive behavior to
commands issued through the underwater network.
E. ELAC gateway buoy
L-3 Communications ELAC Nautik provided a smart gateway buoy as a node in the underwater network. The general
mechanical and electrical structure of the buoy were developed
by AquaDrohne and extended with control and communication
equipment by ELAC. The buoy supported a through-air radio
link as well as an underwater acoustic communication link,
and could therefore establish a gateway between the two
communications mediums. Among other things, this enabled
commands and reports to be sent to and from ship computers,
across the air/water interface. The developed RACUN network
protocols and the buoy-specific RACUN application software
(based on the GUWAL specifications) were implemented on
the controller board of the buoy.
III. P HYSICAL LAYERS AND BENCHMARK
Several modulation schemes have been designed in
RACUN. Given the different development stages, only one of
the methods summarized below (FMT, Section III-A) could be
incorporated in both the Develogic and the SAAB modems,
and thereby be employed over a full-sized network in the final
RACUN sea trial (see also Section V). The other schemes
(Section III-B and Section III-C) could be incorporated only in
the more versatile architecture of the SAAB modems, limiting
the maximum network size to three nodes when using these
schemes, due to hardware availability reasons.
A. Filtered Multi-Tone (FMT)
A multi-carrier format named Filtered Multi-Tone (FMT)
was designed by WTD71/FWG as a part of the Transient
UnderWater Communication System (TUWACS) project [6],
and adapted to the requirements of RACUN. The main idea
behind FMT is to transmit only one symbol, so that the scheme
becomes robust to inter-symbol-interference. In RACUN, 128
bits per symbol were transmitted. The real-time detection of
FMT symbols is achieved via two subsequent synchronization
steps and iterative turbo decoding of both pilots and data [7].
During the RACUN sea trials, FMT was implemented in the
hardware of all nodes and achieved a data rate of 340 bps.
B. Single-Carrier Turbo Equalization (SCTE)
FOI designed a single-carrier modulation scheme, stemming
from the need to exploit the rich multipath of the underwater
channel without feedback from the receiver and employing
turbo equalization to compensate for signal distortions [8].
Training sequences are used to obtain estimates of the channel
impulse response. The main Doppler shift is eliminated via
resampling. After that, the channel estimate is completed with
additional details using the decoded symbols as reference. In
RACUN, a 4-QAM format was employed at a data rate of
1.4 kbps, reduced to 624 bps due to limitations in the RACUN
bitstream format.
C. OFDMR
TNO and TUD contributed two modulations to the RACUN
project, a wideband single-carrier modulation scheme employing a multi-scale multi-lag (MSML) method with adaptive
turbo-equalization [9], and a multiband OFDM method [10],
adapted to RACUNs higher data-rate requirements via a different turbo-coding algorithm. During the RACUN sea trials,
two configurations of the resulting OFDMR method (where the
R stands for RACUN) were used for two different message
lengths and data rates, namely OFDMR1 (256 bits, 205 bps)
and OFDMR2 (128 bits, 120 bps).
D. Structure of channel sounding and benchmarking operations
A comprehensive set of physical-layer simulations was
carried out based on in-situ channel measurements. At an early
stage of the project (Sea Trial 1), the time-varying impulse
response was measured at relevant locations and for various
ranges. These measurements have been collected in a channel
archive that reveals a formidable diversity of propagation
conditions [11]. A channel-replay simulator [12], driven by
the archived channels, was used to benchmark the RACUN
modulation schemes. Replay is a realistic, ultra-wideband
53
JNIC2015

4
Figure 2. PER lookup tables for FMT, SCTE and OFDMR2. (top pane) Relationship between PER and noise. (bottom panes) Checkerboards reporting PER
in case of collisions, as a function of the signal-to-interference ratio (SIR) and of the overlap between the desired and colliding packets.
channel simulation technique that includes all signal distortions introduced by the waveguide. The benchmark results
were compiled as lookup tables (LUTs) containing packet
error rate (PER) estimates as a function of signal-to-noise ratio
(SNR), for all available modulation schemes and channels.
Fig. 2 (top pane) illustrates the LUT for FMT, SCTE and
OFDMR2 signals. The PER is plotted as a function of SNR,
for a channel measured over 3 nautical miles (nmi) in the
Gulf of La Spezia. The LUTs used in the network simulations
consist of such data for a variety of measured distances. One
important difference between the curves in Fig. 2 (top pane)
is that the PER of SCTE and OFDMR2 does not drop to zero
at high SNR for this channel. This is frequently observed in
underwater acoustic communications, where the performance
of modulation schemes may be limited by multipath and
Doppler effects, rather than noise.
Simulations were also performed to assess the impact of
collisions, which occur when two modem signals overlap
at a receiving modem. LUTs were compiled with the PER
as a function of the signal-to-interference ratio (SIR) and
the degree of overlap. Fig. 2 (bottom panes) illustrates the
collision LUT for FMT, SCTE and OFDMR2, where it is
shown, for example, that SCTE is slightly more robust to lower
values of the SIR than FMT, but fails the correct reception of a
signal for a broader range of overlap ratios. Similar arguments
apply to OFDMR2, which however presents a slightly lower
PER for SIR values between 10 and 0 dB, for an overlap up
to 50%.
A. GUWMANET
IV. N ETWORK P ROTOCOLS AND S IMULATIONS

This section presents the network protocols finally employed
in RACUN, and briefly discusses the network simulation setup
and results.
B. Dflood
FKIE, in cooperation with WTD71/FWG, developed a new

underwater ad hoc network protocol named Gossiping in
UnderWater Mobile Ad-hoc NETworks (GUWMANET) [13],
which was brought into the RACUN project as a reference protocol for simulations and at-sea experiments. GUWMANET
is designed using a cross-layer approach in combination with
GUWAL [4]. Basically, GUWAL packets have a fixed length
of 128 bits including a header with an operational source and
destination address and a checksum as parity check. These
fields are exploited by GUWMANET for routing purposes,
reducing the additional network overhead to a minimum of 10
bits, consisting of a source and last hop identifiers of 5 bits
each. In this way, it is possible to pack routing information
into a single FMT transmission, which reduces network traffic,
packet error rate and collision probability. GUWMANET
builds up routes autonomously via a learning process. In the
beginning, nodes use a simple flooding strategy to reach the
destination, which replies with an acknowledgement. This
message is routed back through the same relays employed
on the way to the destination, confirming the presence of a
valid route and creating persistent routing entries at intermediate relays. Retransmissions were introduced to increase the
robustness of the protocol. Sea experiments and simulations
showed that three repetitions are suitable in environments with
high packet error rates. GUWMANET was implemented both
as a stand-alone code and as an ns2 module.
Dflood [12] is a flooding-based protocol, which tries to

reduce the number of duplicate transmissions of a typical
flooding scheme without compromising its robustness. This is
54
JNIC2015

5
Figure 3. Connectivity map used in pre-trial simulations for the final RACUN demonstration trial (left), and example of connectivity map actually experienced
during the trial (right), where asymmetric links are indicated by one line for each direction between two nodes. The thickness and shade of each link are
proportional to its robustness. For an explanation of the node names, refer to Fig. 4.
achieved by exploiting information that the nodes get from

overhearing other nodes transmissions. In Dflood, a hop
counter is included in the packet header [14]. A node will
refrain from forwarding a packet if enough duplicates of that
packet are received with a higher hop count. Forwarding is
also stopped by a neighbor of the destination if it receives a
Receive notification from the destination. Dflood employs
a CSMA MAC protocol. Each node applies a tunable backoff time before forwarding a copy of an incoming packet.
This back-off time is adaptively increased each time the
node overhears a copy of the same packet. The predefined
maximum number of duplicates that need to be heard before
the forwarding is cancelled can also be tuned. In the basic
version of the Dflood protocol, no topology information is
used, no additional control traffic is required besides the
Receive notification, and nodes forward a packet only once.
Retransmissions can be configured for robustness by scheduling the transmission of a copy of a packet packet after some
delay. In large networks, topology information is delivered via
sink probes which help understand how many hops every node
and its nearest neighbors are from the sink. This mechanism
helps reduce unnecessary retransmissions.
In simulations, both regular Dflood, regular Dflood with
retransmissions, and Dflood with sink packets were tested. In
the sea trials, where the number of nodes was relatively small,
regular Dflood with one retransmission was employed.
C. Simulation software structure
Since sea trials are expensive and prone to mishaps and poor
reproducibility, simulations were extensively used in RACUN
to compare different protocols and decide what to use in sea
trials [2]. For network simulations, ns2 with the MIRACLE
and DESERT extensions [3] was applied. RACUN applied the
LUT-based physical-layer model described in Section III-D,
where the LUTs contain PER in real-world environments
vs. SNR, range, and interference. Extensive network simulations using scenarios defined at the beginning of RACUN
indicated that both Dflood and GUWMANET were viable
candidates for sea trial testing, with GUWMANET achieving better performance in particular when the FMT physical
layer was used. This was partly because GUWMANET was
designed for FMT and could send each 128-bit packet as
one FMT burst. Conversely, to get room for the required
header information, Dflood had to send each packet as two
FMT bursts with some seconds of silence in between. With
other physical layers, such fragmentation was not required for
Dflood and the performance of Dflood and GUWMANET was
closer, except that GUWMANET showed better scalability
with increasing network size.
Prior to the final RACUN sea trial (Sea Trial 3, ST3),
network simulations were performed using the planned geometrical layout. Lookup tables based on measurements in the
same environment two years before resulted in a connectivity
map as shown in Fig. 3 (left), in which simulated end-toend (E2E) packet delivery ratios close to 100% could be
achieved with both GUWMANET and Dflood when the traffic
load was moderate. However, the link performances actually
experienced in the final trial were much worse even though the
distances were shorter than in simulations, as shown in Fig. 3
(right), where the discrepancy is mostly due to the empirical
SNR modelling.
V. S EA T RIAL 3: D EMONSTRATION D ETAILS AND
R ESULTS
The RACUN projects final sea trial (ST3) took place
in May 2014 and had the objective to demonstrate realtime capabilities of the network to manage ISR and MCM
scenarios at sea, to test specific network features, and to
collect experimental data for understanding the performance
of physical-layer schemes and network protocols.
A. Experiment area, support assets and deployment setup
The Italian Navy (ITN) selected a trial area near the Italian
coast of approx. 1010 nmi2 , with minimum water depth
20 m, close to the Italian Naval Base of La Spezia. The nodes
were deployed in the area shown in Fig. 4. The inter-node
distances are in the range of 563 m to 8610 m.
55
JNIC2015

6
Figure 4. The RACUN ST3 area, off La Spezia, Italy (left); zoom on the deployment area, with deployment locations (right). In the node names, the first
letter represents the nation providing the hardware (G = Germany, N = Norway, S = Sweden), the second letter the node type (B = Bottom node, G = Gateway
buoy, S = ship node, R = passive recorder, W = Waverider buoy), whereas the number is a unique identifier.
The network was composed of: 2 NILUS bottom nodes plus

2 NILUS passive recording stations; 2 moored nodes plus 1
ship node from SAAB; up to 5 NEREUS bottom nodes plus
1 ship node; 1 gateway buoy from ELAC; 1 SeaCat AUV
from ATLAS plus additional equipment such as 1 Waverider
buoy in the second week. Typically, the bottom nodes were
left at sea during the night, while the other network elements
were deployed and recovered every day. The network was
configured to operate one of the PHY/network protocol pairs
FMT/GUWMANET or FMT/Dflood.
After one week of tests, the demonstration of ISR and
MCM scenarios was successfully carried out (albeit only
once because of bad weather conditions). A first conclusion
is that the physical-layer performance experienced in ST3
was inferior to that predicted by the lookup tables based
on measurements in the same area two years earlier. Given
environmental measurements, it seemed likely that the main
reasons for the discrepancy may be unfavorable sound-speed
profiles, ship/buoy/AUV movement (due to waves), and poorer
SNR compared to that predicted by empirical modeling. Future endeavors will consider more complex empirical models,
which take water depth and bottom type as additional inputs.
B. Description of ST3 ISR / MCM scenario and experiments
The Ministries of Defense of the countries participating
to RACUN set network performance requirements tied to
specific environments and tactical scenarios. Littoral waters
of different kinds were specifically considered, with depths up
to 200 m, offering challenging propagationtions for acoustic
signals across almost the whole year. Also according to the
Navy requirements, the networks should be composed of static
and/or mobile nodes on the bottom, at the surface, and in
the water volume, cooperating to detect, classify and collect
information. A gateway buoy should be included to extend
the communication over larger distances through the air. The
network should exhibit a desired level of effectiveness in
all weather conditions. The operational definition of the test
scenario implies: a 1010 nmi2 area; intra node distance
up to 5 nmi; mobile nodes cruising at up to 8 knots; allweather operational conditions. The main data packet class
employed in ST3 contains 128 bits, which must be delivered
with a success rate of 90% within a maximum E2E delay
of 5 minutes. These constraints reflect the importance of the
information conveyed by the packets, and accommodate some
time for retransmissions if required.
In ST3, the capabilities of the underwater network were
demonstrated via the reproduction of ISR and MCM scenarios.
The ATLAS AUV was used as a mobile communication node;
in the ISR scenario, the AUV took over the role of an intruder
that crossed the network and induced detection reports to be
sent by the bottom nodes and forwarded to the ships; during
the MCM scenario, the AUV was used as mine hunter using its
side-scan sonar. Both scenarios were repeated with both the
GUWMANET and the Dflood network protocols to collect
comparable results for the final evaluation. At the beginning
of each scenario, the network was initialized with a GUWAL
message followed by a broadcast status request, both sent
by one of the ships. After this, the AUV was commanded
to start its mission, depending on the respective scenario.
During these missions, events like intruder or mine detections
were collected at the ship. Additionally, the bottom nodes
sent out periodic status messages and the AUV communicated
its position roughly every five minutes. After one hour, the
mission was completed and the AUV surfaced back.
The configuration and results related to the tactical ISR
and MCM scenario demonstrations are summarized in Table I.
The results confirm that both scenarios could be successfully
demonstrated to the ST3 observers and national defense representatives with both the GUWMANET and Dflood network
protocols, despite the often adverse sea trial conditions that
even led to some equipment damage. The network operated in
a fully ad hoc manner without predefined routes, and encompassed static, mobile as well as surface nodes. GUWMANET
achieved a packet delivery ratio (PDR) of about 90% and
Dflood of about 70% with an average E2E delay well below 5
minutes, albeit at an average intra-node distance below 5 nmi.
56
JNIC2015

7
TABLE I
C ONFIGURATION AND RESULTS OBTAINED FOR THE ISR AND MCM SCENARIOS AT RACUN S FINAL DEMONSTRATION DURING S EA T RIAL 3 (ST3).
Configuration
ISR scenario
Protocol
Bottom nodes
Ship nodes
AUV
Gateway buoy
Sea state
GUWMANET
6
2
1 (damaged
during the test)
1
3
MCM scenario
Dflood
4
2
GUWMANET
6
2
Dflood
4
2
1 (surfaced)
1 (damaged during
the recovery)
34
N/A
N/A
Intra node distances

Depth
Protocol running time
N/A
N/A
12
563 m 8610 m
40 m 80 m
90 minutes
Results
Scenario
ISR GUWMANET
14/05/2014 (8:30-10:00)
ISR Dflood
14/05/2014 (10:30-12:00)
MCM GUWMANET
15.05.2014 (10:30-12:00)
MCM Dflood
15.05.2014 (8:30-10:00)
Number of nodes
PDR
E2E Delay
Energy consumption
per node
11
89.24%
81.92 s
17.43 J
68.15%
121.06 s
20.79 J
90.32%
58.21 s
13.72 J
70.18%
107.34 s
29.79 J
The main reason for the higher PDR of GUWMANET is

the lower network overhead, which allowed the transmission
of a packet within a single FMT burst, whereas Dflood had
to resort to fragmentation. The lower PDR that resulted was
compensated for via retransmissions, which explain the larger
E2E delay of Dflood compared to GUWMANET. Table I also
includes per-node energy consumption figures, which are also
higher for Dflood due to the same fragmentation and retransmission issues. Notably, the results above are in line with
those obtained from the simulations [2], and thereby prove
the feasibility and accuracy of the full-rounded simulation
approach followed in RACUN.
VI. S UMMARY OF ACHIEVEMENTS AND C ONCLUSIONS
Security is of primal importance in tactical scenarios at
sea, and effectively networked underwater communications are
seen as the enabling technology to achieve the next generation
of autonomous tactical systems off shore. In this paper, we
summarized the workflow, context and achievements of the
European Defence Agencys Robust Acoustic Communications in Underwater Networks (RACUN) project, which was
able to demonstrate a working ad hoc underwater network
of static and mobile nodes in typical tactical scenarios. This
was achieved with the diverse hardware and equipment that
was made available to (or adapted for) the RACUN project,
resulting in a heterogeneous network.
The main technical and scientific results of RACUN include: a fully developed workflow for the characterization
of underwater acoustic communications and networks, from
channel soundings and characterization to the modeling of
complex network protocols; the development and advancement
of many communication schemes used in medium-to-long

range communications; the setup of an ad hoc underwater
network encompassing very heterogeneous assets, including
mobile nodes; the ability to reuse network simulation software
directly in sea trials; the demonstration of the feasibility of
the RACUN communications and networking technologies in
tactical scenarios; a thorough scoring system to rank heterogeneous communications and networking solutions on a common
basis with respect to the requirements of the Navies.
Finally, the involvement of the RACUN management board
in guidelines that could be traced back to national interests
of the respective nations ensured that the project transferred
scientific results into requirements and mission goals agreed
by national authorities. Therefore, the results of the project
form a solid foundation to build upon in order to develop the
future capabilities of European navies.
57
R EFERENCES
[1] R. Otnes and P. van Walree, Validation of replay-based underwater
acoustic communication channel simulation, IEEE J. Ocean. Eng.,
vol. 38, no. 4, pp. 689700, Oct. 2013.
[2] C. Tapparello, P. Casari, G. Toso, I. Calabrese, R. Otnes, P. van
Walree, M. Goetz, I. Nissen, and M. Zorzi, Performance evaluation of
forwarding protocols for the RACUN network, in Proc. ACM WUWNet,
Kaohsiung, Taiwan, Nov. 2013.
[3] P. Casari et al., Open-source suites for the underwater networking community: WOSS and DESERT Underwater, IEEE Network, special issue
on Open Source for Networking: Development and Experimentation,
vol. 28, no. 5, pp. 3846, Sep. 2014.
[4] I. Nissen and M. Goetz, Generic underwater application language
(GUWAL) specification of tactical instant messaging in underwater networks, WTD71/FWG, Kiel, Germany, Tech. Rep. WTD710070/2012 FR, Dec. 2012.
JNIC2015

8
[5] F. Berning, T. Radtke, S. Rautenberg, M. Motz, and I. Nissen, A

realization of the software defined radio concept in an underwater
communication modem, in Proc. UCOMMS, Sestri Levante, Italy, Sep.
2014.
[6] I. Nissen, Alternativer ansatz zur verratsarmen unterwasserkommunikation durch verwendung eines transienten im kontext von IFS und
JUWEL, WTD71/FWG, Kiel, Germany, Tech. Rep., Jan. 2009.
[7] , A new and simple blind channel CSI cancellation calculus, in
Proc. DAGA2011/174, Dusseldorf, Germany, 2011.
[8] I. Karasalo, T. Oberg,

B. Nilsson, and S. Ivansson, Validation of replaybased underwater acoustic communication channel simulation, IEEE J.
Ocean. Eng., vol. 38, no. 4, pp. 666677, Oct. 2013.
[9] L. Cannelli, G. Leus, H. Dol, and P. van Walree, Adaptive turbo equalization for underwater acoustic communication, in Proc. MTS/IEEE
OCEANS, Bergen, Norway, Jun. 2013.
[10] G. Leus and P. van Walree, Multiband OFDM for covert acoustic
communications, IEEE J. Sel. Areas Commun., vol. 26, no. 9, pp. 1662
1673, Dec. 2008.
[11] P. van Walree, Propagation and scattering effects in underwater acoustic
communication channels, IEEE J. Ocean. Eng., vol. 38, no. 4, pp. 614
631, Oct. 2013.
[12] R. Otnes, P. van Walree, H. Buen, and H. Song, Underwater acoustic
network simulation with lookup tables from physical-layer replay, IEEE
J. Ocean. Eng., 2015, accepted.
[13] M. Goetz and I. Nissen, GUWMANET multicast routing in underwater acoustic networks, in Proc. MCC, Gdansk, Poland, Oct. 2012.
[14] R. Otnes and S. Haavik, Duplicate reduction with adaptive backoff
for a flooding-based underwater network protocol, in Proc. MTS/IEEE
OCEANS, Bergen, Norway, Jun. 2013.
58
JNIC2015

1
Sistema visual de monitorizacion de seguridad de

flujos de red industriales
Mikel Iturbe, I
naki Garitano, Urko Zurutuza, Roberto Uribeetxeberria
Dpto. de Electronica e Informatica
Escuela Politecnica Superior
Mondragon Unibertsitatea
Email: {miturbe, igaritano, uzurutuza, ruribeetxeberria}@mondragon.edu
Resumen Los sistemas de control industrial son el conjunto de elementos especializados que monitorizan y controlan procesos fsicos. Estos sistemas est
an generalmente
interconectados en entornos conocidos como redes industriales. Las particularidades de este tipo de redes desaconseja el uso de herramientas de seguridad utilizadas en redes tradicionales de computadoras, mientras que a la vez
permiten la utilizaci
on de estrategias de seguridad no extrapolables a redes de computadoras. El uso de listas blancas ha sido probado como un enfoque v
alido para asegurar
redes industriales. En este artculo presentamos un sistema visual de monitorizaci
on y detecci
on de anomalas de
flujo que utiliza listas blancas y diagramas de cuerdas para
mostrar el estado de la red. Por u
ltimo se utilizan datos
de una red industrial real para probar la efectividad del
sistema.
n
I. Introduccio
Los Sistemas de Control Industrial (SCIs) son el conjunto de elementos especializados que monitorizan y controlan procesos fsicos [1]. Como tal, son los responsables
de controlar y automatizar una gran variedad de procesos,
tanto en diferentes sectores industriales o en Infraestructuras Crticas (ICs) [2], generalmente en entornos conectados conocidos como redes industriales. El Consejo de la
Uni
on Europea [3] define los ICs como el elemento, sistema o parte de este (. . . ) que es esencial para el mantenimiento de funciones sociales vitales, la salud, la integridad
fsica, la seguridad, y el bienestar social y econ
omico de
la poblacion y cuya perturbacion o destrucci
on afectara
gravemente a un Estado miembro al no poder mantener
esas funciones;. Ejemplos de infraestructuras crticas incluyen la generacion y transporte de energa, el suministro
de agua, sistemas de transporte o plantas de fabricaci
on
crticas.
Tradicionalmente, las redes industriales han formado
entornos aislados, con protocolos de red, software y hardware propietarios. Sin embargo, los SCIs han ido evolucionando hacia la utilizacion de sistemas de software y red
est
andares, y hoy en da las redes industriales comparten
importantes similitudes con redes de computadoras tradicionales y estan cada vez mas conectadas a ellas. Esto
significa que el aislamiento tradicional en el cual las redes
industriales se han basado para su proteccion ya no es tal;
las redes industriales no estan tan aisladas. Por ello, la
superficie de ataque a estas redes ha aumentado.
Los incidentes de seguridad relacionados con redes industriales han mostrado el gran impacto que puede lle-
59
gar a tener un ataque exitoso, desde perdidas econ

omicas,
a da
nos medioambientales o incluso perdida de vidas humanas [4]. El avance reciente de las Amenazas Persistentes
Avanzadas (APTs por sus siglas en ingles) como Stuxnet
[5], Night Dragon [6] o Havex [7] que tienen como objetivo
las redes industriales, bien para sabotearlas o para el robo
de de informaci
on, hace a
un m
as necesaria la proteccion
de estos sistemas.
Aunque las redes industriales y las redes de ordenadores
tradicionales comparten tecnologas en gran medida, la
distinta naturaleza de las redes requiere que las soluciones
de seguridad que se aplican en una u otra tengan que ser
dise
nadas para adecuarse al tipo de red. Las diferencias
entre los dos tipos de red y el impacto que ello supone a la
hora de dise
nar soluciones de seguridad es analizado por
Cheminod et al [8].
Cuando se comparan las redes industriales con redes
tradicionales de ordenadores, se puede apreciar que la
topologa de de la red industrial es est
atica, a la vez que
el tr
afico de red cuenta con unos patrones de comportamiento muy definidos ya que la mayora del tr
afico de
red lo crean procesos autom
aticos [8], [9].
Teniendo en cuenta estos rasgos de las redes industriales, se puede hacer uso de ellas para dise
nar soluciones de
seguridad, que aunque v
alidas para las redes industriales,
podran no ser eficientes en otros tipos de red. Especificamente, la pr
actica del whitelisting o listas blancas1 ha
sido defendido por la industria como un metodo efectivo
de asegurar redes industriales [2], [10], hecho que fue demostrado por Barbosa et al. [9].
A. Contribuci
on y organizaci
on del artculo
En este artculo proponemos un sistema novedoso de
monitorizaci
on visual de redes industriales a gran escala
para monitorizar flujos de red y detectar anomalas relacionadas. Para ello nos valemos de listas blancas y diagramas de cuerdas. Nuestra principal contribuci
on consiste
en la creaci
on de listas blancas temporales y la utilizacion
de diagramas de cuerdas para la visualizaci
on de flujos
de red industriales y sus anomalas. En consecuencia,
este artculo pretende cubrir el vaco actual en sistemas
de monitorizaci
on para la seguridad visuales en redes in1 Es la pr
actica de registrar una serie de flujos de red permitidos
y no permitir ninguna otra conexi
on o notificar mediante una alerta
cuando se produce una conexi
on no permitida
JNIC2015

2
dustriales.
El resto del artculo esta organizado de la siguiente
manera: la seccion II presenta diferentes detectores de
anomalas que utilizan informacion de flujo, junto con una
introducci
on a los diagramas de cuerdas y su uso en el
campo de la seguridad de redes. La seccion III analiza la
estructura del sistema de monitorizacion, as como su funcionamiento. La seccion IV muestra las pruebas realizadas
al sistema con datos de trafico industrial real. Por u
ltimo,
la secci
on V extrae unas conclusiones finales e identifica
unas posibles vas de trabajo futuro.
II. Trabajos relacionados
A. Detecci
on de anomalas de flujo en redes industriales
Barbosa et al. [9] demostraron que el uso de listas
blancas es un metodo efectivo para detectar anomalas
de flujo en redes industriales. Ha habido diferentes sistemas de deteccion de intrusiones para redes industriales
que se han valido de informacion de flujo para detectar
anomalas: Garitano et al. [11] utilizan la informaci
on
de flujo contenida en forma de reglas de Snort para alertar sobre conexiones anomalas. Hoeve [12] extrae la informaci
on de flujo de red y sus patrones, para detectar
anomalas que quedan fuera de los patrones en tr
afico de
control cifrado. SPEAR [13] utiliza la informaci
on de la
topologa de red e informacion de flujo introducida a mano
para detectar anomalas de flujo mediante la creaci
on de
reglas para Snort.
Sin embargo, ninguna de las propuestas se
naladas presenta los resultados de la deteccion ni el estado de la red
de manera visual.
B. Diagramas de cuerdas
Los diagramas de cuerdas, tambien conocidos como diagramas Circos, son diagramas circulares que representan las interrelaciones entre diferentes entidades. Aunque
originalmente fueron dise
nadas para ser utilizadas en
gen
omica [14], el uso de los diagramas de cuerdas se ha
extendido a diferentes campos.
Las entidades visualizadas estan ordenadas de manera
circular. Cada entidad ocupa una longitud de arco diferente en funcion del peso que tiene en relacion al resto de
entidades.
Las cuerdas son uniones que conectan las diferentes entidades que forman el crculo. Cada cuerda une generalmente dos entidades diferentes, y la anchura de la cuerda
en cada borde indica la naturaleza de la uni
on. Si uno
de los bordes de la cuerda tiene una mayor anchura, la
entidad de ese lado tiene una posicion mas dominante.
Por ejemplo, en el caso de que una cuerda represente
una relacion mercantil entre dos estados, el estado con
la cuerda mas ancha en su base enva mas bienes hacia el
estado con la anchura mas peque
na que viceversa.
En el campo de la ciberseguridad, los diagramas de cuerdas se han utilizado en diferentes tipos de sistemas de visualizaci
on, pero su uso no esta tan extendido como otros
tipos de diagramas.
Mazel et al. [15] utilizan diagramas de cuerdas para
realizar una comparativa visual de diferentes sistemas de
60
detecci
on de anomalas y su rendimiento.
El trabajo de Layton et al. [16] representa las relaciones
entre grupos de p
aginas webs de phishing mediante diagramas de cuerdas.
OCEANS [17] utiliza diagramas de cuerdas para representar flujos de redes entre diferentes subredes. Sin embargo, es una soluci
on orientada a redes tradicionales de
ordenadores y se limita a mostrar los flujos de red existentes, pero sin mostrar la informaci
on de flujos de hosts
individuales ni resaltar las anomalas.
De momento, no hay ejemplos de sistema de visualizaci
on de flujos orientado a la seguridad para redes industriales, menos a
un utilizando diagramas de cuerdas. Sin
embargo, se est
an haciendo varios avances para mejorar
la monitorizaci
on visual de procesos industriales [18].
n del sistema
III. Descripcio
La figura 1 muestra el flujo de trabajo del sistema de
monitorizaci
on y visualizaci
on presentado.
En primer lugar, dispositivos de red con capacidad de
registrar flujos de red envan paquetes con la informacion
de flujo a un recolector de flujos que almacena luego
estos en un servidor de flujos. El envo se puede realizar
desde diferentes redes industriales, permitiendo la monitorizaci
on central de las redes industriales.
Una vez empezada la recolecci
on de flujos, mediante
una consulta al servidor de flujos se crea las polticas de
whitelisitng con los primeros flujos recogidos de la red. A
esta fase la hemos llamado la fase de aprendizaje. Una
vez que las polticas se han creado y se siguen registrando
nuevos flujos de red, se realizan consultas adicionales al
servidor de flujos para obtener los u
ltimos resultados y
luego los compara con las polticas establecidas en las listas blancas para detectar si los flujos nuevos son legtimos
o no, etiquetando cada flujo como legtimo o ilegtimo.
Esta fase es la fase de detecci
on. Finalmente, una vez los
flujos est
an etiquetados, el sistema crea una serie de diagramas de cuerdas para representar los resultados. Mientras que la fase de aprendizaje ocurre una u
nica vez por
red monitorizada, las fases de detecci
on y visualizaci
on se
repiten peri
odicamente en el tiempo.
A. Fase de aprendizaje
En esta fase, se crea una lista blanca de flujos a partir de los primeros flujos detectados en una red industrial
en un periodo de tiempo determinado. La duraci
on adecuada del periodo de tiempo depende del tipo de proceso
que controla la red. En procesos por lotes cortos, la duraci
on necesaria para recoger todos los flujos importantes
es menor que en procesos m
as largos o contnuos, ya que
los ciclos de la red ser
an tambien m
as cortos.
La lista blanca es generada en formato CSV, de este
modo, un operador humano puede a
nadir flujos de red que
considere oportunos, o borrar los flujos de red registrados
que deben ser consideraros an
omalos.
En las listas blancas, se guarda la siguiente informacion
por cada flujo: direcci
on IP origen, direcci
on IP destino,
puerto del servidor, tipo de protocolo IP y el n
umero paquetes de red un intervalo de tiempo dado. No se tiene en
JNIC2015

3
Redes
Industriales
Recolectores
de flujos
Servidor
de flujos
Flujos
etiquetados
Flujos de
red
Diagramas
de cuerdas
Paquetes
de flujo
Fase de deteccin
Datos de flujos
Fase de
visualizacin
Paquetes
de flujo
En lnea
Fase de aprendizaje
Fuera de lnea
Listas blancas
Fig. 1: Vista general del sistema de monitorizaci

on de flujos.
cuenta el puerto del cliente, ya que se asigna de manera aleatoria y etiquetar flujos validos como an
omalos
por tener un n
umero de puerto cliente distinto dara falsos positivos. Barbosa et al. [9] no tienen en cuenta
el n
umero de paquetes para la elaboracion de la lista
blanca, sin embargo, este sistema s lo contempla. Consideramos el n
umero de paquetes un atributo importante
por dos razones: en primer lugar, para poder utilizar este
n
umero como una metrica a de visualizacion (as ayudara
a mostrar visualmente flujos mas y menos activos); y en
segundo lugar, puede ayudar a detectar anomalas de flujo
relativas al tama
no (ataques de denegacion de servicio, o
la cada de un dispositivo).
A.1 Listas blancas con datos de flujo temporales
Sin embargo, la utilizacion del n
umero de paquetes existente en un flujo complica la utilizacon de las listas blancas. El n
umero de paquetes detectado en el flujo es un
dato temporal, es decir, dependiente de la duraci
on de
la captura (cuanto mayor sea el tiempo monitorizado del
flujo, mayor sera el n
umero de paquetes que aparecen en
el). Por ello, es necesario establecer una validez de un espacio de tiempo a cada lista blanca, en la cual puede ser
utilizada. En otras palabras, una lista blanca es solo relevante si el tiempo de captura que se ha utilizado para su
elaboracion es de la misma duracion que los datos de flujo
capturados con los que se compara. Por ejemplo, si una
lista blanca registra la actividad de una red los primeros
diez minutos de una red industrial, es necesario que las
capturas de flujos posteriores tengan tambien la misma
duraci
on para poder comparar correctamente el n
umero
de paquetes registrado en el flujo.
Hay dos formas diferentes de abordar esta cuesti
on:
1. Se crea una u
nica lista blanca por red, con los datos registrados de una duracion u
nica. Todos los datos de flujos
entrantes se recogen, y mas tarde, al realizar las consultas, estos datos recogidos se dividen en pedazos donde la
duraci
on de la captura de cada pedazo es la misma que la
de la lista blanca. El pedazo mas reciente se compara con
61
los datos de la lista blanca y se crea un diagrama de red

con la informaci
on por cada red.
2. Se crean varias listas blancas por cada red, donde cada
lista blanca tiene una duraci
on diferente. Todos los datos
de flujos entrantes se recogen, y dependiendo de la lista
blanca con la que se quiere comparar se dividen en pedazos
de duraci
on diferentes. Los u
ltimos pedazos de cada duraci
on se compara con su lista blanca correspondiente. Se
crea un diagrama de cuerdas por cada pedazo de duracion
diferente.
La segunda es una opci
on m
as deseable, ya que ofrece
m
as granularidad, dando la oportunidad de monitorizar
diferentes ventanas de tiempo y de detectar anomalas que
pueden ser clasificadas como falsos negativos cuando se
utiliza una u
nica lista blanca. Por ejemplo, si un dispositivo de red est
a programado para enviar un gran n
umero
de paquetes de manera estacional durante periodos cortos,
pero debido a un fallo ese envo no cesa, las listas blancas de corta duraci
on permitir
an el tr
afico, ya que esta
registrado que el dispositivo enva ese tr
afico por periodos
cortos. Sin embargo, las listas blancas de mayor duracion
registraran que a largo plazo no es un tr
afico legtimo.
Por ello, proponemos un sistema que utiliza listas blancas con datos de red correspondiente a diferentes periodos
de tiempo. Sin embargo, el n
umero
optimo de listas blancas a utilizar, as como la duraci
on de la monitorizacion
de cada lista es un atributo que depende del proceso y
debera estudiarse para cada caso. No obstante, es importante recalcar que a mayores tiempos de aprendizaje
para construir las listas blancas, mayor es la probabilidad de registrar tr
afico malicioso o an
omalo en la red y
etiquetarlo como legtimo en la lista blanca.
B. Fase de detecci
on
En esta fase, se utilizan las listas blancas creadas en la
fase anterior para evaluar los datos de flujo entrantes. Los
datos de flujos se obtienen mediante consultas al servidor
de flujos. Peri
odicamente se obtienen los datos de flujos de
red correspondientes a los diferentes periodos de tiempo
JNIC2015

4
para los que se haya creado una lista blanca. Despues, se

comparan los datos de flujo de cada duracion con su lista
blanca correspondiente.
Por cada flujo detectado, el detector comprueba si los
datos del flujo estan registrados en la lista blanca. En el
caso de las direcciones origen y destino, puerto del servidor
y protocolo utilizado, la informacion de ambos flujos debe
ser exacta. En el caso del n
umero de paquetes registrados
hay una excepcion: los numeros de la lista blanca y del
flujo detectado no tienen que ser exactamente iguales, pero
tampoco pueden muy diferentes. El detector da la posibilidad de establecer un umbral en forma de porcentaje que
indica la tolerancia del detector a la diferencia del n
umero
de paquetes registrado. Flujos que difieren del flujo registrado en la lista blanca por un margen mayor que el
porcentaje establecido, son etiquetados como an
omalos,
mientras que los que quedan dentro de los lmites del umbral se consideran legtimos.
Si el flujo detectado es considerado valido, el flujo se etiqueta como legtimo y no se lanza ninguna alerta. Sin embargo, si se detecta un flujo que no ha sido registrado en la
lista blanca, el detector etiqueta ese flujo como an
omalo y
lanza una alerta. Ademas, el sistema tambien comprueba
si los flujos registrados en la lista blanca han sido detectados en la red durante ese periodo de tiempo. Si un flujo
registrado en la lista blanca no ha sido detectado, el flujo
se a
nade al grupo de flujos etiquetados como ausente y se
lanza una alerta. De esta forma se puede detectar cuando
hay problemas de conectividad en la red.
Se han creado las siguientes etiquetas en el detector,
basadas en las comparaciones entre las listas blancas y los
flujos registrados:
Flujo legtimo El flujo es legtimo seg
un la informaci
on
contenida en la lista blanca.
Flujo an
omalo Dos dispositivos se comunican entre s,
pero seg
un la lista blanca no deberan de hacerlo. Todos
los flujos relativos a un dispositivo desconocido se etiquetan como tal.
Puerto incorrecto Un dispositivo trata de conectarse a un
puerto diferente del habitual de un dispositivo con el que
tiene permitido comunicarse.
Protocolo incorrecto Un dispositivo trata de conectarse a
un dispositivo con el que puede comunicarse utilizando un
protocolo distinto del habitual.
Flujo ausente Un flujo registrado en la lista blanca no ha
sido detectado en el periodo de tiempo correspondiente a
la captura.
Tama
no de flujo an
omalo El n
umero de paquetes de un
flujo registrado en la lista blanca y el flujo detectado vara
m
as que el umbral establecido.
Cada etiqueta se utiliza para dar informaci
on acerca de
la raz
on por la que el flujo se considera no legtimo, tanto
en la alerta lanzada como en la visualizacion mostrada.
Una vez que todos los flujos han sido etiquetados, el detector traduce todas las direcciones IP de los dispositivos
a nombres de dispositivo para facilitar la comprensi
on de
los datos de flujo al usuario.
Finalmente, despues de la traduccion de nombres, el
sistema tiene un conjunto de flujos completamente etique-
62
tado. Esta informaci

on etiquetada se utiliza en la siguiente
fase (la de visualizaci
on) para construir el diagrama de
cuerdas que muestra los flujos de red con sus anomalas
detectadas.
C. Fase de visualizaci
on
En esta fase, cada uno de los conjuntos etiquetados de
flujos de red es mostrado en forma de un diagrama de
cuerdas.
En primer lugar, cada uno de los dispositivos activos en
la red obtiene una secci
on de la circunferencia que forma
el exterior del diagrama de cuerdas. La longitud de arco
es proporcional al porcentaje de paquetes que el host ha
enviado en el periodo que ha durado la captura; los dispositivos que envan m
as paquetes ocupan una longitud de
arco mayor. Una vez que los dispositivos han sido colocados en el diagrama, es necesario representar los flujos
entre ellos.
Para ello se utilizan las cuerdas: cada flujo de red bidireccional est
a representado con una cuerda que une dos
dispositivos diferentes. Si dos dispositivos se comunican
con diferentes flujos (conexiones a puertos diferentes, uso
de protocolos distintos), se sigue visualizando una u
nica
cuerda que aglutina los flujos entre los mismos dispositivos.
La anchura en los bordes de la cuerda, viene dado
tambien por el n
umero de paquetes que enva. Por ejemplo, si en un flujo dado el Dispositivo A manda m
as paquetes que el Dispostivo B, la anchura ser
a mayor en el
borde del lado del Dispositivo A. De manera similar, los
flujos m
as activos estar
an representados con cuerdas mas
anchas, ya que los actores m
as activos tendr
an bordes mas
anchos. El diagrama es interactivo, cuando el usuario pasa
el rat
on por encima de un flujo, el diagrama muestra informaci
on b
asica acerca del flujo: nombre de los dispositivos implicados, n
umero de paquetes enviados en cada
direcci
on. . .
La figura 2 muestra un diagrama de cuerdas completo
donde todos los flujos detectados en su periodo de tiempo
han sido etiquetados como legtimos. Se puede apreciar
como la anchura de las cuerdas y sus bordes vara de un
flujo a otro dependiendo de la actividad del flujo.
En el caso de flujos de red no legtimos, se rellena de
color rojo, como se muestra en la figura 3. Por un lado
la figura 3a representa como el color rojo destaca entre
el resto de colores de los flujos legtimos. Por otro lado,
la figura 3b muestra la interactividad del gr
afico: el diagrama filtra los flujos relevantes de un dispositivo y muestra el aviso acerca de la raz
on por la que el flujo ha sido
etiquetado como no legtimo, cuando el usuario selecciona
el flujo. Como se ha comentado anteriormente, est
a informaci
on adicional se toma de la etiqueta que ha asignado el
detector. En este caso, la lista blanca no permite ning
un
tr
afico entre los dispositivos PLC 1 y HMI 2.
Con la excepci
on de los flujos con la etiqueta de Flujo
ausente, todos los flujos no legtimos se ti
nen de rojo
para que destaquen entre el resto de flujos. Sin embargo,
debido a la naturaleza diferente de los flujos etiquetados
como ausentes, estos flujos son representados te
nidos de
JNIC2015

5
(a) Flujo prohibido entre PLC 1 y HMI 2.
(b) Detalle del flujo an

omalo
Fig. 3: Representaci
on de un flujo de red an
omalo.
Switch 2
Switch 1
Gateway
Fig. 4: Topologa de red de la red industrial de prueba.

Fig. 2: Diagrama de cuerdas representando un conjunto
de flujos de red legtimos.
negro (ver figura 7). Ademas este tipo de flujos son los
u
nicos en los que se utiliza la informacion de la lista blanca
para representarlos, ya que en los datos recogidos no hay
datos que impliquen a esos flujos.
n en una red industrial
IV. Applicacio
Esta seccion prueba la solucion presentada anteriormente con datos reales de una red industrial.
63
A. Red de prueba
Realizar pruebas de seguridad en una red industrial real
y en marcha puede ocasionar consecuencias inesperadas,
como fallos en el funcionamiento de la red o situaciones
potencialmente peligrosas [19]. Adem
as de momento, no
hay ningun conjunto de datos est
andar con datos reales
de flujo de una red industrial con varios dispositivos. Por
ello, se ha duplicado la red de control de una instalacion
industrial real para realizar las pruebas en un entorno de
laboratorio. La red original es la red de control de una
lnea de pintado de coches de una planta de fabricaci
on.
La figura 4 muestra la topologa de red de la red de
prueba. Los switches son los dispositivos de red que envan
los paquetes de flujo a los recolectores. En esta red se
JNIC2015

6
utiliza NetFlow de Cisco, version 5 para el envo de la

informaci
on de flujo. Ademas el Switch 1 es adem
as el
servidor DNS de la red.
Hay tres controladores logicos programables (PLCs) en
la red, que son los responsables del control de proceso industrial. Dos servidores de control extraen la informaci
on
del proceso a los tres PLCs simultaneamente. La comunicaci
on entre los servidores y los controladores se realiza
mediante el protocolo Modbus/TCP
Tambien hay tres interfaces maquina-humano (HMIs)
en la red, que permite que los operadores puedan supervisar el proceso y sus variables de una manera visual y
accesible. HMI 1 recoge los datos del Servidor 1, el HMI
2, del Servidor 2 y, por u
ltimo, el HMI 3 recoge datos de
ambos servidores. La comunicacion entre los HMIs y los
servidores es mediante el protocolo OPC.
Una puerta de enlace o gateway conecta la red industrial
con redes exteriores, donde se encuentra en este caso el
recolector de flujos.
ambos dispositivos est

a permitida, sobrepasa el n
umero
de paquetes permitidos. Al ser el n
umero de paquetes enviados mayor, el HMI 3 ocupa una mayor secci
on del arco
y la cuerda del flujo an
omalo es m
as ancha en su lado.
B. Implementaci
on del sistema
Como se ha comentado, los flujos en el sistema de
prueba son NetFlow version 5. Los switches mandan los
paquetes de flujo de red a agentes de Logstash2 que, actuando como recolector de flujos, los recibe, los analiza y
despues los indexa en un cluster de ElasticSearch3 . Este
enfoque permite el uso de sistema de monitorizaci
on a
gran escala y permite que las consultas se puedan realizar
de manera rapida. El sistema de visualizaci
on que forma
los diagramas de cuerdas ha sido desarrollado utilizando
la librera D3 [20].
Fig. 5: Visualizaci
on de un ataque de denegaci
on de servicio.
C.2 Descubrimiento de red
En esta seccion se muestran diagramas de cuerdas en

tres casos anomalos diferentes: un ataque de denegaci
on
de servicio (DoS), un escaneo de la red con el objetivo de
enumerar los dispositivos presentes en la red y un fallo en
la red donde un dispositivo deja de estar disponible. En
estas pruebas todas las listas blancas y muestras de red
han sido tomados en un periodo de diez minutos y con un
umbral del 20% como variacion maxima permitida en el
n
umero de paquetes registrados en un flujo.
El descubrimiento de dispositivos es uno de los primeros

pasos que un atacante ejecuta cuando obtiene acceso a una
red desconocida para poder obtener informaci
on acerca de
ella. El escaneo de puertos es una de las tecnicas m
as utilizadas para el descubrimiento. En esta prueba se realiza
un escaneo de puertos TCP Connect con Nmap desde el
HMI 3.
La representaci
on del ataque puede verse en la figura
6. Todos los flujos que incluyen a HMI 3 est
an marcados
como an
omalos, bien porque tiene prohibida la comunicaci
on con la mayora de hosts (p. ej. los PLCs) o porque
utiliza puertos y/o protocolos diferentes para comunicarse
con dispositivos con los que s tiene permitida la comunicaci
on.
C.1 Denegacion de Servicio
C.3 Dispositivo no disponible
Los ataques de denegacion de servicio ocurren cuando

un atacante intenta obstruir el funcionamiento real de
un dispositivo o servicio dejandolo no disponible para los
agentes legtimos. En redes industriales, donde la disponibilidad es el principal objetivo de la seguridad y donde
problemas de latencia de red pueden crear problemas importantes de red, este tipo de ataques son muy peligrosos.
En este caso, imitamos un ataque de denegaci
on de servicio mediante el envo de grandes cantidades de paquetes
ilegtimos del HMI 3 al Servidor 1.
El resultado de la visualizacion del ataque est
a en la
figura 5. El flujo que muestra el ataque se muestra rellenado de color rojo, ya que aunque la comunicaci
on entre
Por u
ltimo, consideramos el caso donde un dispositivo
tiene problemas de conectividad y no es capaz de comunicarse con la red y, por lo tanto, de enviar o recibir paquetes. Para la realizaci
on de esta prueba, se ha desconectado
fsicamente el Servidor 1 de la red.
La figura 7 muestra como los flujos del dispositivo cado
han sido etiquetados como ausentes, y como tal, te
nidos
de negro. Para poder visualizar los datos de los flujos
implicados, se han utilizado los datos registrados en la
lista blanca.
C. Anomalas de red
2 https://github.com/elastic/logstash
3 https://github.com/elastic/elasticsearch
64
V. Conclusiones y trabajos futuros

Hemos presentado un sistema para la monitorizaci
on de
flujos de red que se vale de diagramas de cuerdas y listas
blancas. Para ello, primero se elaboran una serie de listas
JNIC2015

7
A. Trabajos futuros
La informaci
on relativa a los puertos y protocolos es
utilizada para la detecci
on de anomalas, pero en la visualizaci
on no muestra la informaci
on relativa a ellas. La
inclusi
on de estas caractersticas aumentara la cantidad
de informaci
on que el operador recibe de manera visual,
pero tambien aumenta el riesgo de complicar las visualizaciones demasiado, hasta el punto de no poder cumplir
su cometido.
Las listas blancas se crean al principio de la recoleccion
de flujos y no son directamente editables desde la interfaz visual. Sin embargo, es interesante ofrecer al usuario
esta opci
on de editar las listas blancas para poder permitir flujos marcados como ilegtimos si el operador puede
determinar su legitimidad y no ha sido detectado en la
fase de aprendizaje.
Referencias
Fig. 6: Visualizacion de un escaneo de puertos.

[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
Fig. 7: Visualizacion de un dispositivo cado.

[9]
blancas temporales que tienen en cuenta el n

umero de paquetes registrados, junto con las direcciones de red, puertos de servicio y protocolos IP que permite la detecci
on
de anomalas relacionadas con flujos de red. Todos los flujos se etiquetan utilizando la lista blanca como referencia
(legtimo, anomalo, puerto o protocolo incorrecto, ausente
y tama
no de flujo anomalo).
Estos datos etiquetados se utilizan para producir diagramas de cuerdas que representan relaciones de red entre
dispositivos diferentes, en donde el n
umero de paquetes de
red es la principal metrica para producir el diagrama, especialmente para establecer el tama
no de las cuerdas. El
sistema de etiquetado tambien tiene un codigo de colores
que hacen que los flujos anomalos destaquen con colores
diferentes (en rojo o negro) y tambien proporciona informaci
on acerca de la razon por la que el flujo ha sido etiquetado como no legtimo, tanto en la visualizaci
on como
en las alertas lanzadas.
65
[10]
[11]
[12]
[13]
[14]
[15]
A. C
ardenas, S. Amin, and S. Sastry, Research Challenges for
the Security of Control Systems., in HotSec, 2008.
K. Stouffer, J. Falco, and K. Scarfone, Guide to Industrial
Control Systems (ICS) Security, Special publication 800-82,
tech. rep., National Institute of Standards and Technology,
June 2011.
Consejo de la Uni
on Europea, Directiva 2008/114/CE del
Consejo de 8 de diciembre de 2008 sobre la identificaci
on y designaci
on de infraestructuras crticas europeas y la evaluaci
on
de la necesidad de mejorar su protecci
on, Diario Oficial de la
Uni
on Europea, vol. L345, pp. 7582, Diciembre 2008.
B. Miller and D. Rowe, A survey of SCADA and Critical Infrastructure incidents, in Proceedings of the 1st Annual conference on Research in information technology, pp. 5156, ACM,
2012.
N. Falliere, L. O. Murchu, and E. Chien, W32.Stuxnet
dossier, White paper, Symantec Corp., Security Response,
2011.
McAfee, Global Energy Cyberattacks: Night Dragon (white
paper), tech. rep., McAfee, 2011.
D. Hentunen and A. Tikkanen, Havex Hunts For ICS/SCADA
Systems, June 2014. [Online]. Available: http://www.fsecure.com/weblog/archives/00002718.html (Retrieved: 201507-26).
M. Cheminod, L. Durante, and A. Valenzano, Review of Security Issues in Industrial Networks, IEEE Transactions on
Industrial Informatics, vol. 9, no. 1, pp. 277293, 2013.
R. R. R. Barbosa, R. Sadre, and A. Pras, Flow Whitelisting
in SCADA Networks, International Journal of Critical Infrastructure Protection, vol. 6, no. 3, pp. 150158, 2013.
M. Herrero Collantes and A. L
opez Padilla, Protocolos y Seguridad de red en infraestructuras SCI, tech. rep., INCIBE:
Instituto Nacional de Ciberseguridad, Mayo 2015.
I. Garitano, M. Iturbe, I. Arenaza-Nu
no, R. Uribeetxeberria,
and U. Zurutuza, Sistema de Detecci
on de Anomalas para
protocolos propietarios de Control Industrial, in XIII Spanish Meeting on Cryptology and Information Security (RECSI
2014), (Alicante, Spain), pp. 315320, University of Alicante,
Sep 2014.
M. Hoeve, Detecting Intrusions in Encrypted Control Traffic,
in Proceedings of the First ACM Workshop on Smart Energy
Grid Security, SEGS 13, (New York, NY, USA), pp. 2328,
ACM, 2013.
B. Genge, D. A. Rusu, and P. Haller, A connection patternbased approach to detect network traffic anomalies in critical
infrastructures, in Proceedings of the Seventh European Workshop on System Security, (Amsterdam, Netherlands), ACM,
2014.
M. Krzywinski, J. Schein, I. Birol, J. Connors, R. Gascoyne,
D. Horsman, S. J. Jones, and M. A. Marra, Circos: an information aesthetic for comparative genomics, Genome Research,
vol. 19, no. 9, pp. 16391645, 2009.
J. Mazel, R. Fontugne, and K. Fukuda, Visual comparison of
network anomaly detectors with chord diagrams, in Proceed-
JNIC2015

8
[16]
[17]
[18]
[19]
[20]
ings of the 29th Annual ACM Symposium on Applied Computing, pp. 473480, ACM, 2014.
R. Layton, P. Watters, and R. Dazeley, Unsupervised authorship analysis of phishing webpages, in Communications and
Information Technologies (ISCIT), 2012 International Symposium on, pp. 11041109, IEEE, 2012.
S. Chen, C. Guo, X. Yuan, F. Merkle, H. Schaefer, and T. Ertl,
OCEANS: online collaborative explorative analysis on network
security, in Proceedings of the Eleventh Workshop on Visualization for Cyber Security, pp. 18, ACM, 2014.
T. Tack, A. Maier, and O. Niggemann, On Visual Analytics
in Plant Monitoring, in Informatics in Control, Automation
and Robotics, pp. 1933, Springer, 2014.
D. Duggan, M. Berg, J. Dillinger, and J. Stamp, Penetration
testing of industrial control systems, Tech. Rep. SAND20052846P, Sandia National Laboratories, March 2005.
M. Bostock, V. Ogievetsky, and J. Heer, D3 data-driven documents, Visualization and Computer Graphics, IEEE Transactions on, vol. 17, no. 12, pp. 23012309, 2011.
66
JNIC2015

1
Correlacion de Alertas en la Deteccion de Malware

en Redes basadas en Anomalas
Jorge Maestre Vidal, Ana Lucila Sandoval Orozco and
Luis Javier Garca Villalba, Senior Member, IEEE
Grupo de Analisis, Seguridad y Sistemas (GASS, http://gass.ucm.es)
Departamento de Ingeniera del Software e Inteligencia Artificial (DISIA)
Facultad de Informatica, Despacho 431, Universidad Complutense de Madrid (UCM)
Calle Profesor Jose Garca Santesmases, 9, Ciudad Universitaria, 28040 Madrid, Espa
na
E-mail: jmaestre@ucm.es, {asandoval, javiergv}@fdi.ucm.es
Resumen En este trabajo se presenta un marco para la
correlaci
on de alertas emitidas por sistemas de detecci
on
de anomalas en redes basados en el an
alisis estadstico de
la carga u
til del tr
afico. La estrategia propuesta tiene en
cuenta las caractersticas de los modelos construidos durante el entrenamiento de los sensores. Las alertas son
analizadas de manera individual y en grupo, en dos niveles
de procesamiento relacionados entre s. El primero ofrece
respuestas r
apidas a nivel de paquete; el segundo facilita
la reconstrucci
on de escenarios de ataques. Para su evaluaci
on se ha procesado tr
afico real de la Universidad Complutense de Madrid.
n
I. Introduccio
En los u
ltimos a
nos el malware ha experimentado un
importante crecimiento. Seg
un la Agencia Europea de
Seguridad de las Redes y de la Informacion (ENISA), el
software malicioso se ha convertido en la principal amenaza para las tecnologas de la informacion actuales [1].
Esto es debido a que cada vez mas usuarios se apoyan
en estos servicios para llevar a cabo actividades de especial sensibilidad, como comercio electronico o accesos
a informacion confidencial. Ademas el malware es mucho m
as sofisticado, habiendo adquirido mayor capacidad
de propagacion, infeccion y elusion de mecanismos defensivos. En consecuencia, asegurar la eficacia de los sistemas
de detecci
on convencionales a menudo requiere de su complementacion por medio de otras herramientas, de entre
las que destacan los sistemas de correlacion de alertas.
Los sistemas de correlacion de alertas facilitan la gesti
on
de las alertas emitidas por los sistemas de detecci
on de
intrusiones, mejorando as la decision de las contramedidas
a aplicar [2]. En la u
ltima decada se ha publicado una
gran cantidad de propuestas al respecto. Pero a pesar de
ser un problema ampliamente estudiado, la mayor parte
de los esfuerzos realizados abordan soluciones de
ambito
general, que a menudo son inefectivos en casos de uso
reales. Algunas de las principales causas de este problema
se enumeran en [3], destacando el crecimiento del volumen
de informacion a tratar, la gestion de una mayor cantidad
de alertas o su heterogeneidad.
La propuesta realizada se centra en el problema de la
correlaci
on de alertas en sistemas de detecci
on de intrusiones basados en el analisis estadstico de la carga u
til
67
del tr
afico que circula por una red, en busca de contenidos
an
omalos. Su elaboraci
on ha sido motivada por la necesidad de complementar la herramienta de detecci
on APAP
desarrollada por nuestro grupo de investigaci
on [4]. En
base a esto se propone un marco para correlacionar incidencias, adaptado a sensores de caractersticas similares.
La propuesta gestiona las alertas en un esquema multinivel, que permite su an
alisis individual y en grupos. Su
eficacia ha sido demostrada en un caso de uso real, con
tr
afico de la Universidad Complutense de Madrid (UCM).
El resto del artculo est
a estructurado de la siguiente
manera: en la secci
on 2 se describen los trabajos relacionados. En la secci
on 3 se propone un marco para correlacionar sus alertas. En la secci
on 4 se describe el escenario
de evaluaci
on. En la secci
on 5 se discuten los resultados
obtenidos. Finalmente, en la secci
on 6 se presentan las
conclusiones.
II. Trabajos Relacionados
Recientemente se han publicado diferentes estados del
arte relacionados con la gesti
on de las alertas emitidas
por sistemas de detecci
on de intrusiones. Algunos de ellos ofrecen una visi
on general, como es el caso de [2],
[3]. Sin embargo otros hacen hincapie en aspectos mas
especficos, como en la colaboraci
on entre sensores [5], o
la reducci
on de su tasa de falsos positivos [6]. A lo largo
de la bibliografa, los sistemas de correlaci
on de alertas
han sido agrupados de manera muy similar a la propuesta
en [2], donde su eje de clasificaci
on est
a determinado por
los metodos de correlaci
on. En base a este criterio se distinguen tres grandes grupos: estrategias basadas en similitud, metodos secuenciales o casos.
La correlaci
on basada en similitud habitualmente se
centra en la agrupaci
on y reducci
on de las alertas emitidas. Para ello se tienen en cuenta diferentes atributos
o caractersticas, que abarcan desde las direcciones IP y
puertos relacionados con la intrusi
on, hasta la frecuencia
de aparici
on de ciertos patrones en su contenido. En [7]
se observa un claro ejemplo, donde adem
as de estos atributos, son considerados otros rasgos, como su protocolo o
prioridad de tratamiento. En [8] se aplican caractersticas
parecidas al tratamiento de eventos de redes m
oviles. La
JNIC2015

2
correlaci
on basada en similitud a menudo tambien tiene
en consideracion las relaciones espacio-temporales de las
incidencias. Un ejemplo de ello se encuentra [9], donde
a partir de estas caractersticas es posible inferir el escenario del ataque. Otras propuestas toman como referencia
atributos propios del sistema de deteccion. Este es el caso
de [10], donde la correlacion se realiza a partir de una
versi
on comprimida del conjunto de muestras que ha participado en el entrenamiento del sensor.
El an
alisis secuencial de alertas tiene en cuenta las relaciones de causalidad de los incidentes, y se basa en el estudio de sus precondiciones y postcondiciones. Se definen
como precondiciones al conjunto de requisitos necesarios
para desencadenar una amenaza. Las postcondiciones son
las consecuencias de su ejecucion. En [11] se muestra un
claro ejemplo de esta metodologa, donde mediante el enlace de prerrequisitos y postcondiciones de diferentes alertas, es posible la construccion de escenarios de ataques.
En [12] esto se lleva a cabo mediante la elaboraci
on de matrices de correlacion causal. Otra representaci
on com
un
son los grafos. En [13] se profundiza en esta tendencia,
y se propone la aplicacion de grafos de incidencias generalizados basados en las relaciones de dependencia entre alertas. La construccion del escenario del ataque a
menudo involucra la aplicacion de diferentes estrategias,
como sucede en [14] mediante el uso de gram
aticas, o en
[15] con algoritmos de minera de datos, haciendo especial
hincapie en la logica difusa.
Los metodos basados en casos se fundamentan en bases
del conocimiento, denominadas en este contexto como
bases de casos. Por lo tanto, dependen de algoritmos
encargados de reconocer los patrones especficos de comportamiento representados en ellas. Un ejemplo de ello
se observa en [16], donde los escenarios de ataques que
integran la base de casos son construidos a partir de agrupaciones de incidencias. La propuesta infiere futuras amenazas, lo que permite actualizar la base del conocimiento
con nuevas intrusiones. En [17] se introduce una aproximaci
on similar, centrada en la actualizacion autom
atica
de grafos de dependencias. En [18] se aplican algoritmos
de agrupamiento para clasificar las incidencias en funci
on
de la base de casos, con el fin de priorizar su tratamiento.
n de Alertas
III. Marco para la Correlacio
El marco propuesto para la gestion de incidencias se
adapta a las particularidades de las herramientas de detecci
on de malware basadas en anomalas. En consecuencia, han sido consideradas las siguientes asunciones:
Los sensores a complementar presentan arquitectura centralizada. Existen pocas contribuciones que
planteen esquemas colaborativos. Adem
as, el an
alisis
centralizado predomina en las publicaciones de mayor
relevancia.
Los sensores analizan el tr
afico paquete a paquete. El
modelado de la red se basa en el estudio de su carga
u
til, por ser el campo que contiene el codigo malicioso.
Las peculiaridades de los sensores determinan las caractersticas que permiten establecer los modelos de uso.
A partir de las caracter
sticas de la carga u
til y del
68
entrenamiento de los sensores es posible inferir las

propiedades del malware.
Cuando la carga u
til de un paquete satisface ciertas
propiedades definidas en el entrenamiento, se emite una
alerta. Tambien se emiten alertas cuando la carga
u
til difiere considerablemente de los modelos de uso
legtimo.
Una amenaza puede llegar a la vctima repartida en
diferentes paquetes. Adem
as es frecuente que cada uno
de ellos desencadene una acci
on intrusiva diferente, pero
necesaria para que act
ue la siguiente.
Los sistemas de detecci
on robustos frente a metodos de
evasi
on a menudo operan de manera no determinista
para evitar ser enumerados. Tambien permiten reconocer algunas tecnicas de ocultaci
on basadas en oligomorfismo y metamorfismo, por medio de la identificacion
de la parte invariante de su vector de infeccion.
En el marco propuesto se analiza la informaci

on ofrecida
por las alertas en base a las caractersticas extradas por el
propio sensor, y una base del conocimiento. Por lo tanto
ambas herramientas deben compartir metricas y estrategias de modelado. Esto dificulta su escalabilidad, pero
tiene en cuenta que los sistemas de detecci
on basados en
anomalas a menudo ofrecen informaci
on muy especfica,
la cual tiene que ver con distancias entre modelos y reglas
de activaci
on, ad
aptandose de este modo mucho mejor a
los casos de uso reales.
A. Arquitectura
La aproximaci
on propuesta gestiona las incidencias en
base a dos criterios: la diferencia de la observaci
on con
los modelos de uso legtimo de la red, y su naturaleza.
Eso permite establecer dos componentes de an
alisis. El
primero lleva a cabo la correlaci
on en funci
on del grado
de anomala que muestran las observaciones que han causado alertas. Ha sido denominado componente de Diagn
ostico por Anomala (DA). El otro componente las
agrupa tomando como eje de clasificaci
on su naturaleza.
Ha sido denominado componente de Diagn
ostico por Naturaleza (DN). La arquitectura de la propuesta consta de
dos niveles de tratamiento de informaci
on, tal y como se
muestra en Fig. 1. El primero de ellos se encarga de
correlacionar incidencias individuales a nivel de paquetes.
En el participan los componentes DA y DN, y se proponen
los objetivos de agrupar, priorizar y distinguir las incidencias desencadenadas por falsos positivos. El segundo nivel
trata de identificar conjuntos de alertas relacionadas entre
s, derivadas de amenazas ejecutadas en diferentes pasos.
Por lo tanto depende de las caractersticas extradas en
el nivel anterior. Para asociar las incidencias se considera
una variante del componente DN que aplica una base del
conocimiento relacionada con amenazas en m
ultiples pasos. A pesar de su relaci
on, el resultado del an
alisis llevado
a cabo en cada nivel debe interpretarse de manera independiente. Esto es debido a que cada uno de ellos cubre
un caso de uso especfico. Adem
as es recomendable su implementaci
on mediante metodos de clasificaci
on no deterministas, que dificulten posibles intentos de enumeraci
on.
JNIC2015

3
La fase de agrupamiento se ejecutar

a cada vez que el
sistema de detecci
on emita una alerta. Esta es asignada
al grupo de alertas de mayor similitud.
Entorno Monitorizado
NIDS
C. Diagn
ostico por Naturaleza
Alertas
Sistema de correlacin
DA
DA
Paquetes
DNSimple
{distancia, naturaleza}
DNMltiple
Trazas
{amenaza}
Fig. 1
n de alertas.
Arquitectura del sistema de correlacio
B. Diagn
ostico por Anomala
El componente DA correlaciona las alertas a partir de
un proceso de agrupamiento asociado a los resultados del
entrenamiento del sistema de deteccion de intrusiones. Sea
D = {d1 , , dn }, tal que 0 < n el conjunto de trazas
de tr
afico procesadas por el sensor en su entrenamiento,
donde A = {a1 , , am } son sus muestras con contenido
maliciosos y L = {lm+1 , , ln } sus muestras legtimas,
tal que 0 < m < n.
DA opera en dos etapas: definicion de grupos y agrupamiento. En la fase de definicion de grupos se establecen
las posibles clasificaciones que realiza. Tiene lugar durante el entrenamiento de los sensores, donde a partir de
L se genera una representacion del modo de uso habitual
del entorno protegido, cuyas caractersticas m
as representativas son M L = {ml1 , , mlp } tal que 0 < p. En la
definici
on de grupos participa el modelo M L, y en ocasiones el conjunto A; esto u
ltimo dependera de su n
umero
de clases.
En el caso de considerar u
nicamente muestras legtimas,
es decir si |A| es poco representativo, los grupos se construyen en funcion de la distancia de las observaciones respecto a los umbrales que determinan si seran etiquetadas
como an
omalas o legtimas. Sin embargo, cuando |A| es
representativa, sus muestras tambien pueden tomar parte
del proceso de decision de grupos. A diferencia del caso
anterior, en esta situacion los algoritmos de agrupamiento
s
olo consideran las distancias de las muestras maliciosas
respecto del umbral de decision. Se trata de un esquema
habitualmente mas preciso, ya que las alertas emitidas por
los sensores siempre superan dichos margenes. De este
modo, y a diferencia del primer caso, los valores centrales
de los grupos siempre los superan.
69
La naturaleza de una anomala es el tipo de amenaza

que la desencadena. Para que el componente DN sea
capaz de su determinaci
on, se requiere de una base del
conocimiento sobre ataques, adecuada a las caractersticas
del entorno protegido. La naturaleza de las incidencias es
inferida a nivel de alertas y de trazas, tal y como se describe a continuaci
on:
Naturaleza de alertas. Sea U = {u1 , , up }, tal que
0 < p el conjunto de caractersticas en las que se
basa un detector para etiquetar un evento. A partir de ellas es posible determinar las propiedades P =
{p1 , , pn } de la amenaza. Cada propiedad pi , 0 <
i n es definida por un subconjunto de caractersticas
C = {c1 , , cm } tal que 0 < m, pertenecientes a
U . N
otese que las P propiedades act
uan como reglas
de detecci
on, mientras que las U caractersticas indican los valores que condicionan su activaci
on. En el
sistema propuesto la naturaleza de las amenazas es inferida por un conjunto de propiedades (o reglas). Estas son definidas mediante el entrenamiento del sistema de detecci
on a partir de una colecci
on de muestras de ataques representativa del tipo de intrusi
on a
tratar. Aplicando este procedimiento con diferentes
tipos de amenaza es posible la construcci
on de la base
del conocimiento del sistema de correlaci
on, la cual incluye todas las reglas que activan todas las amenazas
con las que ha sido entrenada. De este modo, cuando
el sistema de detecci
on emita una alerta bastar
a con
observar las caractersticas del malware que la han activado, para inferir un conjunto de reglas de la base de
casos, y a partir de ellas determinar su naturaleza.
Naturaleza de secuencias de alertas. La estrategia de
clasificaci
on de secuencias es similar a la que se lleva a
cabo a nivel de alertas. Esta

parte de la informacion
inicial, provista por el etiquetado realizado en el paso
anterior para cada una de las alertas que integran la
secuencia. En este componente tambien se construye
una base del conocimiento, solo que en esta ocasi
on las
caractersticas que activan las reglas son las etiquetas
del nivel de correlaci
on anterior, y las reglas son las
posibles secuencias que ha presentado la amenaza en
su entrenamiento
IV. Escenario de Pruebas
El sistema de detecci
on complementado ha sido APAP
[4]. A continuaci
on se describe la implementacion de cada
componente y la colecci
on de muestras aplicada:
Componente DA. A partir del modelado realizado por
APAP se establecen las caractersticas de la carga u
til
del tr
afico que circula por la red protegida. Los valores centrales de los grupos en que se etiquetan las
anomalas se generan considerando las distancias entre los umbrales de decisi
on del sensor y las caractersticas que presenta el conjunto de tr
afico malicioso.
JNIC2015

4
El agrupamiento se ha realizado mediante el algoritmo

K-medias. Al recibir alertas, el sistema de correlaci
on
las asigna al grupo de mayor similitud.
Componente DN para Alertas. El componente DN
para la correlacion de alertas ha sido implementado
mediante una red neuronal artificial. Dicha red consta
de n = 32 entradas, correspondientes con el total de
caractersticas que componen la metrica en que se basa
APAP para la construccion de modelos. La red neuronal presenta 3 capas (de las cuales una es oculta),
funci
on de activacion Elliot y tolerancia a error del
0.001. Ha sido entrenada con las reglas construidas
por el sensor, tras su entrenamiento con cada tipo de
amenaza y su salida asociada. Esto permite relacionar
las reglas inferidas por la emision de cada alerta, con
su naturaleza.
Componente DN para Secuencias de Alertas. Con el
fin de generar clasificaciones no deterministas, el componente DN ha sido implementado mediante un algoritmo genetico basico. Durante el entrenamiento de
APAP se ha establecido una tabla que asocia cada secuencia de alertas tratada, con el tipo de intrusi
on que
la desencadena. En el algoritmo genetico, el genotipo
de cada individuo es un vector que contiene las clasificaciones de todas las alertas de una secuencia de
ataques. De esta manera las etiquetas que m
as aparezcan en ella tendran mayor representacion. Cada vez
que APAP genera una secuencia de alertas, el algoritmo genetico construye una poblacion inicial de trabajo a partir de su genotipo. Los individuos son generados a partir de mutaciones arbitrarias sobre este.
A continuacion, realiza iteraciones que involucran las
operaciones de cruce y mutacion propias de este tipo de
algoritmos, hasta que alcanza su condicion de parada.
Esto sucede cuando se alcanza un n
umero m
aximo de
iteraciones o cuando un subconjunto representativo de
los individuos ha alcanzado la aptitud optima (este es
el caso en que la funcion de aptitud devuelve el valor
0). La funcion de aptitud viene dada por la mejor
distancia Levenshtein entre el genotipo del individuo y
las configuraciones presentes en la tabla.
Al concluir el algoritmo, la secuencia es clasificada
como perteneciente a aquellas intrusiones cuyos genotipos asociados hayan aparecido en la poblaci
on de trabajo. La probabilidad de que se trate de la etiqueta
correcta coincide con la probabilidad asociada a su frecuencia de aparicion en la poblacion.
A. Colecci
on de Muestras
Para la evaluacion del sistema se ha empleado una
colecci
on de capturas de trafico etiquetadas por el Centro de Procesamiento de Datos (CPD) de la Universidad
Complutense de Madrid, tomadas a lo largo del a
no 2011
en la subred de la facultad de informatica.
Las posibles alertas han sido divididas en 16 categoras:
troyano, escalada de privilegios, c
odigo ejecutable, denegaci
on de servicio, software privativo, enumeraci
on I, enumeraci
on II, virus, exploit, software privativo espa, acci
on
de control remoto, software privativo con accesos no au-
70
torizados, software con accesos no autorizados, spyware I,

spyware II, anomala desconocida.
Las secuencias de alertas pueden inferir 9 tipos de clasificaciones: botnet I, malware ofuscado, gusano, drive-by,
Adware, spyware, virus, botnet/troyano II, anomala desconocida. El 80% de las trazas disponibles han sido empleadas en el entrenamiento del sistema y el 20% restante
para su evaluaci
on.
V. Resultados
Durante la etapa de entrenamiento de APAP, en el componente DA se generaron 5 grupos de alertas. En funcion
de su proximidad con el umbral de decisi
on han sido etiquetadas con riesgos muy alto, alto, moderado, bajo y muy
bajo. Se han realizado dos pruebas con dicho componente.
La primera de ellas sirve para decidir la capacidad del sistema de identificar falsos positivos, e involucra el an
alisis
de las trazas legtimas etiquetadas err
oneamente como intrusiones. Por otro lado se han correlacionado las alertas
correspondientes a verdaderos ataques.
En Fig. 2 se muestran los resultados. El 95,7% de
las muestras legtimas analizadas han sido clasificadas exitosamente en los grupos de menor riesgo (muy bajo y
bajo). El 83,82% de las alertas por ataques verdaderos han
sido ubicadas correctamente en su grado de riesgo original. Los mayores errores han significado su asignaci
on al
grupo m
as pr
oximo del correcto. Esto permite una cierta
tolerancia a fallos. El tiempo de procesamiento medio por
muestra de APAP ha sido de 171,104 ms; al a
nadirle el
componente DA el an
alisis tarda 173,127 ms en los casos peores. Por lo tanto, la sobrecarga causada sobre el
sistema es inferior al 1%.
La distribuci
on de las clasificaciones de las alertas emitidas por APAP, en base a su naturaleza, se muestra en
Fig. 3 Al comparar la precisi
on obtenida con la del CPD
se ha obtenido una tasa de acierto del 99,512%. La penalizaci
on sobre el tiempo de procesamiento del sensor es
del 2,3% (175,135 ms por muestra en los casos peores). Al
combinar este etiquetado con el emitido por DA se obtiene
la pareja riesgo,naturaleza, correspondiente con la salida
del nivel de procesamiento a nivel de paquetes. Dado que
ambas se calculan en paralelo, la sobrecarga a nivel de
paquetes ha sido la mayor de ellas: 2,3%.
Los resultados de la correlaci
on de secuencias de alertas
se muestran en Fig. 4 En ella se indica la frecuencia de
aparici
on de cada etiqueta tras el proceso de correlacion,
y la del etiquetado correcto en la primera opci
on del conjunto de soluciones propuesto por el algoritmo genetico.
La precisi
on de la etiqueta m
as probable propuesta por
DN ha sido del 75,124%, mientras que el 24,876% restante
se ha dado en la segunda opci
on m
as representativa. Por
lo tanto, todas de las amenazas han sido agrupadas correctamente considerando las dos primeras opciones emitidas.
En este caso el tiempo de procesamiento ha sido peor y
asciende a 221,362 ms, lo que supone un incremento de la
sobrecarga del 20,88% tras considerar el retardo del DA y
el del DN (debido principalmente al uso de un algoritmo
genetico).
0,00380625
0,01358725
JNIC2015 0,00567021
0,11796354
0,00380625
0,163631
0,01358725
0,137609
0,00567021
60,0%
0,247923
0,11796354
Legtimo
50,2%
0,163631
50,0%
45,5%0,0000975
Malicioso
43,8%
0,00015
0,137609
40,0%
0,09660625
0,247923
30,0%
0,00344625
0,0000975
20,0%
15,4%
0,00626275
0,00015
14,8%
12,6%
10,4%
0,09660625
10,0%
4,3%
0,00026
0,00344625
0,0%
0,002509
0,00626275
Muy Bajo
Bajo
Medio
Alto
Muy Alto
0,004394
0,00026
Fig. 2
0
n basada en anomalas.
Resultados
en correlacio
0,002509
0,004394
Total
0,80010975
0
Troyano
Esc. privilegios
Cd. ejecutable
Total
DoS
Sfw. privativo
Troyano
Enumeracin I
Esc. privilegios
Enumeracin II
Cd. ejecutable
Virus
DoS
Exploit
Sfw. privativo
Sfw. Priv./spy I
Enumeracin I
Control remoto
Enumeracin II
Swr priv. restrict.
Virus
Swr. acc. no aut.
Exploit
Spyware I
Sfw. Priv./spy I
Spyware II
Control remoto

5
Agradecimientos
Los autores agradecen el apoyo brindado por el Programa de Financiaci
on de Grupos de Investigaci
on UCM
validados de la Universidad Complutense de Madrid Banco Santander.
Referencias
[1]
[2]
[3]
0,381%
1,359%
0,567%
[4]
0,80010975
11,796%
16,363%
13,761%
0,381%
1,359%
0,567%
0,010%
0,015%
[5]
24,792%
11,796%
16,363%
9,661% 13,761%
0,345%
24,792%
0,626%
0,010%
0,026%
0,015%
0,251%
9,661%
0,439%
0,345%
Swr priv. restrict.
0,626%
Swr. acc. no aut.
0,026%
Fig. 3
Spyware I
0,251%
Distribucin
Acierto
en primera
opcin
n de
n de
Distribuci
correlacio
alertas
por
naturaleza.
0,439%
Spyware IIo
Botnet
0,91%
Ofuscado
0,14%
Gusano
1,6%
Driver by
Botnet
Adware
Ofuscado
Spyware
Gusano
Virus
Driver by
Troyano
Adware
0,91%
1,6%
0,24%
0,73%
Virus
0,24%
Troyano
0,73%
[8]
89,10%
[9]
94,40%
83,70%
89,10%
73,10% 91,20%
71,30% 94,40%
83,10%
83,70%
94,50%
91,20%
Acierto en primera opcin
23,18%
30%
43,2%
23,18%
30%
43,2%
Spyware
[7]
73,10%
Distribucin
0,14%
[6]
[10]
[11]
71,30%
83,10%
94,50%
[12]
Fig. 4
n de correlacio
n de secuencias.
Distribucio
[13]
VI. Conclusiones
[14]
Se ha introducido un marco para la correlaci

on de alertas emitidas por sistemas de deteccion de malware en redes basados en la identificacion de anomalas en su carga
u
til. En el se integran las estrategias de an
alisis y modelado del sensor a complementar. Su eficacia ha sido demostrada al correlacionar alertas emitidas tras el an
alisis
de tr
afico real de la UCM. Pero a pesar de los buenos
resultados, su precision y rendimiento presentan mucha
dependencia de las caractersticas de su instanciaci
on (tal
y como sucedio con la sobrecarga del sistema al desplegar
un algoritmo genetico en su u
ltimo nivel). Adem
as es un
marco que integra parte de la estrategia de an
alisis del
sensor que complementa, situacion que dificulta su escalabilidad. Consecuentemente, el futuro trabajo se centrar
a
en optimizar las tecnicas de clasificacion aplicadas.
71
[15]
[16]
[17]
[18]
L. Marinos, A. Sfakianakis, ENISA (2015), Threat Landscape

2014. Available: https://www.enisa.europa.eu/
S. Salah, G. Maci
a-Fern
andez, J.E. Daz-Verdejo, A modelbased survey of alert correlation techniques, Computer Networks, vol. 57, no. 5, pp. 1289-1317, 2013.
S. A. Mirheidari, S. Arshad, R. Jalili, Alert Correlation Algorithms: A Survey and Taxonomy, in Proceedings of the 5th
International Symposium on Cyberspace Safety and Security
(CSS), Zhangjiajie, China, 2013. Lecture Notes in Computer
Science, vol. 8300, pp. 183-197, 2013.
L.J.G. Villalba, A.L. Sandoval Orozco, J. Maestre Vidal, Malware Detection System by Payload Analysis of Network Traffic, IEEE Latin America Transactions, vol. 13, no. 3, pp. 850855, 2015.
H.T. Elshoush, I.M. Osman, Alert correlation in collaborative
intelligent intrusion detection systems-A survey, Applied Soft
Computing, vol. 11, no. 7, pp. 4349-4365, 2011.
N. Hubballi, V. Suryanarayanan, False alarm minimization
techniques in signature-based intrusion detection systems: A
survey, Computer Communications, vol. 49, pp. 1-17, 2014.
G.C. Tjhai, S.M. Furnell, M.Papadaki, N.L. Clarke, A preliminary two-stage alarm correlation and filtering system using
SOM neural network and K means algorithm, Computers &
Security, vol. 9, no. 6, pp. 712-723, 2010.
H.Cam, P.A. Mouallem, R.E. Pino, Alert Data Aggregation
and Transmission Prioritization over Mobile Networks, Network
Science and Cybersecurity, Advances in Information Security,
vol. 55, pp. 205-220, 2014.
A.A. Amaral, B.B. Zarpelao, L.S. Mendez, J.J.P.C. Rodrigues,
M.L.P. Junior, Inference of network anomaly propagation using spatio-temporal correlation, Journal of Network and Computer Applications, vol. 35, no. 6, pp. 1781-1792, 2012.
T. Chen, X. Zhang, S. Jin, O. Kim, Efficient classification using parallel and scalable compressed model and its application
on intrusion detection, Expert Systems with Applications, vol.
41, no. 13, pp. 5972-5983, 2014.
L. Zhaowen, L. Shan, M. Yan, Real-Time Intrusion Alert Correlation System Based on Prerequisites and Consequences,
in Proceedings of the 6th International Conference on Wireless Communications Networking and Mobile Computing
(WiCOM), Chengdu, China, 2010, pp. 1-5.
A.A. Ramaki, M. Amini, R.E. Atani, RTECA: Real time
episode correlation algorithm for multi-step attack scenarios
detection, Computers & Security, vol. 49, pp. 206-219, 2015.
M. Albanese, S. Jajodia, A. Pugliese, V.S. Subrahmanian,
Scalable Analysis of Attack Scenarios, in Proceedings of the
16th European Symposium on Research in Computer Security
(ESORICS), Leuven, Belgium, 2011. Lecture Notes in Computer Science, vol. 6879, pp. 416-433, 2011.
S.O. Al-Mamory, H. Zhang, IDS alerts correlation using
grammar-based approach, Journal in Computer Virology, vol.
5, no. 4, pp. 271-282, 2008.
K. Alsubhi, I. Aib, R. Boutaba, FuzMet: a fuzzy logic based
alert prioritization engine for intrusion detection systems, International Journal of Network Managment, vol. 22, no. 4, pp.
263-284, 2012.
H.T. Elshoush, I.M. Osman, Intrusion Alert Correlation
Framework: An Innovative Approach, in Proceedings of the
IAENG World Congress on Engineering, London, U.K, 2012.
Lecture Notes in Electrical Engineering, vol. 229, pp. 405-420,
2013.
S.H. Ahmadinejad, S. Jalili, M. Abadi, A hybrid model for
correlating alerts of known and unknown attack scenarios and
updating attack graphs, Computer Networks, vol. 55, no. 9,
pp. 2221-2240, 2011.
R. Shittu, A. Healing, R. Ghanea-Hercock, R. Bloomfield, M.
Rajarajan, Intrusion alert prioritisation and attack detection
using post-correlation analysis, Computers & Security, vol. 50,
pp. 1-15, 2015.
JNIC2015 Quinta sesion: Artculos cortos - Seguridad en Redes, ataques, contramedidas y criptografa
Rational Protection Against Timing Attacks

Extended Abstract*
Goran Doychev
Boris Kopf

goran.doychev@imdea.org

boris.koepf@imdea.org
AbstractTiming attacks can effectively recover cryptographic keys. Defensive protections such as constant-time implementations introduce performance penalties. Hence, a balance is
needed between performance and security against timing attacks.
We propose a systematic approach for choosing a protection,
on the example of discrete-log-based cryptosystems. The chosen
protection is an equilibrium in a game-theoretic model. To enable
the equilibrium computation, we derive novel bounds on the
key-recovery probability, as a function of the applied protection
and attack strategies of timing adversaries. We demonstrate our
approach on libgcrypts ElGamal implementation, determining
situations where the optimal protection is either a leaky or
constant-time implementation.
I.
Motivation
Side-channel attacks break the security of systems by

exploiting signals that are unwittingly emitted by the implementation. Examples of such signals are the consumption of
power [6], memory [4], and execution time [5]. Execution time
is a particularly daunting signal because it can be measured
and exploited from a long distance [1], which opens the door
for a potentially large number of attackers.
In theory, one can get rid of timing side channels by
avoiding the use of secret-dependent control flow and of
performance-enhancing features of the hardware architecture,
such as caches and branch prediction units. However, this
defensive approach comes at the price of a performance
penalty. In practice, one is hence faced with the problem of
striking a balance between performance and security against
timing attacks.
II.
Resolving Security vs. Performance Trade-Offs
In this paper we present a game-theoretic approach for

solving this problem. The key novelty of our approach is a
simple and practical model of the side-channel adversary as
a player that can distribute the available resources between
timing measurements and offline search for the secret. Our
approach is focused in that we consider only cryptosystems
based on discrete logarithms and input blinding as a countermeasure, yet it is comprehensive in that it goes all the way
from formal modeling to identifying the optimal protection for
a library implementation of ElGamal. A highlight of our results
is that we are the first to formally justify the use of a fast but
(slightly) leaky implementation over a defensive constant-time
implementation, for some parameter ranges.
The full version of this paper was published in the Proceedings of the 28th
IEEE Computer Security Foundations Simposium, 2015 [2].
72
A. Game-Theoretic Solution
On a technical level, we identify the optimal countermeasure configuration as an equilibrium of a two-stage (Stackelberg) game between two rational players: an adversary and
a defender. The adversary strives to maximize the probability
of key recovery, by distributing bounded resources between
timing measurements and computational search for the key.
The defender strives to minimize the cost of protection, while
maintaining a certain security level given in terms of an upper
bound on the probability of adversary success. The defenders
means to achieve this are the choice of the key length and the
configuration of the countermeasure.
B. Bounds on Probability of Key Recovery
At the heart of the equilibrium computation are novel
bounds for the probability of key recovery in the presence
of side-channel information. We derive these bounds in the
generic group model and under the assumption that the cryptosystem is based on discrete logarithms and protected against
timing attacks by an idealized form of input blinding.
Our starting point is an existing upper bound for the amount
of information contained in n timing measurements, when the
execution time is discretized [7]. The technical challenge we
face is to turn this bound into a guarantee against an adversary
that can mount a combined timing/algebraic attack. We identify
unpredictability entropy [3] as a suitable tool for this task. In
particular, unpredictability entropy satisfies a chain rule [8],
which limits the extent to which bounded leakage can decrease
the hardness of a computational problem. We then cast Shoups
lower bound for computing discrete logs in generic groups [9]
in terms of the unpredictability entropy w.r.t. an adversary
who can perform m group operations. Finally, we connect the
leakage bound with the bound for the discrete log to obtain
the desired bound (in terms of n and m) for combined side
channel/algebraic adversaries.
III.
Case Study
We put our approach to work in a case study where we

seek to optimally configure countermeasures against timing
attacks in the libgcrypt 1.6.1 ElGamal implementation. Experimentally, we identify optimal choices of key lengths and
countermeasure configurations that guarantee the same degree
of security as a constant-time implementation using a reference
key size. We do this for realistic server configurations, and
target commonly used key lengths. In the course of our
implementation allowing two distinct running times (which

we call buckets). In both figures, a cheaper implementation
constitutes the defenders optimal protection strategy for a set
of parameter configurations.
experiments we observe that the time of deployment of a key,

or the number allowed connections per second (which we call
access rate) can influence which configuration is optimal: the
defensive, constant-time implementation with a short key, or
the more aggressively tuned and leaky implementation with a
longer key.
The variation in the cost of the two-bucket implementations is explained in the following. When increasing the
key deployment time, the adversary has more opportunities
to make timing measurements, which leads to an increased
timing leak; as the defender requires a fixed level of security,
he compensates for this higher leak by increasing the key size,
which leads to an increase in cost. As shown in Figure 1,
for longer key deployment times (over 120 days), the cost
of increased key may supersede the cost of a constant-time
implementation. In contrast, as shown in Figure 2, for a
scenario with a bigger reference key size and a lower access
rate, a leaky implementation provides a cheaper protection than
a constant-time implementation even for key deployment times
of over 10 years.
1.15
# instructions 108
1.1
1.05
1
0.95
0.9
0.85
0.8
constant time
2 buckets
0.75
0.7
1
14
30
60
120
180
240
key deployment time (in days)
IV.
Fig. 1: Average cost (in number of CPU instructions) of

ElGamal decryption, for varying key deployment time (in
days). The results are given for a reference key size of 1024
bits, and access rate of 100 accesses per second.
In summary, our contributions are conceptual and practical.

Conceptually, we combine game theory with novel, quantitative security guarantees to tackle the problem of systematically choosing the optimal balance between security and
performance. Practically, we perform a case-study on a realistic
ElGamal implementation, where we illustrate how our techniques can be used to identify cost-effective countermeasure
configurations.
7
6.5
# instructions 108
Summary of Contributions
References
5.5
5
[1]
4.5
4
3.5
3
1 year
[2]
constant time
2 buckets
4 year
7 years
10 years
[3]
13 years
key deployment time
[4]
Fig. 2: Average cost (in number of CPU instructions) of

ElGamal decryption, for varying key deployment time (in
days). The results are given for a reference key size of 2048
bit, and access rate of 10 accesses per second.
[5]
[6]
[7]
Examples of our practical findings are shown in Figure 1

and Figure 2, which give the cost (i.e., running time measured in number of CPU instructions) of ElGamal decryption,
when varying the key deployment time. We compare two
implementations: a constant-time implementation and a leaky
[8]
[9]
73
D. Brumley and D. Boneh. Remote timing attacks are practical.

Computer Networks, 48(5):701716, 2005.
G. Doychev and B. Kopf. Rational Protection Against Timing Attacks. In
Proc. 28th IEEE Computer Security Foundations Symposium (CSF15).
IEEE, 2015.
C.-Y. Hsiao, C.-J. Lu, and L. Reyzin. Conditional computational
entropy, or toward separating pseudoentropy from compressibility. In
EUROCRYPT, pages 169186. Springer, 2007.
S. Jana and V. Shmatikov. Memento: Learning secrets from process
footprints. In SSP, pages 143157. IEEE, 2012.
P. Kocher. Timing Attacks on Implementations of Diffie-Hellman, RSA,
DSS, and Other Systems. In CRYPTO, pages 104113. Springer, 1996.
P. Kocher, J. Jaffe, and B. Jun. Differential power analysis. In CRYPTO,
pages 388397. Springer, 1999.
B. Kopf and M. Durmuth. A provably secure and efficient countermeasure against timing attacks. In CSF, pages 324335. IEEE, 2009.
S. Krenn, K. Pietrzak, A. Campus, A. Wadia, and D. Wichs. A
counterexample to the chain rule for conditional hill entropy. 2014.
V. Shoup. Lower bounds for discrete logarithms and related problems.
In EUROCRYPT, pages 256266. Springer, 1997.
1
Resource Monitoring for the Detection of Parasite

P2P Botnets
Rafael A. Rodrguez-Gomez, Gabriel Macia-Fernandez, and Pedro Garca-Teodoro
E.T.S. de Ingeniera Informatica y de Telecomunicacion, Universidad de Granada
C/Periodista Daniel Saucedo Aranda s/n, E-18071, Granada
{rodgom, gmacia, pgteodor}@ugr.es
The problem of detection of P2P botnets has been denounced as one of the most difficult ones, and this is even
sounder when botnets use existing P2P networks infrastructure (parasite P2P botnets). The main intuition behind our proposal1 of detecting P2P parasite botnet resources is the fact that resources shared by legitimate users
in a P2P network (legitimate resources) will be accessed in
a different way than resources shared by nodes belonging
to a botnet (botnet resources). For this reason, we are interested in building models for both legitimate and botnet
resources. Then, we will suggest a detection architecture
that relies on these models to detect botnet resources in
P2P networks.
Our models are based on the evolution of the number of
P2P nodes that share a specific resource over time. This
way, let nr (k) be the number of nodes sharing a resource
r during a period of time of duration which ends at
k , k = 1, ..., K.
Based on the behavior of nr (k) for legitimate popular
P2P resources, our main hypothesis is that nr (k) will differ substantially from these patterns when r represents
a botnet resource. This means that the detection of potential botnet resources would be possible by monitoring
nr (k) and detecting deviations from the expected temporal sharing behavior.
The key problem to verify this hypothesis is that it is
not possible to use experimental traces from botnet resources. To the best of our knowledge, nowadays there
are no real active parasite botnets reported, possibly due
to the fact that it is extremely difficult to detect them by
existing methods. For this reason, our strategy is to build
a theoretical model for the sharing evolution of botnet
resources, assuming that botmasters must follow certain
rules to maintain and operate their botnets. Here, it is
important to consider two properties that could not be circumvented by botmasters without degrading botnets behavior or exposing them to active detection mechanisms:
1. Botnet resources must be popular resources.
Botnets can be composed of a large number of infected
machines (boots) [2]. When botmasters update the bot
code or send commands, all the bots must download a
given botnet resource which contains those commands or
updates. This implies that a large number of downloads
will be observed for that botnet resource.
2. Botnet resources must have a short life-time.
The period of time during which a botnet resource is be1 This
work is a brief summary of the paper [1].
ing shared should be short, due to the fact that this file is
directly pointing to all the members of the botnet, exposing them to known detection systems [3] [4].
These two rules imply that, during the first phase of
a botnet resource sharing, a high level of popularity is
expected and after that all the bots will stop sharing the
botnet resource in a short period of time.
Resource-based Botnet Detection: Architecture and Operation
The architecture of our proposal for a resource-based
botnet detection system is shown in Fig. 1. The data
from a resource monitoring system for Mainline network
is feeded into our system, where the three typical stages
are considered:
Preprocessing
Both the training and detection processes require a previous common stage to preprocess the data given by the
resources monitoring system. We obtain nr , which represents a low pass filtering of the time series evolution of
the number of peers sharing r.
Training
First, a normality model is built to represent the sharing evolution of legitimate resources in the monitored P2P
network. As we are interested in identifying those resources that exhibit a high fall in the number of peers
that share them and present a reduce sharing duration,
we extract the fall threshold and the sharing duration of
the system.
Detection
Once the model is obtained, every resource shared in the
P2P network is analyzed, in order to determine potential
deviations with respect to the expected behavior. In such
a case, an alarm is triggered indicating the detection of
a malicious, botnet resource. The core of the detection
system corresponds to the module of abnormal fall and
duration detection.
I. Experimental Evaluation
In order to make the training, we collect the evolution
of 34,075 resources in the Mainline network and we select 14,869 of them which are corroborated as legitimate.
Additionally, 42,000 synthetic bot resources following our
74
2
Fig. 1: Functional architecture of the detection system.

=0.07; =0.15
=0.12; =0.28
100
Discovering Botnet Patterns
TPR (%)
80
60
40
=1.2; =3.7
20
0
0
0.1 0.2 0.3 0.4 0.5 0.6 0.7

FPR (%)
Fig. 2: ROC for our detection system by varying and .
x 10
res1
res2
res3
nr(k)
4
3
2
1
0
0
10
20
k (hours)
30
We have also carried out further experiments to check

the system when new, unknown resources are observed
and once the detector is completely tuned. For that, we
used the remaining 19,206 resources obtained in the monitoring process but not previously used for training and
testing our system. These resources could correspond either to legitimate or to botnet resources, as we only know
that they are not explicitly recommended as valid by users.
Our system raised alarms for only three of the monitored
resources, which clearly behaved as outliers.
Fig. 3 shows nr for these three resources. Here we can
check that all of them are shared by a large amount of
peers during a short period of time. Specifically, res1
reaches a maximum of 523,883 users and the sharing phase
of this resource lasts less than 5 hours. The same happens with res2, with less but still significative number of
peers (28,897). Regarding res3, the duration of the sharing phase is longer, but still very short (only 24 hours),
and the number of peers is really significative (436,963).
These behaviors are really suspicious of being due to botnet resources sharing, as they follow the expected behavior
regarding abrupt falling and short-duration in sharing.
40
Fig. 3: Time evolution of the three resources detected as

abnormal.
Acknowledgments
This work has been partially supported by Spanish Government through project TIN2014-60346-R.
Referencias
model based on popularity and short-life time are generated. The existence of both legitimate and botnet resources allows to obtain a ROC curve representing the
performance of our detection system (see Fig. 2). We obtain this ROC by varying and which are the factor to
calculate the fall threshold, Fth , and the duration threshold, Dth .
From these results, we select a value of equal to 1.2
and a value of equal to 3.7, which obtain false positive
rates equal to zero, in order to minimize the number of
alarms while being sure about the malicious nature of the
events detected.
[1] R. A. Rodrguez-G
omez, G. Maci
a-Fern
andez, P. GarcaTeodoro, M. Steiner, and D. Balzarotti, Resource monitoring
for the detection of parasite {P2P} botnets, Computer Networks, vol. 70, no. 0, pp. 302 311, 2014.
[2] M. A. Rajab, J. Zarfoss, F. Monrose, and A. Terzis, My botnet
is bigger than yours (maybe, better than yours): why size estimates remain challenging, in Proceedings of the first conference
on First Workshop on Hot Topics in Understanding Botnets.
USENIX Association, 2007.
[3] S. Shin, Z. Xu, and G. Gu, EFFORT: Efficient and Effective Bot Malware Detection, in Proceedings of the 31th Annual IEEE Conference on Computer Communications (INFOCOM12), 2012.
[4] J. Zhang, R. Perdisci, W. Lee, U. Sarfraz, and X. Luo, Detecting stealthy P2P botnets using statistical traffic fingerprints, in
Dependable Systems & Networks (DSN), 2011 IEEE/IFIP 41st
International Conference on. IEEE, 2011, pp. 121132.
75
Multigraph Project: First Steps towards the Definition

of a Multiple Attack Graph Model Simulator
Mattia Zago, Juan Jos Andreu Blzquez, Manuel Gil Prez, Gregorio Martnez Prez
University of Verona, University of Murcia

mattia.zago@studenti.univr.it, {juanjose.andreu, mgilperez, gregorio}@um.es
AbstractThis paper presents the design and implementation
of a software component acting as a simulator and aiming to help
in the deployment of novel attack graph models. It is also intended
to help comparing these novel approaches with already existing
designs and implementations. It has also as an objective to
determine those aspects of existing models that have not been
completely defined or specified by their authors and thus may
need some completion before being used in lab or real attack
scenarios.
I.
INTRODUCTION AND MOTIVATION
In the literature, there exist several approaches to risk

analysis through attack-graph based models as they represent
an interesting data structure that allows modelling multiple
ways of penetrating a network. However, selecting one or
another approach to be consider in a potential lab or real
scenario seems to be a complex task mostly because some of
these models are just defined theoretically and simple
experimentation has been provided on them. Additionally, it
seems to be a complex task to compare two models to
determine, under certain equivalent circumstances, which of
the two is performing better.
With this aim in mind a software component defining the
basic data structures and general interfaces of the detection and
reaction parts is defined as part of the Multigraph project, a
joint effort between the University of Verona and the
University of Murcia, and whose early results are being
described as part of this paper. The main target of the project is
to build a simulator allowing security researchers and
practitioners to implement different models and try to compare
them, when possible, using similar assumptions. It is also
intended to provide and describe a set of common interfaces
that any potential researcher willing to design, implement and
test a new model in the future could follow as a basic template
to guide its design and deployment.
II. HIGH-LEVEL VIEW OF THE STRUCTURE OF THE SIMULATOR
The attack graph model simulator aims to provide a tool that
can analyse a specific network by means of different models,
offer the user (e.g., either a security specialist or a system
administrator) a graphical visualization of the graph, and
produce results that are consistent and can be easily compared
to one another, independently of the model used for the
analysis. To this end, the models are implemented following a
common structure and interface, which allows the simulator to
interact with them.
A. Core class implementing a model

The model implementation is defined by a set of classes
including one core class that has to implement a common
interface named DecisionInterface. This interface includes
different methods that enable the simulator to do the real
continuous interaction with the model and provide the results
based on such interaction.
The core class is working in a multi-thread environment and
all the additional classes required by any particular model to be
implemented have to communicate with this core class.
Several core classes representing each one a different model
already implemented in the simulator are provided to the user
of the simulator when it is first run as depicted in Fig. 1.
B. Configuration
Fig. 1. Simulator main window
As each attack graph model is having a different set of

parameters, another important aspect considered while
designing the simulator was the definition of different template
windows that any designer of a model could use to get the key
values that need to be provided to make the model run under
certain circumstances.
As an example in Fig. 2 some of the values required by the
model [1] to run are depicted, together with some of the most
relevant actions that can be considered to provide certain
dynamism to the model execution while running it either step
by step or as a whole.
C. Visualization
The simulator has been also designed to provide a graphical
representation of the model and the graph being analysed
during execution. This enables the user to see a representation
76
nodes through different colours and shapes. We are also

intending to provide a multi-layered graph with abstraction and
folding capabilities.
III. FIRST SET OF LESSONS LEARNT
Fig. 2. Model configuration frame
of the model and interact with it. This is achieved through the
use of a graph visualization class that receives as an input the
nodes and edges of the model, and presents them on a screen.
This visualization is using the library JGraphX [2] to display
the graph.
An example of the representation of one sample graph for
the model [1] is provided in Fig. 3.
In our simulator a given attack graph model can provide a
The first issue that have emerged from this work is related
with the innate difficulties while comparing different attack
graph models. This is mostly due to the lack of a common
structure or even a similar approach to the problem. There are
several attempts to create a standard way to manage this
problem, but each one has some issues at a certain point.
As a matter of example, and based on our design and
implementation experience with different models existing in
the simulator, there is a scale for the risk management (i.e.,
low, medium, high) but it is not mandatory or even
recommended. The same happens inside the network analysis:
how it should be defined the probability of a service being
really compromised? Which should be the target: services,
machines or both? And, what happens if the system is
distributed or virtualized and then including different tenants?
In fact, as part of this effort, it has been also faced the
problem that even taking two models with the same basic
assumptions (e.g., same graph structure: services as nodes,
exploits as edges, countermeasures as nodes and evidences as
attributes), the outputs of these models can be different.
This is leading to the identification of a major issue when
considering the comparison between different attack graph
models, which is the lack of a standard normalized way to
approach the problem, including specially the way to provide
the input to the model and the way the model is describing its
outputs.
IV. CONCLUSION
This paper describes a first attempt towards the creation of a
simulator willing to help with the definition of new attack
graph models. A first version of this simulator has been created
and several models have been already implemented using it.
Moreover, a first comparison between different existing
proposals has been performed. As future work, we are planning
to include new implementations of attack graph models and
improve the current definition of the common interfaces, as
well as providing general access to researchers to the
simulator, so it can be used to design novel approaches.
ACKNOWLEDGEMENTS
Fig. 3. Example of graph visualization for a given model
basic graphical interface to interact with it adding and deleting

nodes and edges, changing the properties of these, etc. Whether
or not this should be able to be done at any moment during
runtime, or only at the beginning, depends on the specific
features of the model being used.
In addition to that, the current version is able to represent the
data at the lowest level and it represents the different classes of
This work has been partially funded with the support from
the Spanish MICINN (project DHARMA, Dynamic
Heterogeneous Threats Risk Management and Assessment,
with code TIN2014-59023-C2-1-R) and the European
Commission (FEDER/ERDF).
77
REFERENCES
[1]
[2]
N. Poolsappasit, R. Dewri, and I. Ray, Dynamic security risk

management using bayesian attack graphs, IEEE Transactions on
Dependable and Secure Computing, vol. 9, no. 1, pp. 61-74,
January/February 2012.
JGraphX library, [Online] https://github.com/jgraph/jgraphx.
Seguridad definida por software en subestaciones

electricas
Elas Molina, Armando Astarloa, Eduardo Jacob.
Departamento de Ingeniera de Comunicaciones,
Universidad del Pas Vasco (UPV/EHU)
Alameda Urquijo s/n. 48013, Bilbao - Bizkaia
{elias.molina, armando.astarloa, eduardo.jacob} ehu.es
ResumenEl despliegue de Smart Grids supone la integracion
de las redes de comunicaciones con la red electrica, siendo
necesario establecer mecanismos de seguridad que aseguren la
robustez de los servicios provistos. En este trabajo se propone
una plataforma basada en el paradigma Software-Defined
Networking (SDN) para la gestion de infraestructuras que
implementan el estandar IEC 61850, orientado a las
comunicaciones de datos en las instalaciones de suministro
electrico. La arquitectura propuesta incluye funcionalidades de
monitorizacion y control que permiten implementar medidas de
seguridad a traves de una interfaz comun.

Palabras ClaveIEC 61850, OpenFlow, Seguridad, Smart
Grid, Software-Defined Networking
I. INTRODUCCI ON
El concepto Smart Grid engloba los procesos de
supervision y control del sistema electrico, soportados por las
tecnologas de comunicacion e informacion. Se trata, pues, de
aplicaciones que requieren prestaciones en tiempo real con un
alto grado de fiabilidad y seguridad. El estandar IEC 61850
Power Utility Automation [1] define los servicios y requisitos
para las comunicaciones que tienen lugar en las subestaciones
electricas. La utilizacion de tecnologas SDN para la gestion
de tales entornos crticos permite beneficiarse del concepto de
programabilidad de la red. En las redes basadas en SDN el
plano de control esta desacoplado del de datos y la inteligencia
de red esta logicamente centralizada, aportando una vision
global de la red con el objetivo de establecer las condiciones
adecuadas en la misma.
En el presente trabajo se extraen los aspectos de
ciberseguridad abordados en el artculo previo [2], en el cual
el paradigma SDN es empleado para implementar prestaciones
tales como filtrado de trafico, balanceo de carga o calidad de
servicio en sistemas basados en el estandar IEC 61850.
II. ARQUITECTURA SDN
La arquitectura propuesta constituye un Network Operating
System (NOS), basado en tecnologas estandarizadas, que
sirve como punto comun de configuracion de polticas
seguridad y calidad de servicio. El NOS puede dividirse en
tres bloques funcionales:
Control: mediante el protocolo OpenFlow [3] un
controlador puede decidir el encaminamiento de los diferentes
flujos que llegan a un switch. Para lo cual, anade entradas
en las tablas de encaminamiento del switch, definidas a
traves de diferentes campos (puerto de entrada y cabeceras
de paquetes), prioridades e instrucciones asociadas a cada
flujo de entrada. En concreto, ha sido utilizado el controlador
Floodlight [4].
78
Filtrado de
trfico
Balanceo
de carga
Calidad de
Servicio
Tunelado
Topology Service
Load Balancing
Virtual Network Filter
Static Flow Pusher
Link Discovery
Firewall
Forwarding
Port Down Reconc.
Device manager
Monitor
Aislamiento
Ports
Packet sampling
Queues
Counters
Tunnels
Network Operating System
Fig. 1: Plataforma de control y gestion de red.

Monitorizacion: bajo el estandar sFlow [5] un sistema
puede recoger contadores y muestras de paquetes de los
switches de la red para detectar el estado de la red y actuar
en consecuencia.
Gestion: la configuracion de los switches OpenFlow es
realizada con el protocolo OVSDB [6].
La Figura 1 remarca los modulos del NOS que permiten
la administracion de la red en cuanto a seguridad se refiere,
implementando funciones tales como aislamiento de trafico,
deteccion de anomalas o cortafuegos.
DE LA
III. PROPUESTA PARA LA GESTI ON
SEGURIDAD DE SISTEMAS IEC 61850
La implementacion de estrategias de ciberseguridad es
prioritaria para el desarrollo de Smart Grids. La especificacion
IEC 62351-6 [7] incluye metodos de seguridad para los
diferentes perfiles de comunicacion incluidos en el IEC 61850,
tales como algoritmos criptograficos o la certificacion de
autenticacion. Sin embargo, dados los exigentes requisitos
de latencia de los protocolos definidos por el IEC 61850
(Sampled Value, SV, y Generic Object Oriented Substation
Events, GOOSE, son protocolos orientados a soportar ciertos
servicios que requieren tiempos de transferencia inferiores a
3 ms [1]), la encriptacion no se recomienda. Ademas, hay
ambiguedad sobre la necesidad de asegurar la integridad de
los datos y la autenticidad del emisor [7]. A continuacion, se
proponen diferentes polticas de red y controles de seguridad
apropiados para mitigar posibles vulnerabilidades.
Aislamiento de trafico
De acuerdo con [8], la segmentacion de nivel 2 y las listas
de control de acceso basadas en MAC son efectivas para
restringir el trafico de datos a los diferentes dominios de
las infraestructuras electricas. La plataforma propuesta facilita
la segmentacion de red haciendo uso del modulo Virtual
Network Filter, el cual permite crear redes logicas basadas
RED LGICA
HMI
MAC.C
VLAN.Z
HTTP
RED LGICA
SAMPLE VALUE
SV
MU
MAC.B
VLAN.X
RED LGICA
GOOSE
GOOSE
IED Y
GOOSE
IED X
MAC.A
VLAN.Y
RED LGICA
GOOSE
MAC.A
VLAN.X
Fig. 3: Deteccion de un ataque DoS.
INFRAESTRUCTURA
FSICA
Fig. 2: Ejemplo de segmentacion de red basado en

direccionamiento MAC y VLAN.
en direccionamiento MAC. Ademas, en caso de usar VLAN
(IEEE 802.1Q), los identificadores de cada red virtual pueden
reutilizarse. La Figura 2 muestra un diagrama de ejemplo
donde un red es segmentada en diferentes redes logicas
basados en diferentes flujos que tienen lugar en subestaciones
IEC 61850. As, dicha tecnica de aislamiento es un efectivo
complemento a la segregacion del trafico basado en VLAN.
Firewall y control de spoofing
Al no tener que implementar mecanismos de autenticacion
y encriptado para las tramas SV y GOOSE, diferentes estudios
[9,10] han demostrado como la seguridad de un sistema IEC
61850 puede estar comprometida. En particular, los autores
coinciden en proponer ataques de tipo MAC spoofing. Con el
proposito de solventar tales problemas, el modulo Firewall de
Floodlight es usado para limitar el trafico entrante de acuerdo
a la direccion MAC origen, puerto y switch. Por tanto, la
plataforma permite establecer Listas de Control de Acceso
(ACL) estaticamente. Ademas, haciendo uso del modulo
Device Manager, el controlador restringe continuamente la
conexion de dispositivos con direcciones MAC unvocas (la
primera en conectarse), lo que favorece la proteccion contra
ataques de spoofing y otros problemas tradicionales que
pudieran ocurrir con direccionamiento duplicado.
Deteccion de anomalas
En la arquitectura propuesta el colector sFlow puede
detectar que un umbral este siendo sobrepasado. Lo cual es
comunicado al controlador OpenFlow para que este establezca
las acciones pertinentes. As, la plataforma permite establecer
flujos (definidos por Ethertype, direcciones MAC/IP, VLAN,
puertos de TCP/UDP, etcetera) y determinar umbrales de
monitorizacion asociados a tales flujos. Por consiguiente,
los diferentes nodos de la red pueden ser protegidos contra
ataques de denegacion de servicio (DoS) desde uno o varios
orgenes (DoS distribuido).
La Figura 3 ejemplifica una situacion en la que se detecta un
ataque DoS, donde un nodo es saturado con paquetes ICMP
del tipo Echo Request (ping flood). Puede observarse una
primera fase en la que el control de DoS esta deshabilitado y
una segunda en la que el controlador limita el trafico entrante
79
cuando este excede el umbral predeterminado (100 paquetes

IP por segundo en este caso).
IV. CONCLUSIONES Y L INEAS

FUTURAS
El modelo Smart Grid es un claro ejemplo de
infraestructura crtica en la que la gestion de la seguridad
es esencial para asegurar las prestaciones de la red. Para
disenar y mantener subestaciones electricas es necesario
proveer polticas de seguridad y diferenciacion del trafico
de datos. Con dicho objetivo, una plataforma basada en
tecnologas SDN permite configurar los elementos de red a
traves de una interfaz comun. La arquitectura propuesta se
beneficia de la programabilidad de las SDN, automatizando la
configuracion de recursos y aportando tecnicas de diagnostico
de las condiciones de red.
Dado que las funcionalidades presentadas estan basadas en
filtrados de flujos estaticos (stateless), como acciones futuras
se plantea la incorporacion de reglas de filtrado de paquetes
con estado.
AGRADECIMIENTOS
El trabajo descrito ha sido posible gracias al programa
ZABALDUZ, habiendose producido en la Unidad de
Formacion e Investigacion UFI11/16 financiada por la
Universidad del Pas Vasco (UPV/EHU).
R EFERENCIAS
[1] International Electrotechnical Commission TC57, Communication
networks and systems for power utility automation, IEC 61850. 2011.
[2] E. Molina, E. Jacob, J. Matias, N. Moreira, and A. Astarloa, Using
Software Defined Networking to manage and control IEC 61850-based
systems, Computers Electrical Engineering, 2014.
[3] Open Networking Foundation (ONF), OpenFlow Switch Specification,
version 1.5.0, Open Networking Foundation (ONF), Diciembre 2014.
[4] B. S. Networks. Floodlight openflow controller. [Online]. Available:
http://www.projectfloodlight.org/floodlight/
[5] P. Phaal, S. Panchen, and N. McKee, InMon Corporations sFlow: A
Method for Monitoring Traffic in Switched and Routed Networks, RFC
3176, IETF, Sep. 2001.
[6] B. Pfaff and B. Davie, The Open vSwitch Database Management
Protocol, RFC 7047, IETF, 2013.
[7] IEC TC57, Power systems management and associated information
exchange - Data and communications security - Part 6: Security for
IEC 61850, IEC TS 62351-6 ed.
[8] T. Janca, Utility ethernet network architecture: Networked electrical
exchange topology-next, in Sarnoff Symposium (SARNOFF), 2012 35th
IEEE, May 2012, pp. 16.
[9] J. Hoyos, M. Dehus, and T. Brown, Exploiting the goose protocol: A
practical attack on cyber-infrastructure, in Globecom Workshops (GC
Wkshps), 2012 IEEE, Dic 2012, pp. 15081513.
[10] N. Kush, E. Ahmed, M. Branagan, and E. Foo, Poisoned goose:
Exploiting the goose protocol, in Twelfth Australasian Information
Security Conference (AISC 2014), ser. CRPIT, U. Parampalli and
I. Welch, Eds., vol. 149. Auckland, New Zealand: ACS, 2014, pp.
1722.
1
VERITAS: Visualizacion de Eventos en Red

Inteligente para el Tratamiento y Analisis de la
Seguridad
Jose Camacho, Gabriel Macia-Fernandez, Pedro Garca-Teodoro
Dpto. Teora de la Se
nal, Telematica y Comunicaciones, Universidad de Granada (Spain)
{josecamacho,gmacia,pgteodor}@ugr.es
Roberto Theron
Universidad de Salamanca (Spain)
theron@usal.es
Resumen Los sistemas SIEM tienen como finalidad la
agregaci
on y an
alisis de datos procedentes de los diversos
mecanismos de seguridad desplegados en un entorno de red,
a fin de gestionar potenciales incidentes. Entre los retos
que deben afrontar los SIEM actuales podemos destacar
el manejo de grandes vol
umenes de datos y m
ultiples y
heterog
eneas fuentes de informaci
on. Tomando como base
resultados previos de los autores, en este trabajo se propone una metodologa jer
arquica de an
alisis multivariante
para su integraci
on en un SIEM, de modo que se consiga
el manejo de mayores cantidades de datos sin afectar las
prestaciones de la detecci
on.
I. Seguridad en Red y Analtica Visual

Los sistemas de gestion de la informacion de seguridad
y eventos en red, o SIEM (del ingles Security Information & Event Management) [1], constituyen una de las
herramientas actuales mas adoptadas en la lucha contra
ataques a la seguridad en entornos de red. Entre los retos
que deben afrontar los SIEM actuales podemos destacar
el manejo de grandes vol
umenes de datos registrados a
altas velocidades y la integraci
on de informacion procedente de m
ultiples fuentes de gran heterogeneidad (p.ej.,
trazas de cortafuegos, trafico en red, alertas de IDS, etc.).
Adicionalmente, los datos deben ser pre-procesados, agregados y presentados al administrador de forma que este
pueda comprenderlos y gestionarlos facilmente. Este problema coincide con la definicion dada en la literatura de
un problema Big Data, donde es necesario gestionar las
conocidas cuatro Vs: variedad, volumen, velocidad y veracidad [2].
El emergente campo de la analtica visual (visual analytics) trata de abordar las necesidades de descubrimiento
exploratorio en grandes vol
umenes de datos (Big Data)
[3], [4], [5]. Para ello, combina tecnicas de analisis automatizado con visualizaciones interactivas para una eficaz comprension, razonamiento y toma de decisiones sobre
la base de conjuntos de datos muy grandes y complejos.
La aplicacion de este tipo de tecnologas al campo de la
(ciber)seguridad es cada vez mayor, ejemplos de lo cual
son el simposio VizSec (Visualization for Cyber Security,
http://www.vizsec.org/), dentro del prestigioso congreso
de visualizacion IEEE VIS (http://ieeevis.org/), as como
la seleccion de la ciberseguridad como tema central para
los retos del IEEE Symposium on Visual Analytics Science
80
and Technology en sus versiones de 2012 y 2013, organizados por la Visual Analytics Community.
Centrandonos en las caractersticas especficas de la deteccion de anomalas en red, para el empleo eficiente de un
sistema SIEM, as como para poder extender su estrategia
de seguridad a distintos entornos de redes (p.ej. redes corporativas, redes inalambricas, redes celulares) y modelos
de negocio actuales (p.ej. la nube, Bring Your Own Device), podemos establecer los siguientes retos principales:
1. Fusion efectiva de distintas fuentes de informacion, que
incluye la parametrizacion o parsing de los datos capturados por los sensores.
2. Mantenimiento de una alta capacidad de deteccion de
anomalas evitando la tpica tendencia a presentar un alto
n
umero de falsos positivos.
3. Capacidad de analisis de grandes cantidades de datos
a altas velocidades.
4. Reduccion del volumen de trafico asociado a la seguridad ante el elevado volumen de trafico generado entre sensores y SIEM.
5. Combinacion de fuentes de informacion de seguridad
asociada a sistemas finales (alarmas de antivirus, registros
de aplicaciones y SO, cortafuegos de dispositivos, etc.)
con los sensores de la red (cortafuegos de red, sniffers de
trafico, IDS, etc.).
En este contexto, las tecnicas basadas en el analisis
estadstico multivariante para el analisis exploratorio de
datos o EDA (del ingles Exploratory Data Analysis) [6] y
el control estadstico de procesos o SPC (del ingles Statistical Process Control) [7] pueden resultar extremadamente
u
tiles. Si bien la capacidad de deteccion de anomalas del
analisis multivariante es bien conocida en el area de monitorizacion de procesos industriales [8], [9], su aplicacion
en seguridad en redes, aunque existente [10], es mas limitada y presenta un menor desarrollo. Es precisamente
en este marco que los autores han llevado a cabo algunos
desarrollos de deteccion de anomalas en redes basados
en tecnicas multivariantes, los cuales han evidenciado una
alta potencialidad [11].
tesis y Objetivos
II. VERITAS: Hipo
La metodologa desarrollada en [11] ofrece una solucion
prometedora para los tres primeros retos de los sis-
2
Fig. 1. SIEM multivariado distribuido.
temas SIEM listados con anterioridad.

Ha surgido
as la propuesta I+D+i bautizada como VERITAS
(acronimo de Visualizacion de Eventos en Red Inteligente para el Tratamiento y Analisis de la Seguridad; http://nesg.ugr.es/veritas), la cual establece como
hipotesis de partida:
H1. Las t
ecnicas multivariantes desarrolladas por el
equipo de investigaci
on, en combinaci
on con las adecuadas
tecnicas de caracterizacion de la informacion y de analisis
visual interactivo, constituyen una metodologa de altas
prestaciones para la deteccion y diagnostico de anomalas
en un SIEM.
H2. Las extensiones jer
arquicas del analisis multivariante permiten desarrollar un sistema SIEM distribuido de
deteccion de anomalas, donde (a) las prestaciones de deteccion y diagnostico son equivalentes al sistema no distribuido, y (b) se reduce el volumen de trafico de seguridad
en red.
H3. La reducci
on del volumen de trafico de seguridad en la red supone una ventaja competitiva en sistemas
SIEM.
H4. El esquema SIEM distribuido permite desacoplar
la deteccion del diagnostico de anomalas, de forma que (a)
se mantienen las prestaciones originales y (b) se mejora la
privacidad del sistema.
Con estas hipotesis, el objetivo perseguido en VERITAS
es dise
nar, implementar y evaluar una metodologa basada
en el analisis multivariante para la deteccion y diagnostico
distribuido de anomalas en red, que permita:
- Aumentar la capacidad de deteccion de los SIEM actuales.
- Reducir el n
umero de falsos positivos.
- Mejorar la interpretaci
on de los eventos detectados.
- Reducir el volumen de trafico de seguridad en la red.
- Asegurar la privacidad del sistema resultante.
El sistema propuesto se ilustra en la Fig. 1, donde se
destaca la distribucion en la red de los llamados sensores
multivariantes. Estos analizan los parametros de la fuente
de datos que reciben y generan informacion comprimida
que, a su vez, envan a un concentrador superior. Este esquema se puede repetir las veces deseadas en una estructura jerarquica de N niveles. En lo alto de la jerarqua
81
se encuentra el SIEM, donde se dispone de herramientas

de analisis visual interactivo del sistema completo. La deteccion de anomalas se realiza de forma distribuida y a
distintos niveles de agregacion de datos.
Los sensores multivariantes son capaces de detectar
anomalas, pudiendo remitir de forma asncrona a los niveles superiores informacion detallada de diagnostico. A su
vez, si un nivel superior detecta una anomala en datos de
algunos de sus sensores multivariantes, puede realizar una
solicitud de informacion de diagnostico a dichos sensores.
De esta manera, u
nicamente la informacion anomala es
elevada a los niveles superiores hasta el SIEM, reduciendo
la cantidad de informacion de seguridad transmitida por
la red y permitiendo evaluar mayores cantidades de datos.
Las amenazas localizadas en ciertos dispositivos, como un
ataque de denegacion de servicio en un servidor, son susceptibles a ser detectadas en el sensor PCA de dicho dispositivo. Finalmente, dicha arquitectura permite mantener la privacidad de los niveles inferiores, si as se desea,
manteniendo el nivel de deteccion y diagnostico.
Agradecimientos
Este trabajo esta financiado por el Ministerio de
Economa y Competitividad, con fondos FEDER, a traves
del proyecto TIN2014-60346-R.
Referencias
[1] D.R.. Miller, S. Harris, A. Harper, S. VanDyke, and C. Blask,
Security Information and Event Management (SIEM) Implementation, McGraw Hill Professional, 2010.
[2] M. Schroeck, R. Shockley, J. Smart, D. Romero-Morales, and
P. Tufano, Analytics: The Real-World Use of Big Data, IBM
Institute for Business Value, IBM Institute for Business Value Executive Report, 2012.
[3] A. Endert, M.S. Hossain, N. Ramakrishnan, C. North, P. Fiaux,
and C. Andrews, The Human is the Loop: New Directions for
Visual Analytics , Journal of Intelligent Information Systems,
pp. 1-25, 2014.
[4] R. Santamara, R. Theron, and L. Quintales, BicOverlapper:
Visual Analysis for Gene Expression , Bioinformatics, Vol. 30,
No. 12, pp. 1785-1786, 2014.
[5] A. Gonz
alez-Torres, and F.J. Garca-Pe
nalvo, HumanComputer Interaction in Evolutionary Visual Software Analytics ,
Computers in Human Behavior, Vol. 29, No. 2, pp. 486-495,
2013.
[6] K.H. Esbensen, D. Guyot, F. Westad, and L.P. Houmoller, Multivariate Data Analysis - In Practice , 5o Ed. Camo. ISBN:
82-993330-3-2, 2001.
[7] A. Ferrer, Multivariate Statistical Process Control Based on
Principal Component Analysis (MSPC-PCA): Some Reflections
and a Case Study in an Autobody Assembly Process , Quality
Engineering, Vol. 19, pp. 311-325, 2007.
[8] J. Camacho, and J. Pic
o, Online Monitoring of Batch Processes
Using Multi-phase Principal Component Analysis , Journal of
Process Control, Vol. 16, No. 11, pp. 1021-1035, 2006.
[9] P. Nomikos, and F. MacGregor, Multivariate SPC Charts for
Monitoring Batch Processes , Technometrics, Vol. 37, No. 1,
pp. 41-59, 1995.
[10] A. Patcha, and J.M. Park, An Overview of Anomaly Detection
Techniques: Existing Solutions and Latest Technological Trends
, Journal of Computer Networks, Vol. 51, No. 12, pp. 3448-3470,
2007.
[11] J. Camacho-P
aez, G. Maci
a-Fern
andez, J.E. Daz-Verdejo, and
P. Garca-Teodoro, Tackling the Big Data 4 Vs for Anomaly Detection, IEEE INFOCOM, 2nd. International Workshop on Security in Big Data (BigSecurity), pp. 506-511, Toronto (Canada),
May 2014.
Security services as cloud capabilities using MAS

Fernando De la Prieta, Alberto Lpez Barriuso and Juan M. Corchado
Universidad de Salamanca, Departamento de Informtica y Automtica, Plaza de la merced s/n, 37007, Salamanca (Espaa)
{fer, albarriuso, corchado}@usal.es
Luis Enrique Corredera de Colsa
Flag Solutions S.L., C/Bientocadas 12, 37002, Salamanca, (Espaa)
luisenrique@flagsolutions.net
Abstract- The digital signature solves partially the problem of

the validation of veracity of the digital resources because it
provides the characteristics of authentication, integrity and nonrepudiation. However, it has weakness in terms of availability,
confidentiality and changes control, besides the complexity on its
usage. This paper presents the project DoyFE.es that is an agentbased platform deployed over a cloud system that provides cloudbased services to guarantee the veracity of the communications
(email, web content and photographs).
I.
INTRODUCTION
Nowadays, there are many trials where evidences are based

on electronic documents (files, information, emails,
photographs, etc.). The majority of these documents have not
been digitally signed, so it is difficult to validate their
truthfulness. In these cases, it is necessary to validate the
veracity of these evidences by means of forensic computer
science techniques [1]. This process not only delays the trials,
but also increases considerably their costs. These problems can
be partially addressed by the users through the use of the
digital signature. Besides the electronic communications
advantages, digital signed documents have many advantages
facing to non-electronic one (i.e. authentication, integrity and
non repudiation).
Despite the use of digital signature, there still are some
weaknesses in terms of (i) Availability, it depends directly on
the end-users because they are on charge of the backup of the
signed document along the time; (ii) Confidentiality, it is not
possible to monitor access to the signed files, so everyone
would be able to see their content; and finally (iii), the Change
Control, because when a signed document is changed, it is not
possible to know what what were the changes.
This study presents the platform DoyFe.es1 that deals with
these open issues. To do so, DoyFe platform exposes three
cloud-based services for secure communication of information
exchanges and electronic transactions. DoyFe is based on
Cloud Computing (CC) [2][3], which improves the
commercialization following a payment model based on the
usage [4]. The core of DoyFe is a multiagent system (MAS)
based on virtual organization (VO) [5] that allows the
interaction both with the underlying cloud platform and with
the end-user.
This work is organized as follow, next section presents the
three main developed services, while section 3 is focused on
1
This work has been previously published:

De la Prieta, F., Corredera, L. E., Snchez-Martin, A. J., &
Demazeau, Y. (2014, January). An Agent-Based Cloud
Platform for Security Services. In PAAMS (Workshops) (pp.
333-343).
the integration with the cloud platform and the MAS. Finally,
last section contains the conclusions.
II. CLOUD-BASED SECURITY SERVICES
Under the frame of DoyFe.es project, a set of services has
been developed in order to guarantee the authentication,
integrity and non-repudiation, but also other open issues such
as availability, confidentiality and change control. To do so,
three main services have been created:
Transmission and signed backup of emails. An active
inbox model is used to facilitate the usability of the
system. The process is very easy, because the end-user
sends the email normally and only has to put in copy a
special email of the platform (doyfe@doyfe.es). The
processing includes the signing, timestamped and the
storage of the email data (content, dates, addresses,
headers, attachments, images, etc.).
Transmission and signed backup of web content. The
process of tracking (signing and storage) of web content
is more complex because the web pages usually include
related contents (i.e. images, style sheets, scripts, etc.).
So, it is needed not only to process the main content, but
also al related content and all exchanges of request and
responses.
Sign of photographs. The process of tracking
photographs is different because it is not only necessary
to sign the taken photography by a mobile phone, but also
geolocalize it. A second photography with the frontal
camera is taken in order to know who is the person that
takes the photography. To do so, the user has to install a
specific APP. In this case they are signed into the mobile
phone. To do so, it is necessary to exchange information
between the cloud platform and the phone about the
security certificate because the photograph is signed on
the smartphone.
http://www.doyfe.es/
82
III. DOYFE PLATFORM

Once the communication services have been presented, there
is no doubt that their nature requires large computational
resources. DoyFE not only has to store a large amount of
information, but also needs computational power to sign the
files in order not to delay the normal flow of the signed
resources. Thus, DoyFe platform is deployed over +Cloud
which is a cloud-based platform [2][3] that used a CBR (CaseBased reasoning) to control the elasticity of the services. This
platform allows offering services at the PaaS and SaaS
levels. Under de frame of DoyFE (Fig. 1), the persistence
services at PaaS level represent the Digital Repository where
the signed documents are stored. But also, +Cloud provides a
deployment environment where the computational power
(needed for signing) is taken from the virtual machines where
each service is deployed.
Signing manager. It is in charge of gather the information

for signing and converts it into the appropriate format and
sends it to the Notary for signing.
Certificates manager. It manages the creation, store and
revocation of digital certificates for mobile clients and for
the notary agents.
Notary. It is the role that signs the documents received
from the Signing manager using the keys provided by the
Certificate manager.
User
DoyFE.es
Service
SLA Negotiation
Evidence
Organization
Global
Supervisor
Signing
Manager
Service
Organization
Notary
Certificate
Manager
Digital
Repository
(FSS&OSS)
Service
Monitor
Service
Manager
External Layer
DoyFE
Front-end
Web Browser
(in-a-browser)
e-mail
Global
Manager
Signing y
timestamping
Certification
authority
Local
Manager
Resource
Organization
Mobile
Application
Hardware
Manager
SaaS
iMap Control
Local
Monitor
MAS
Fig. 2. Organizations of agents in DoyFe.es y +Cloud
Security Communication Services

Digital Repositories
Infrastructure
Control
Files
IV. CONCLUSIONS
Documents
PaaS
The main advantage of DoyFE.es is related with the fact of it

is deployed over a CC platform. Moreover, the end user has a
perspective of a single system, however, the reality is that the
users make use of the services of DoyFE and the computational
power of CC. Moreover, it is possible to use DoyFE within the
legal frame in order to validate the genuineness of the
electronic evidences by a third party using an innovative
perspective and traditional tools such as digital signature and
service.
Environment
Are Storage
Network
MAS
Adaptive
Algorithms
Load
balancing
Documental
database
Security
Virtualization Layer
Physical Layer
Environment
Internal Layer
Fig. 1. Components diagram of DoyFE.es
+Cloud platform uses VO to manage the system resources

(Fig. 2). MAS can be perfectly adapted to solve this problem,
as it allows making decisions in an open environment where
the availability of information is limited and agents are thereby
required to make decisions, amidst great uncertainty, that affect
the entire system. The core of +Cloud is based on two virtual
organizations as follow:
Resource Organization. This agent organization is charge
of managing both the physical and virtual system resources.
Its main goal is to maximize the use of resources.
Consumer Organization. The services encompassed by
this organization will, therefore use the system resources
according to existing demand. Its main goal is to maximize
the quality of service.
DoyFe incorporates an additional organization (Fig. 2) in
order to manage the evidences, this organization include three
main roles:
Acknowledgements. This work has been supported by the

SOHA+C project (Ref. SA213U13) funded by Junta de
Castilla y Leon.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
83
Casey, E. (2011). Digital evidence and computer crime: Forensic

science, computers, and the internet. Academic press.
De la Prieta, F., Rodrguez, S., Bajo, J., & Corchado, J. M. (2013). A
Multiagent System for Resource Distribution into a Cloud Computing
Environment. In Advances on Practical Applications of Agents and
Multi-Agent Systems (pp. 37-48). Springer Berlin Heidelberg.
Heras, S., De la Prieta, F., Julian, V., Rodrguez, S., Botti, V., Bajo, J.,
& Corchado, J. M. (2012). Agreement technologies and their use in
cloud computing environments. Progress in Artificial Intelligence, 1(4),
277-290.
Buyya, R. Market-Oriented Cloud Computing: Vision, Hype, and
Reality for Delivering IT Services as Computing Utilities. 10th IEEE
International Conference on High Performance Computing and
Communications, 2008. HPCC '08. Pages. 5-13
Rodrguez, S., de Paz, Y., Bajo, J., Corchado, JM. Social-based planning
model for multiagent systems. Expert Systems with Applications 38
(10), 13005-13023. 2011.
1
Programmable Hash Functions go Private:

Constructions and Applications to
(Homomorphic) Signatures with Shorter Public Keys
1
Dario Catalano1 , Dario Fiore2 , Luca Nizzardo2

Dipartimento di Matematica e Informatica, Università di Catania, Italy.
2
IMDEA Software Institute, Madrid, Spain.
Abstract We introduce the notion of Asymmetric Programmable Hash Functions (APHFs), which adapts Programmable Hash Functions, introduced by Hofheinz and
Kiltz at Crypto 2008. We show that APHFs are surprisingly powerful objects. Using them we indeed obtain:
(1) the first linearly-homomorphic signature (in the standard model) whose public key is sub-linear in both the
dataset size and the dimension of the signed vectors; (2)
short signatures (in the standard model) whose public key
is shorter than those by Hofheinz-Jager-Kiltz from Asiacrypt 2011, and essentially the same as those by Yamada,
Hannoka, Kunihiro, (CT-RSA 2012).
I. Introduction
Programmable Hash Functions (PHFs) were introduced
by Hofheinz and Kiltz [1] as an information theoretic
tool to mimic the behavior of a random oracle in finite groups. In a nutshell, a PHF H is an efficiently computable function that maps suitable inputs (e.g., binary
strings) into a group G, and can be generated in two different, indistinguishable, ways. In the standard modality, H hashes inputs X into group elements H(X) G.
When generated in trapdoor mode, a trapdoor allows one
to express every output in terms of two (user-specified) elements g, h G, i.e., one can compute two integers aX , bX
such that H(X) = g aX hbX . Finally, H is programmable in
the sense that it is possible to program the behavior of H
so that its outputs contain (or not) g with a certain probability. More precisely, H is said (m, n)-programmable if for
all disjoint sets of inputs {X1 , . . . , Xm } and {Z1 , . . . , Zn },
the joint probability that i, aXi = 0 and j, aZj 6= 0 is
significant (e.g., 1/poly()). Programmability turns out
to be particularly useful in several security proofs. For
instance, consider a security proof where a signature on
H(X) can be simulated as long as aX = 0 (i.e., g does not
appear) while a forgery on H(Z) can be successfully used
if aZ 6= 0 (i.e., g does appear). Then one could rely on an
(m, 1)-programmability of H to hope that all the queried
messages X1 , . . . , Xm are simulatable, i.e., i, aXi = 0,
while the forgery message Z is not, i.e., aZ 6= 0. PHFs
essentially provide a nice abstraction of the so-called partitioning technique used in many cryptographic proofs.
II. Our Contribution
Asymmetric Programmable Hash Functions. We
introduce the notion of asymmetric programmable hash
This is an extended abstract based on an earlier article which
c IACR 2015.
appears in the proceedings of CRYPTO 2015,
84
functions (asymmetric PHFs) which modifies the original

notion of PHFs [1] in two main ways. First, an asymmetric
PHF H maps inputs into a bilinear group G and is only
secretly computable. At the same time, an isomorphic copy
of H can be publicly computed in the target group GT , i.e.,
anyone can compute e(H(X), g).1 Second, when generated
in trapdoor mode, for two given group elements g, h G
such that h = g z , the trapdoor allows one to write every
H(X) as g cX (z) for a degree-d polynomial cX (z).
We define two main programmability properties of
asymmetric PHFs. The first one is an adaptation of
the original programmability notion, and it says that H
is (m, n, d)-programmable if it is (m, n)-programmable as
before except that, instead of looking at the probability
that aX = 0, one now looks at whether cX,0 = 0, where
cX,0 is the coefficient of the degree-0 term of the polynomial cX () obtained using the trapdoor.2 The second programmability property is new and is called programmable
pseudo-randomness. Roughly speaking, programmable
pseudo-randomness says that one can program H so that
the values g cX,0 look random to any polynomially-bounded
adversary who observes the public hash key and the outputs of H on a set of adaptively chosen inputs.
Applications. In principle, secretly computable PHFs
seem less versatile than regular PHFs. In this work, however, we show that, for applications such as digital signatures, asymmetric PHFs turn out to be more powerful
than their publicly computable counterparts. Specifically:
we obtain the first linearly homomorphic signature
scheme, secure in the standard model, achieving a public key which is sub-linear in both the dataset size and
the dimension of the signed vectors;
we obtain regular signature schemes, matching the efficiency of the ones in [2], thus providing the shortest signatures in the standard model with a public key shorter
than in [3].
In the following paragraphs we elaborate more on the
fist contribution, while we refer to the full version of the
paper [4] for more details on the second contribution.
Linearly-Homomorphic Signatures with Short
Public Key in the Standard Model. Imagine a
user Alice stores one or more datasets D1 , D2 , . . . , D` on
a cloud server. Imagine also that some other user, Bob,
1 Because of such asymmetric behavior we call these functions
asymmetric.
2 For d = 1, this is basically the same programmability of [1].
2
is allowed to perform queries over Alices datasets, i.e., to

compute one or more functions F1 , . . . , Fm over any Di .
The crucial requirement here is that Bob wants to be ensured about the correctness of the computations results
Fj (Di ), even if the server is not trusted. An obvious way
to do this (reliably) is to ask Alice to sign all her data
(i)
(i)
Di = m1 , . . . , mN . Later, Bob can check the validity of
the computation by (1) downloading the full dataset locally, (2) checking all the signatures and (3) redoing the
computation from scratch. Efficiency-wise, this solution
is clearly undesirable in terms of bandwidth, storage (Bob
has to download and store potentially large amount of
data) and computation (Bob has to recompute everything
on his own).
A much better solution comes from the notion of homomorphic signatures [5]. These allow to overcome the first
issue (bandwidth) in a very elegant way. Using such a
scheme, Alice can sign m1 , . . . , mN , thus producing signatures 1 , . . . , N , which can be verified exactly as ordinary
signatures. In addition, the homomorphic property provides the extra feature that, given 1 , . . . , N and some
function F : MN M, one can compute a signature
F,y on the value y = F (m1 , . . . , mN ) without knowledge
of the secret signing key sk. In other words, for a set
of signed messages and any function F , it is possible to
provide y = F (m1 , . . . , mN ) along with a signature F,y
vouching for the correctness of y. The security of homomorphic signatures guarantees that creating a signature
F,y for a y 6= F (m1 , . . . , mN ) is computationally hard,
unless one knows sk.
To solve the second issue and allow Bob to verify efficiently such signatures (i.e., by spending less time than
that required to compute F ), one can use homomorphic
signatures with efficient verification [6].
Despite the significant research work in the area, it
is striking that all the existing homomorphic signature
schemes that are proven secure in the standard model
(e.g., [7], [8], [9], [10], [11], [12], [6], [13]) suffer from a
public key that is at least linear in the size N of the
signed datasets. On one hand, the cost of storing such
large public key can be, in principle, amortized since the
key can be re-used for multiple datasets. On the other
hand, this limitation still represents a challenging open
question from both a theoretical and a practical point of
view. From a practical perspective, a linear public key
might be simply unaffordable by a user Bob who has limited storage capacity. From a theoretical point of view,
considered the state-of-the-art, it seems unclear whether
achieving a standard-model scheme with a key of length
o(N ) is possible at all. Technically speaking, indeed, all
these schemes in the standard model somehow rely on a
public key as large as one dataset for simulation purposes.
Our Result. We solve the above open problem by
proposing the first standard-model homomorphic signature scheme that achieves a public key whose size is sublinear in the maximal size N of the supported datasets.
Slightly more in detail, we show how to use asymmetric PHFs in a generic fashion to construct a linearly-
85
homomorphic signature scheme based on bilinear maps

that can sign datasets, each consisting of up to N vectors
of dimension T . The public key of our scheme mainly consists of the public hash keys of two asymmetric PHFs. By
instantiating these using (one of) our concrete realizations
we obtain a linearly-homomorphic
signature with a public
key of length O( N + T ). We stress that ours is also

the first linearly-homomorphic scheme where the public
key is sub-linear in the dimension T of the signed vectors.
Concretely, if one considers applications with datasets of
1 million of elements and a security parameter of 128bits,
previous solutions (e.g., [9], [11]) require a public key of
at least 32 MB, whereas our solution simply works with a
public key below 100 KB.
References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
D. Hofheinz and E. Kiltz, Programmable hash functions and

their applications, in CRYPTO 2008, ser. LNCS, D. Wagner,
Ed., vol. 5157. Springer, Aug. 2008, pp. 2138.
S. Yamada, G. Hanaoka, and N. Kunihiro, Two-dimensional
representation of cover free families and its applications: Short
signatures and more, in CT-RSA 2012, ser. LNCS, O. Dunkelman, Ed., vol. 7178. Springer, Feb. / Mar. 2012, pp. 260277.
D. Hofheinz, T. Jager, and E. Kiltz, Short signatures from
weaker assumptions, in ASIACRYPT 2011, ser. LNCS, D. H.
Lee and X. Wang, Eds., vol. 7073. Springer, Dec. 2011, pp.
647666.
D. Catalano, D. Fiore, and L. Nizzardo, Programmable hash
functions go private: Constructions and applications to (homomorphic) signatures with shorter public keys, in CRYPTO
2015. Springer, 2015, to appear.
D. Boneh and D. M. Freeman, Homomorphic signatures for
polynomial functions, in EUROCRYPT 2011, ser. LNCS,
K. G. Paterson, Ed., vol. 6632. Springer, May 2011, pp. 149
168.
D. Catalano, D. Fiore, and B. Warinschi, Homomorphic signatures with efficient verification for polynomial functions, in
CRYPTO 2014, Part I, ser. LNCS, J. A. Garay and R. Gennaro, Eds., vol. 8616. Springer, Aug. 2014, pp. 371389.
N. Attrapadung and B. Libert, Homomorphic network coding
signatures in the standard model, in PKC 2011, ser. LNCS,
D. Catalano, N. Fazio, R. Gennaro, and A. Nicolosi, Eds., vol.
6571. Springer, Mar. 2011, pp. 1734.
D. Catalano, D. Fiore, and B. Warinschi, Adaptive pseudo-free
groups and applications, in EUROCRYPT 2011, ser. LNCS,
K. G. Paterson, Ed., vol. 6632. Springer, May 2011, pp. 207
223.
, Efficient network coding signatures in the standard
model, in PKC 2012, ser. LNCS, M. Fischlin, J. Buchmann,
and M. Manulis, Eds., vol. 7293. Springer, May 2012, pp.
680696.
D. M. Freeman, Improved security for linearly homomorphic
signatures: A generic framework, in PKC 2012, ser. LNCS,
M. Fischlin, J. Buchmann, and M. Manulis, Eds., vol. 7293.
Springer, May 2012, pp. 697714.
N. Attrapadung, B. Libert, and T. Peters, Computing on authenticated data: New privacy definitions and constructions,
in ASIACRYPT 2012, ser. LNCS, X. Wang and K. Sako, Eds.,
vol. 7658. Springer, Dec. 2012, pp. 367385.
, Efficient completely context-hiding quotable and linearly homomorphic signatures, in PKC 2013, ser. LNCS,
K. Kurosawa and G. Hanaoka, Eds., vol. 7778.
Springer,
Feb. / Mar. 2013, pp. 386404.
S. Gorbunov, V. Vaikuntanathan, and D. Wichs, Leveled fully
homomorphic signatures from standard lattices, in 47th ACM
STOC. ACM Press, 2015, to appear.
Certified PUP: Abuse in Authenticode Code Signing

Platon Kotzias , Srdjan Matic , Richard Rivera , Juan Caballero
IMDEA
Universita degli Studi di Milano

Software Institute
platon.kotzias@imdea.org, srdjan.matic@unimi.it,
richard.rivera@imdea.org, juan.caballero@imdea.org
The full version of this paper will appear in the Proceedings of the 2015 ACM SIGSAC Conference on Computer and
Communications Security.
AbstractCode signing is a solution to verify the integrity
of software and its publishers identity, but it can be abused
by malware to look benign. This work performs a systematic
analysis of Windows Authenticode code signing abuse, evaluating
the effectiveness of existing defenses by certification authorities.
We build an infrastructure that automatically analyzes signed
malware, classifies it into operations, and produces a blacklist of
malicious certificates. We evaluate it on 350 K malware samples
from 2006-2015.
Our analysis shows the constant increase of signed malware
over time and that CA defenses such as identity checks and
revocation are not currently effective. Up to 97% of the signed
malware uses CA-issued certificates and only 15% of those
certificates are revoked. Our generated blacklist is 9x larger than
current ones. We analyze the code signing infrastructure of the
largest operations and show how they evolve over time, using
multiple identities and leveraging the lack of CA synchronization
to move from one CA to another. We also identify a design issue
in Authenticode where timestamped signed malware successfully
validates even after the revocation of their code signing certificate.
We propose hard revocations as a solution.
I. I NTRODUCTION
Malicious software (i.e., malware) is software that most
users will not want to install consciously on their computers. It
includes clearly malicious software (e.g., trojans, ransomware,
keyloggers) as well as potentially unwanted programs (PUP)
such as adware and spyware. Publishers of malicious software
are always looking for ways to make their code look benign
in order to convince the user to install it and avoid detection.
One such way is code signing, where the software is distributed
with a digital signature which, if valid, certifies the integrity
of the software and the identity of the publisher. Signed code
looks more benign and is often assigned higher reputation by
security products, e.g., reputation engines [7]. In Windows,
properly signed application code avoids scary warnings when
a user executes it and is assigned higher reputation when
downloaded through Internet Explorer. Furthermore, kernelmode code is required to be signed. Aware of these benefits
attackers are increasingly leveraging signed code for their
goals, e.g., for launching notorious targeted attacks [2][4].
To sign Windows-based malware, publishers need to obtain
a valid code signing certificate from a Certification Authority
(CA). This should pose a barrier for malicious software, since
86
it requires providing the publishers identity to the CA and

paying a fee ($60$500 for 1-year certificates). Furthermore,
when malicious software is observed in the wild signed with
a valid certificate, the CA that issued the certificate should
swiftly revoke it. However, it is not clear how well defenses
such as identity checks and revocation work. Prior work in
2010 by two AV vendors [8], [9] showed that signed samples
were not uncommon in malware datasets. But, there has been
no systematic study analyzing the extent to which malware
(e.g., bots, trojans) and PUP (e.g., adware, bundles) are abusing
code signing and how well defenses such as identity validation
and revocation work.
In this work we perform a systematic study on abuse of the
Windows Authenticode [6] code signing solution by malicious
software. We build an infrastructure that takes as input a large
number of potentially malicious samples, filters out benign
samples and those that are not signed, and thoroughly analyzes
signed samples including their digital signatures, certificate
chains, certificate revocation, and file timestamping (i.e., thirdparty certification of the time they saw some signed code). It
also classifies signed samples into operations. Our infrastructure automatically builds a blacklist of malicious certificates,
which can be used as input by CAs to perform revocation, or
users can embed it into the Windows untrusted certificate store
to block malicious code.
Using our infrastructure we analyze over 350 K malware
samples distributed between 2006 and Februrary 2015, of
which 141 K (42%) are signed. This process outputs a blacklist
of over 2,900 malicious code certificates, 9x larger than existing blacklists [1]. Our analysis uncovers that signed malware is
on the rise since 2010, e.g., 87% of the malware in our corpus
first seen in 2014 is signed. Up to 97% of signed malware
uses a valid code signing certificate, showing limitations of the
identification procedures used by CAs. Even more worrying,
only 15% of the malicious code signing certificates in our
blacklist have been revoked and the best CA revokes merely
43% of the malicious certificates it issues.
We identify a problematic interaction between revocation
and timestamping in Authenticode, where timestamped signed
malware still validates even if their code signing certificate
is revoked. To address this issue CAs need to perform hard
revocations that invalidate all malware signed by a certificate.
Our classification of signed malware into operations shows

that the largest operations using signed malware correspond to
potentially unwanted programs such as adware and gray payper-install programs that offer users to install suspicious thirdparty programs. The classification enables examining the temporal evolution of their code signing infrastructure, identifying
how they react to revocation. Large operations use multiple
identities to convince CAs to issue them certificates. One
operation uses 37 different companies and 2 individuals across
5 countries to obtain 88 valid code signing certificates from 4
CAs. They reuse identities across different CAs; when revoked
by one CA, miscreants leverage the lack of synchronization
among CAs to request other certificates from others.
We also leverage the fact that timestamped malware contains a trusted timestamp close to its creation to evaluate
how fast VirusTotal [5], a large malware repository collects
malware.
II. C ONCLUSION
We have performed a systematic analysis of Windows
Authenticode code signing abuse by building an infrastructure
that automatically analyzes signed malware, classifies it into
operations, and produces a blacklist of malicious certificates.
We have identified a design issue in Authenticode where
timestamped signed malware successfully validates even after
the revocation of their code signing certificate. We have
proposed hard revocations as a solution. We have evaluated our
infrastructure on 350 K malware samples. Our analysis shows
that CA defenses such as identity checks and revocation are
not currently effective. Up to 97% of the signed malware uses
CA-issued certificates and only 15% of those certificates are
revoked. Our generated blacklist is 9x larger than current ones.
We have analyzed the code signing infrastructure of the largest
operations and show how they evolve over time, using multiple
identities and leveraging the lack of CA synchronization to
move from one CA to another. We have also used timestamped
malware to evaluate the speed with which the VirusTotal online
service collects malware.
R EFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Ccss forum: Common computing security standards.

http://www.
ccssforum.org/.
Malware Analysis Report - W64/Regin, Stage 1. https://www.f-secure.
com/documents/996508/1030745/w64 regin stage 1.pdf.
Stuxnet Under the Microscope.
http://www.eset.com/us/resources/
white-papers/Stuxnet Under the Microscope.pdf.
Unveiling Careto - The Masked APT. http://kasperskycontenthub.com/
wp-content/uploads/sites/43/vlpdfs/unveilingthemask v1.0.pdf.
Virustotal- free online virus, malware and url scanner. http://www.
virustotal.com/.
Microsoft. Windows authenticode portable executable signature format, Mar. 21 2008. http://download.microsoft.com/download/9/c/5/
9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode PE.docx.
MSDN.
Stranger Danger - Introducing SmartScreen Application Reputation.
http://blogs.msdn.com/b/ie/archive/2010/10/13/
stranger-danger-introducing-smartscreen-application-reputation.aspx.
J. Niemala. Its signed, therefore its clean, right?, May 2010. Presentation at the CARO 2010 Workshop.
M. Wood. Want my autograph? The use and abuse of digital signatures
by malware. In Virus Bulletin Conference, 2010.
87
Aplicacin del cifrado con preservacin del formato

para eventos de ciberseguridad
L. Gonzlez-Manzano1, J. M. de Fuentes1, V. Gayoso Martnez2
Computer Security Lab (COSEC). Universidad Carlos III de Madrid
2
Instituto de Tecnologas Fsicas y de la Informacin. Consejo Superior de Investigaciones Cientficas (CSIC)
{lgmanzan, jfuentes}@inf.uc3m.es, {victor.gayoso}@iec.csic.es
1
Resumen-La comparticin de informacin sobre eventos de

ciberseguridad presenta mltiples retos. Uno de ellos es la
ocultacin de la informacin transmitida, de forma que pase
inadvertida a un observador. Adems de la esteganografa, se han
propuesto mecanismos de cifrado que persiguen un fin similar.
Uno de ellos es el cifrado con preservacin del formato (format
preserving encryption). En este artculo se describe el trabajo en
curso sobre su uso en el contexto de la ciberseguridad.
I.
INTRODUCCIN
El ciberespacio juega un papel fundamental en las

sociedades modernas. Sin embargo, la Estrategia Nacional de
Seguridad pone de manifiesto que el ciberespacio es un entorno
muy accesible y de difcil control [1].
Para responder adecuadamente a estas amenazas es crtico
que las organizaciones cooperen entre s. Un pilar esencial de
dicha cooperacin es la comparticin de informacin de
ciberseguridad sobre vulnerabilidades, amenazas, actores,
tcticas, incidentes en curso, contramedidas, etc. [2].
Este trabajo se centra en la proteccin de la informacin
intercambiada acerca de eventos de ciberseguridad. Se define
un evento de seguridad como un fallo o problema que
compromete los sistemas de informacin, los servicios o la red,
es decir, indica que una poltica de seguridad ha sido violada o
que una salvaguarda ha fallado [7].
Un problema abierto en este entorno es que la propia
existencia de la comunicacin revela cierta informacin a un
observador. Por ejemplo, si dos entidades cooperantes
intercambian datos en un momento determinado, es posible que
una de ellas haya sufrido un evento de seguridad. Es necesario
proporcionar algn mecanismo que impida esta circunstancia.
En este artculo se describe el trabajo en curso para la
aplicacin de una tcnica de cifrado en este contexto.
Particularmente, la tcnica considerada es el cifrado con
preservacin del formato (en adelante FPE, del ingls Format
Preserving Encryption) [3].
II. NOMBRADO DE EVENTOS DE CIBERSEGURIDAD
El foco de este trabajo se sita en posibilitar la comparticin
de forma inadvertida para un tercero. Como paso previo, es
necesario explorar las herramientas existentes para una
comparticin efectiva.
En los ltimos tiempos, se han propuesto numerosos
mecanismos para intercambiar esta informacin [4]. Adems,
es imprescindible que todas las partes nombren los eventos de

seguridad de forma unvoca. En concreto se han propuesto
algunos formatos unificados para nombrar los eventos de
ciberseguridad. En esta seccin se revisan brevemente dos
formatos representativos. El uso de formatos bien definidos es
la base fundamental para la aplicacin del FPE.
A. Recomendacin ITU-T X.1520
La recomendacin X.1520 de la ITU-T persigue
proporcionar una forma estructurada de intercambio global de
informacin pblicamente conocida sobre vulnerabilidades y
exposiciones maduras [5]. Para ello, determina el correcto uso de
los CVE (Common Vulnerabilities and Exposures). Dichos
CVE aglutinan las diferentes vulnerabilidades de diversos
programas y plataformas.
B. STIX
STIX (Structured Threat Information Expression) es una
iniciativa de la corporacin MITRE para estructurar esta
informacin [6]. En dicho lenguaje se definen numerosos
conceptos:
ciber-observable,
indicadores,
tctica/tcnica/procedimiento de ataque, plataforma objetivo,
tipo de atacante, etc. Por ejemplo, en la Figura 1 se muestra
parte del indicador de un ataque de phishing. Se describe el
ttulo, el tipo de ataque, cmo ha ocurrido y la fecha del
mismo.
Fig. 1 Indicador (porcin) de un ataque de phising utilizando STIX [11].
III. CIFRADO CON PRESERVACIN DEL FORMATO (FPE)

Los sistemas de cifrado FPE se basan en que el formato del
texto cifrado sea equivalente al del texto en claro. Este trmino
fue acuado por Terence Spies [12, 13] proponiendo distintas
aplicaciones, entre las que destacan el cifrado de nmeros de la
seguridad social o nmeros de tarjetas de crdito (Figura 2).
FPE hace uso de una clave simtrica K utilizada para cifrar
un texto X de un formato N descrito en el conjunto finito N,
donde N se corresponde con todos los posibles espacios de los
88
mensajes, es decir, con los posibles valores de textos en claro y

cifrados. Para cifrar X N se realiza la llamada a un algoritmo
de cifrado proporcionando la clave K y el texto X. Esto
producir un texto cifrado Y = EK(X) manteniendo que Y N.
El proceso de descifrado, DK(Y), proporcionar nuevamente el
texto X. Adems, EK() ha de corresponderse con una
permutacin aleatoria en el espacio de mensajes N.
En base a la descripcin realizada, un buen sistema FPE es
aquel en el que un adversario no es capaz de distinguir un texto
cifrado con una permutacin EK() y ese mismo texto cifrado
con una permutacin K().
informacin. Este tipo de primitivas podra inspirarse en las de

la criptografa ligera (lightweight cryptography) [9].
Por otro lado, una cuestin importante es aplicar esta tcnica
de forma que los resultados pudiesen correlarse. La correlacin
permite conocer el ataque que se padece o el grado de avance
del mismo [10]. Esto tendra un elevado potencial disuasorio
para el observador, quien no podra establecer si est
visualizando los eventos reales o el resultado de cifrarlos.
La aleatoriedad de los resultados es tambin crtica en este
entorno. Los eventos de seguridad pueden repetirse con gran
frecuencia, lo que podra dar lugar a ataques de texto claro
escogido que permitiesen revelar la clave. Se necesita, por
tanto, que los resultados sean impredecibles.
V. CONCLUSIONES
Fig. 2. Esquema de cifrado con preservacin de formato
A. Aproximacin propuesta para eventos de ciberseguridad

Para utilizar FPE en relacin con eventos de seguridad se
pueden distinguir los siguientes pasos:
1. Establecer qu formato se va a considerar.
2. Determinar el espacio de mensajes N. Se cifran los
datos del tipo de ataque, acciones a emprender, etc. o
slo un dato concreto, por ejemplo el elemento
observado?
3. Realizar anlisis de los sistemas FPE existentes y
escoger el ms apropiado en su caso, modificndolo o
desarrollando uno que satisfaga las necesidades.
Asumiendo que N es el espacio de mensajes compuesto
por los caracteres del alfabeto y los nmeros, se podra
estudiar la posibilidad de utilizar el algoritmo
presentado en [14]. As se conseguira el cifrado de
caracteres en base a su cdigo binario mediante un
cifrador de bloque basado en una estructura Feistel.
En relacin con el ejemplo presentado en la Figura 1, un
cifrado FPE se muestra en la Figura 3 (enmarcado en rojo). En
este caso, por ejemplo, el cifrado de Malicious E-mail se
corresponde con Malicious Docume, as como la fecha de
comienzo, 2012-12-01, que puede cifrarse como 2013-0212.
La comparticin de informacin sobre eventos de

ciberseguridad ha recibido gran atencin por parte de la
comunidad investigadora en los ltimos tiempos. Entre los
numerosos retos que sta plantea, este artculo ha presentado el
trabajo en curso para la proteccin de dicho intercambio.
Particularmente, se propone desarrollar una aproximacin
basada en el cifrado con preservacin del formato (FPE).
Gracias a FPE, el observador no es capaz de distinguir si
visualiza el mensaje en claro o su resultado cifrado, en tanto
que ambos mantienen la misma estructura.
AGRADECIMIENTOS
Este trabajo ha sido financiado a travs del proyecto
CIBERDINE (S2013/ICE-3095), otorgado por la Comunidad
Autnoma de Madrid, y del proyecto SPINY (TIN2013-46469R), otorgado por el MINECO.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
Fig 3. Cifrado FPE de indicador de phishing
IV. LNEAS DE TRABAJO EN CURSO
[13]
En esta lnea de trabajo existen numerosos aspectos que

merecen atencin investigadora. En primer lugar, el desarrollo
de tcnicas FPE ligeras permitira un intercambio gil de
[14]
89
Espaa, Estrategia Nacional de Seguridad, 2013.

E. Gal-or y A. Ghose, The economic incentives for sharing security
information. Information Systems Research, 2005, vol. 16, p. 186-208.
M.
Bellare,
et
al.,
Format-preserving
encryption.
https://eprint.iacr.org/2009/251.pdf (ltimo acceso Julio 2015).
L. Dandurand, Cyber Defense Data Exchange and Collaboration
Infrastructure (CDXI). ITU-T Workshop, 2010
ITU-T, X.1520: Vulnerabilidades y estados comunes, 2014.
S. Barnum, Standardizing Cyber Threat Intelligence Information with
the
STIX,
disponible
en
http://stixproject.github.io/gettingstarted/whitepaper/ (ltimo acceso Julio 2015).
ISO, ISO27001-Glosario, disponibles en http://www.praxiom.com/iso27001-definitions.htm (ltimo acceso Julio 2015).
M. Brightwell and H. Smith. Using datatype-preserving encryption to
enhance data warehouse security. 20th NISSC Proc., pp. 141149, 1997
T.
Eisenbarth,
A
survey
of
lightweight-cryptography
implementations. IEEE Design & Test of Computers, 2007, p. 522-533.
F. Cuppens, A. Miege, Alert correlation in a cooperative intrusion
detection framework.. Security and Privacy, 2002. Proceedings. 2002
IEEE Symposium on. IEEE, 2002. p. 202-215.
Ejemplos
de
STIX,
disponible
en:
http://stix.mitre.org/about/example_phishing.html (lt. acceso Julio 2015)
Spies, Terence. "Format preserving encryption." Unpublished white
paper, www. voltage. com Database and Network Journal. 2008.
Black, John, and Phillip Rogaway. "Ciphers with arbitrary finite
domains." Topics in CryptologyCT-RSA 2002. Springer Berlin
Heidelberg, 2002. 114-130
Li, Min, et al. "Format-preserving encryption for character data." Journal
of Networks 7.8 (2012): 1239-1244.
1
Modelling ephemeral leakage in group key

exchange protocols
Mara Isabel Gonzalez Vasco1 , Angel L. Perez del Pozo1 , Adriana Suarez Corona2
1
Universidad Rey Juan Carlos, 2 Universidad de Leon
1
{mariaisabel.vasco, angel.perez}@urjc.es, 2 asuac@unileon.es
ResumenWhen a group key exchange protocol is executed, the session

key is typically extracted from some ephemeral values generated during
the execution. The leakage of this so-called ephemeral keys has been extensively analyzed in the two party case, yet very few works are concerned
with it in the group setting. We augment previous security models to capture the adversarial ability to retrieve long-term and ephemeral keys of
users, with the sole restriction of not getting both secret values from the
same user (during or after the protocol execution). We further tune up our
model so that it can also be applied to the (much less studied) certificateless
setting.
I. I NTRODUCTION
Group key establishment protocols are a fundamental cryptographic building block allowing n 2 participants to agree
upon a common secret key. It is usually assumed that these participants hold both long-term secrets, which are typically used
for authentication and ephemeral secrets, which are sessionspecific randomly generated values that provide enough entropy for the key to be indistinguishable from random in some
sense. Different security models have tried to capture accordingly the effect of leaking long-term keys, ephemeral keys or
values related to them ([2], [9], [10]). In this paper we adapt
the two-party model from [1] to the group setting, arguing why
our model is strictly stronger than previously proposed ones.
For the certificateless case we propose a security model for
the group setting, based on the two-party model from [13] and
compare it to the previous proposal from [15].
II. S TRONG SECURITY FOR GROUP KEY EXCHANGE
We sketch here our augmented security model which is a
modification of the model of Bohli et al [6], which in turns
builds in previous models [3], [4], [5], [11]. Our model differs
from previous ones in that it treats separately the session state
(state) and the session ephemeral keys (rand) from a given session, following the rationale from [7].
At this, users are modeled as probabilistic polynomial time
(ppt) Turing machines. Each user U U may execute a polynomial number of protocol instances in parallel. To refer to
instance si of a user Ui U we use the notation si i (i N).
Protocol instances. A single instance si i can be taken for
a process executed by Ui . To each instance we assign seven
variables , informally described next :
s
usedi i indicates whether this instance is or has been used for
a protocol run;
s
statei i keeps the internal state of the Turing machine that
executes the protocol;
s
randi i keeps the session-specific atomic secret values
typically values generated uniformly at random which will
be referred to as ephemeral keys. More precisely, these are any
90
values that cannot be computed from long-term secret keys or

other values received/computed previously in the session.
s
termi i shows if the execution has terminated;
si
sidi denotes a session identifier;
s
s
pidi i stores the set of identities of those users that i i aims
at establishing a key withincluding Ui himself;
s
acci i indicates if the user accepted the session key;
si
s
ski stores the session key once it is accepted by i i .
Adversarial capabilities. We restrict to ppt adversaries. The
capabilities of an adversary A are made explicit through a number of oracles allowing A to communicate with protocol instances run by the users:
s
Send(Ui , si , M ); sends message M to the instance i i and
returns the reply generated by this instance.
su
su
Execute({u11 , . . . , u }); executes a complete protocol
run among the specified unused instances.
s
Reveal(Ui , si ); yields the session key ski i .
Test(Ui , si ) Only one query of this form is allowed for an
active adversary A. Provided that sksi i is defined, A can execute this oracle query at any time when being activated. Then
with probability 1/2 the session key sksi i and with probability
1/2 a uniformly chosen random session key is returned.
s
RevealRand(Ui , si ); returns the value stored in randi i .
Corrupt(Ui ); returns the long term key hold by Ui .
Note that we dont grant the adversary access to the full state
of an oracle, as done in the two party setting by Cremers [7].
Before we define correctness and key privacy, we introduce
partnering to express which instances are associated in a common protocol session.
s
Partnering. We refer to instances si i , j j as being partnered
sj
sj
s
si
si
si
if sidi = sidj , pidi = pidj and acci = accj j = true.
Correctness. We call a group key establishment protocol P
correct, if in the presence of a passive adversary Ai. e., A
must not use the Send oraclethe following holds: for all i, j
s
s
s
with sidsi i = sidj j , pidsi i = pidj j and accsi i = accj j = true,
sj
si
we have ski = skj 6=NULL.
Freshness. A Test-query should only be allowed to those instances holding a key that is not for trivial reasons known to the
adversary. To this aim, an instance si i is called fresh if
s
acci i = true
sj
s
A never called Reveal(Uj , sj ) with i i and j being partnered.
sj
s
If i i and j are partnered and A called Corrupt(Uj ), then
s
any message sent to si i on behalf of j j must indeed come
sj
si
from j intended to i .
A never called both Corrupt(Uj ) and RevealRand(Uj , sj )
s
with si i and j j being partnered.
2
Key Privacy We say a group key establishment achieves key

privacy, if the advantage AdvA (`) of a ppt adversary A in attacking protocol P is a negligible function in the security parameter, where the advantage is defined as
AdvA := |2 Succ 1|.
Here Succ is the probability that the adversary queries Test on
a fresh instance si i and guesses correctly the bit b used by the
Test oracle in a moment when si i is still fresh.
It is easy to see that our new model outperforms the proposal from [16], where the EphemeralKeyReveal calls only
retrieve the ephemeral Diffie-Hellman exponents generated on
each session (and does not involve the random nonces ki that
actually fully determine the session key). Furthermore, other
security properties such as KCIR (Key Compromise Impersonation Resilience, first defined in [9]) are also captured by our
freshness definition. In a full version of this work, we will
ellaborate on how a group key exchange protocol that can actually be proven secure in this stronger sense can be derived.
The model proposed by Teng and Wu [15] is weaker than the

model above, since it does not allow leakage of ephemeral keys
of any party from the target session. In fact, if ephemeral keys
are revealed, the session key established with their protocol can
be fully determined.
If we restrict our model to the two party case, it is also
stronger than the models in [13] and [14], since they only consider passive adversaries. Actually, an active adversary sending
a message (rA P, xA P ), can determine the key computed with
the proposal in [13] after revealing both long-term keys at the
end of the execution without violating freshness.
Acknowledgements
M.I. Gonzalez Vasco and Adriana Suarez Corona are partially supported by MINECO research projects MTM2013-41426R and MTM2013-45588-C3-1-P respectively.
R EFERENCIAS
[1] F. Bergsma and T. Jager and J. Schwenk, One-Round Key Exchange with
Strong Security: An Efficient and Generic Construction in the Standard
Model, Public-Key Cryptography PKC 2015, Lecture Notes in Computer Science, vol. 9020, 2015 pp.477494.
III. C ERTIFICATELESS GROUP KEY EXCHANGE
[2] E. Bresson and M. Manulis, Securing Group Key Exchange Against
Strong Corruptions and Key Registration Attacks, in Int. J. Appl. CrypWhen protocols are based on certificateless public key cryptol.,vol. 1,n. 2, 2008, pp.91107.
tography, the long-term key is comprised of two distinguished [3] M. Bellare and P. Rogaway, Entity Authentication and Key Distribution,
in Advances in CryptologyCRYPTO 93, Lecture Notes in Computer
values. The security model we propose, based on [13], is as
Science, Vol 773, 1993, pp. 232249.
above except for the following:
[4] M. Bellare and P. Rogaway, Provably Secure Session Key Distribution
Adversarial capabilities. Now, we include oracles modelling
The Three Party Case, in Proceedings of the 27th Annual ACM Symposium on Theory of Computing, STOC95, ACM Press, 1995, 5766.
the leakage of the long-term keys separately. Thus, the oracle
[5]
M. Bellare, D. Pointcheval and P. Rogaway, Authenticated Key Exchange
Corrupt is replaced by the following oracles:
Secure Against Dictionary Attacks, in Advances in Cryptology EU RevealIDBasedSecret(Ui ) Returns the ID-based long term
ROCRYPT00, Lecture Notes in Computer Science, Vol 1807, 2000, pp.
139155.
key hold by Ui .
[6] J.M. Bohli, M.I. Gonzalez Vasco and R. Steinwandt, Secure Group Key
RevealSecretValue(Ui ) Yields the long term secret value
Stablishment Revisited, International Journal of Information Security,
generated by Ui corresponding to its certificateless public key.
2007, vol. 6, n. 4, pp. 243254.
[7]
C. Cremers, Session-state Reveal is stronger than Ephemeral Key Reveal:
Moreover, to consider the corruption of the key generation
Attacking the NAXOS Authenticated Key Exchange Protocol, in Applied
center we also include the following oracle:
Cryptography and Network Security. Springer Berlin Heidelberg, 2009.
pp. 2033.
RevealMasterKey Returns the master secret key.
The adversary is also allowed to replace certificateless public [8] C. Cremers and M. Feltz, Beyond eCK: perfect forward secrecy under actor compromise and ephemeral-key reveal, in Designs, Codes and Crypkeys, which we model as follows:
tography, vol. 74, n. 1, 2015, pp. 183218.
[9]
M. C. Gorantla and C. Boyd and J.M. Gonzalez Nieto, Modeling Key
ReplacePublicKey(Ui , pk) This replaces users certificateCompromise Impersonation Attacks on Group Key Exchange Protocols,
less public key by pk chosen by the adversary. This new public
in Public Key Cryptography PKC 2009, Lecture Notes in Computer Scikey will be used for future communication and computations.
ence, vol. 5443, 2009, pp. 105123.
Freshness. We require a certificateless key establishment [10] M. C. Gorantla and C. Boyd and J.M. Gonzalez Nieto and M. Manulis,
Generic One Round Group Key Exchange in the Standard Model, in Inscheme to be secure as long as each party involved in a sesformation, Security and Cryptology ICISC 2009, Lecture Notes in Comsion has at least one uncompromised secret. To define freshputer Science, vol. 5984, 2010, pp. 115.
ness in this setting we divide the queries regarding the secrets [11] J. Katz and M. Yung, Scalable Protocols for Authenticated Group Key
Exchange in Advances in Cryptology CRYPTO03, Lecture Notes in
into three types:
Computer Science, Vol 2729, 2003, pp. 110125.
queries on the ID-based part of the scheme: RevealMasterKey [12] B. LaMacchia and K. Lauter and A. Mityagin, Stronger Security of
Authenticated Key Exchange, in Provable SecurityProvSec07, Lecture
and RevealIDBasedSecret.
Notes in Computer Science, vol. 4784, 2007, pp. 116.
queries on the public key part of the scheme: RevealSecretValue[13] G. Lippold and C. Boyd and J. M. Gonzalez Nieto, Strongly Secure
Certificateless Key Agreement, in Pairing-Based CryptographyPairing
and ReplacePublicKey.
2009, Lecture Notes in Computer Sciences, vol. 5671 , 2009, pp. 206
queries on the keys of a particular session: RevealRand.
230.
For a session to be fresh in this setting, the last two condi- [14] C. Swanson and D. Jao, A Study of Two-Party Certificateless Authenticated Key-Agreement Protocols, in Progress in Cryptology
tions in the freshness definition above are replaced by:
sj
INDOCRYPT 2009, Lecture Notes in Computer Sciences, 2009, pp. 57
s
If i i and j are partnered and A called queries on both
71.
sj
the ID-based part and the public key part of j , then any mes- [15] J. Teng and C. Wu, A provable authenticated certificateless group key
agreement with constant rounds, in Journal of Communications and Nets
s
sage sent to si i on behalf of j j must indeed come from j j
works, vol 14, n. 1, 2012, pp. 104110.
si
intended to i .
[16] J. Zhao, G. Gu and M.C. Gorantla, Stronger Security Model of Group
sj
si
Key Agreement, in Proceedings of the 6th ACM Symposium on Informa no session U partnered with U has been asked all three
j
i
tion, Computer and Communications Security. ACM, 2011. pp. 435440.
types of reveal queries (is fully corrupt);
91
JNIC2015
Deteccin de funciones inseguras en

repositorios de software libre
Alfonso Muoz Muoz1, Pablo Gonzlez Prez2
Criptored Universidad Politcnica de Madrid. Espaa
ElevenPaths, Telefnica Digital. Identity & Privacy, Madrid. Espaa
amunoz@diatel.upm.es1, pablo.gonzalez2@11paths.com
Resumen- La deteccin de vulnerabilidades software es una
temtica de gran complejidad en la que se ha invertido, y se invierte,
gran cantidad de esfuerzos. Por desgracia, ningn software es 100%
seguro y a nivel particular o empresarial se ejecuta software de
procedencias diversas cuya garanta debe ser cuestionada. En nuestra
investigacin centramos la atencin en la deteccin de funciones
peligrosas en repositorios de software libre, particularizando en los
paquetes por defecto de Ubuntu. Analizados 45.153 paquetes es
posible afirmar la existencia de funciones inseguras en paquetes
oficiales, algunas de las cuales introducen vulnerabilidades en los
sistemas Linux que las instalen.
Keywords - software inseguro, Ubuntu, vulnerabilidades,
repositorio, deteccin
I.
SOFTWARE LIBRE VS SOFTWARE PRIVATIVO
En las ltimas dcadas multitud de esfuerzos se han destinado

a analizar y detectar vulnerabilidades en programas software.
En ocasiones, quizs de forma interesada por una u otra parte,
se intenta argumentar sobre la calidad del software en funcin
de su naturaleza y el proceso de revisin del cdigo, ms abierto
a cualquier usuario o ms restringido en funcin de diversas
polticas. En este escenario es habitual encontrarse grandes
defensores y detractores de la calidad del software en funcin
de si se define como software libre o por el contrario es software
privativo. Se entiende por software libre, segn la definicin
establecida por Richard Stallman y la Free Software Foundation
(FSF), su principal impulsora, como aquel software que puede
ser usado, copiado, estudiado, modificado y redistribuido
libremente de varias formas. Una ventaja habitual que se le
otorga a este tipo de filosofa es la posibilidad de que cualquier
usuario pueda analizar el cdigo fuente del software. En
principio, lo anterior debera ayudar a generar software ms
fiable y seguro ya que potencialmente cualquier usuario de
Internet podra corregir o sugerir mejoras. Es importante
recordar que en funcin de la licencia software utilizada, puede
que se permita analizar el cdigo fuente, pero no estemos
hablando de software libre si no de software de cdigo abierto.
Ejemplos de licencias son: LGPL, AGPL, LBSD, MPL, etc. De
hecho, en la prctica el software de cdigo abierto y el software
libre comparten muchas de sus licencias, si bien es cierto que
difieren en el objetivo del mismo. Por un lado, la Open Source
Initiative (OSI), fundada en 1998 por Eric S. Raymond y Bruce
Perens, busca darle mayor relevancia a los beneficios prcticos
de compartir el cdigo fuente, e interesar a las principales casas
de software y otras empresas de la industria, mientras que la
FSF prefieren plantear el asunto en trminos ticos.
92
Por el otro lado, nos encontramos con el software no libre. La

FSF define el software privativo (software no libre) como aquel
que limita la libertad del usuario para usar, estudiar, distribuir o
mejorar el mismo. Este tipo de software est distribuido bajo
una licencia ms restrictiva que reserva la mayora de los
derechos de modificacin, duplicacin y redistribucin para el
dueo del copyright. En la prctica, existen zonas grises en
estas definiciones y en funcin de nuestras necesidades es
posible que se obtengan ms ventajas que inconvenientes en
una u otra filosofa. Por ejemplo, ciertos usuarios pueden pensar
que el software privativo, entindase en este ejemplo como
software propietario que vende una empresa y no permite
acceso a su cdigo, debera tener un cdigo ms trabajado,
como resultado de un equipo profesional detrs, y permitir
mantenimiento continuado y actualizacin del mismo de una
forma profesional/empresarial. Sin embargo, este software por
su definicin es menos flexible ya que puede que la empresa
que lo genera no cree las variantes adecuadas para adaptarse a
las necesidades concretas de un particular o empresa.
Adicionalmente a todas las cuestiones tcnicas, que podran
indicar que software es ms o menos fiable y seguro, existen
todas una serie de implicaciones econmico-polticas que
complican an ms la decisin de qu tipo de software utilizar.
Tradicionalmente el negocio detrs del software libre se ha
caracterizado por la oferta de servicios adicionales al software
(tradicionalmente gratuito) como la personalizacin y el
mantenimiento. Por ejemplo, la traduccin del software a un
idioma concreto que posiblemente no fuera rentable
comercialmente para una gran empresa. Adicionalmente, tiene
una caracterstica social importante, puesto que el software
libre permite el libre uso, modificacin y redistribucin, a
menudo encuentra un hogar entre usuarios para los cuales el
coste del software no libre es a veces prohibitivo, o cmo
alternativa a la piratera. Se defiende con firmeza el ahorro que
puede obtenerse con este tipo de software frente al software
privativo y especialmente limitar la dependencia que un usuario
o empresa tiene de una corporacin concreta que desarrolla ese
software. Existe una fuerte tendencia a la defensa de su uso en
sectores estratgicos y administracin pblica a lo largo del
planeta. En paralelo, en el modelo de negocio del software de
cdigo cerrado predomina la venta de licencias por su uso,
opcionalmente con servicios de actualizacin y mantenimiento.
En resumen, en funcin de las necesidades concretas de un
usuario o empresa y del software necesario a utilizar, sea
JNIC2015
software libre o no, existen ventajas e inconvenientes a analizar.

No necesariamente el software libre tiene porqu ser ms
seguro/fiable y resolver los problemas concretos de una
organizacin. En cualquier caso, en esta investigacin se
focaliza el esfuerzo, como aportacin a la mejora del cdigo
libre disponible a la comunidad de Internet, en el anlisis de
aspectos de seguridad relacionado con software real disponible
en los repositorios de software libre, con la intencin de
responder unas cuestiones bsicas: Es posible detectar de
forma sencilla fallos de seguridad en herramientas que deberan
ser auditadas por la comunidad? Son fiables los repositorios
de software libre?
II. REPOSITORIOS DE SOFTWARE LIBRE. SON
CONFIABLES?
En la ltima dcada muchas lneas se han escrito sobre la
relacin entre software libre y software seguro. En la prctica
la gran mayora de estas estn relacionadas con la posibilidad
de revisar el cdigo fuente y en funcin de los cambios
necesarios poder modificarlo y distribuirlo. Sin duda, existen
ventajas tcnicas claras de utilizar este tipo de software que
influyen en el mundo de la seguridad informtica:
como el ao negro del Open Source debido a vulnerabilidades

tan mediticas como Heartbleed [2] o Shellshock [3]. En
resumidas cuentas, el software libre o de cdigo abierto no es
necesariamente ms seguro que el software privativo aunque es
mucho ms flexible para ser analizado y modificado. Ante esta
situacin solo cabe preguntarse una cuestin: Qu
herramientas de software libre o de cdigo abierto utilizar?
Cmo se agrupan? Son algunas ms fiables que otras?
Sin duda, uno de los problemas relacionados con el software
libre/cdigo abierto es la gran dispersin entre distribuciones y
repositorios software (donde descargarse programas). Por
ejemplo, existen distribuciones que estn soportadas
comercialmente, como Fedora (Red Hat), openSUSE (Novell),
Ubuntu (Canonical Ltd.) y Mandriva; distribuciones
mantenidas por la comunidad, como Debian y Gentoo; y
distribuciones que no estn relacionadas con ninguna empresa
o comunidad, como es el caso de Slackware. Todas las
distribuciones son igual de fiables? Existen alguna poltica
adicional de revisin de cdigo en cada una de estas
distribuciones? Son confiables?
No es sencillo responder a las cuestiones anteriores de manera
generalista. Por este motivo, se ve interesante centrar nuestro
inters en una de las distribuciones Linux ms populares a nivel
mundial (Ubuntu), y analizar cmo funciona su repositorio y el
cdigo fuente de las herramientas que alberga. Antes de esto
entendamos un poco mejor como funciona esta distribucin y
el proceso de publicacin y verificacin de aplicaciones.
a) El anlisis del cdigo fuente puede ser auditado por cualquier

persona con los conocimientos suficientes.
b) El cdigo puede ser modificado y distribuido. Esto puede
provocar mejoras o parches que corrijan problemas detectados.
Adicionalmente, las organizaciones pueden adaptar el software
a sus necesidades eliminando funcionalidades que no necesitan,
lo cual necesariamente reducir problemas a futuro (poltica de
recursos mnimos).
c) El coste del software libre (se distribuye sin cargo) permite
difundir tecnologa de seguridad informtica (parches,
cortafuegos, IDS, etc.) que facilita crear un ecosistema de
comunicaciones y procesamiento de datos ms seguro. En
general, estas modificaciones no estn sujetas a criterios
comerciales tpicos como el time to market y los aspectos
tcnicos suelen prevalecer frente a otros criterios.
En este escenario idlico la tendencia a utilizar software libre, o
al menos de cdigo abierto, debera ser clara. Aunque, quizs,
la asuncin de que el cdigo fuente es revisado
concienzudamente por la comunidad de usuarios debera
ponerse en cuarentena y optar por una poltica ms activa en
este sentido. De hecho, en los ltimos aos diferentes sucesos
graves han puesto esto de manifiesto. Por ejemplo, uno de los
sucesos ms significativos fue la vulnerabilidad encontrada en
uno de los paquetes software ms famosos a nivel mundial
(OpenSSL/Debian) y por tanto se asume que ms revisados.
Despus de una modificacin del cdigo, se introdujo por error
un cambio que minimiz la seguridad del generador de nmeros
aleatorios que utiliza este software, permitiendo ataques
prcticos a procesos criptogrficos, falsificar certificados X.509
o atacar claves SSH. Esta vulnerabilidad estuvo presente en el
software durante 2 aos [1]. De hecho, esto est empezando a
ser ms comn de lo deseable. El ao pasado (2014) se defini
93
El sistema operativo Ubuntu est basado en GNU/Linux

(Debian) y se distribuye como software libre. Su patrocinador,
Canonical, es una compaa britnica propiedad del empresario
sudafricano Mark Shuttleworth. Ofrece el sistema de manera
gratuita, y se financia por medio de servicios vinculados al
sistema operativo y vendiendo soporte tcnico. Cada seis meses
se publica una nueva versin de Ubuntu. Esta recibe soporte por
parte de Canonical durante nueve meses por medio de
actualizaciones de seguridad, parches para bugs crticos y
actualizaciones menores de programas. Las versiones LTS
(Long Term Support), que se liberan cada dos aos, reciben
soporte durante cinco aos en los sistemas de escritorio y de
servidor. Ubuntu internamente divide todo el software en cuatro
secciones, llamadas componentes, para mostrar diferencias en
licencias y la prioridad con la que se atienden los problemas que
informen los usuarios. Estos componentes son: main,
restricted, universe y multiverse. Por defecto se instalan
paquetes de los componentes main y restricted. Los paquetes
del componente universe de Ubuntu generalmente se basan en
los paquetes de la rama inestable (Sid) y en el repositorio
experimental de Debian.
Conocida esta informacin se plantea la implementacin de un
sistema automatizado con el objetivo de intentar detectar de
forma continua la introduccin de funciones inseguras en
repositorios Linux. Esta tarea es compleja, por este motivo se
habilita un mecanismo de plugins para ir aadiendo diferentes
JNIC2015
anlisis. En los siguientes apartados se particularizar el uso de

esta plataforma en la deteccin de funciones inseguras y la
deteccin de software vulnerable presente en el repositorio del
sistema operativo Ubuntu.
III. PLATAFORMA PARA LA DETECCIN DE
FUNCIONES INSEGURAS EN REPOSITORIOS LINUX
El objetivo de este apartado es describir la plataforma

implementada, vase Figura 1, utilizada para la deteccin
automatizada de funciones inseguras en repositorios de
software libre (en general sera aplicable a otros repositorios
que permitan acceder a cdigo fuente). Anlisis posteriores nos
permitirn observar si esas funciones inseguras son explotables
o no.
En la Figura 1 se describe la plataforma genrica utilizada para

la deteccin automatizada de vulnerabilidades software. Desde
un punto de vista conceptual la plataforma se compone de 3
componentes principales:
Este componente facilita la tarea del investigador a la hora de

procesar y analizar las detecciones almacenadas en la base de
datos. Actualmente mediante diversos scripts se permite la
bsqueda de patrones que permitira, por ejemplo, obtener fuga
de informacin hardcodeada en el propio cdigo fuente (por
ejemplo, contraseas), bsqueda de patrones que desemboquen
en vulnerabilidades (getenv(), strcpy(),), obtencin de
funciones inseguras que utilizan parmetros de entrada no
validados, errores de gestin de memoria, etc.
En resumen, el proceso completo realizado es el siguiente:

1.
2.
Adquisicin de datos. Sistema de Crawling.
En el diseo de la plataforma se contempla la posibilidad de

adquirir datos de diversas fuentes y empaquetados o
formateados de diversas maneras. El componente de
adquisicin de datos dispone de diferentes mdulos de
configuracin que le indicarn la forma adecuada para adquirir
la informacin y cmo modelarla en funcin del procesamiento
y almacenamiento que se le quiera dar. Por ejemplo, es posible
el desempaquetado de paquetes software, extraccin de su
cdigo fuente o facilitar el anlisis de un lenguaje de
programacin particular.
-
Bsqueda de patrones e inteligencia
Como se puede ver la plataforma dispone de los elementos

esenciales para adaptarse a diferentes fuentes de datos y
analizar cdigo fuente en diversos lenguajes. De hecho, en
nuestra investigacin en curso, se particulariza el uso de la
plataforma en la deteccin de funciones inseguras en cdigo
fuente desarrollado en lenguaje de programacin C existente en
repositorios Linux, concretamente, en los repositorios oficiales
del sistema operativo Ubuntu. Para ello se configura la
plataforma para que realice la adquisicin de paquetes software
del repositorio de Ubuntu. Actualmente, se han procesado
45.153 paquetes. Estos paquetes son los que se pueden
descargar en una distribucin Ubuntu 14.10 por defecto. Este
nmero de paquetes puede ser aumentado incluyendo nuevos
repositorios en el fichero /etc/apt/sources.list
Figura 1. Plataforma para la deteccin de vulnerabilidades en repositorios

de software.
Actualmente la plataforma solo permite almacenar los

resultados en una base de datos PostgreSQL, almacenndose
informacin relativa a la vulnerabilidad detectada y el fichero
donde est presente ese cdigo fuente para facilitar bsquedas
avanzadas.
Deteccin de vulnerabilidades
3.
4.
5.
6.
Lectura de un paquete de software proveniente de la

fuente de datos.
Descarga del paquete de software que contiene el
cdigo fuente de la aplicacin.
Los paquetes de software vienen comprimidos en
formato tar.gz, llevndose a cabo su descompresin.
Anlisis del cdigo fuente en la bsqueda de funciones
inseguras.
Almacenamiento de las funciones inseguras y
parmetros encontrados en los diferentes ficheros
fuente de cada paquete. Se almacena informacin de
metadatos para facilitar su anlisis posterior.
Se procede a la eliminacin del paquete de software
descargado, as como de los ficheros descomprimidos
y analizados.
Una vez se tiene acceso al cdigo fuente solo es necesario

configurar el componente de deteccin de vulnerabilidades con
plugins adecuados que faciliten esta tarea. En nuestra
investigacin se centra el esfuerzo en la deteccin de funciones
inseguras. Posteriormente, mediante el componente de
Este componente es el elemento central de la plataforma

permitiendo detectar vulnerabilidades software de diferente
naturaleza en base a una serie de plugins configurados. Por
ejemplo, detectar la presencia de funciones inseguras que
podran desembocar en la deteccin de una vulnerabilidad.
94
JNIC2015
bsqueda de patrones e inteligencia se analizar la gravedad de

las detecciones.
En este punto, es importante, definir ms detalladamente que se
entiende por funciones inseguras y documentar cuales estamos
analizando. Entendemos por funcin insegura, en nuestro caso
en lenguaje de programacin C, aquella funcin que por defecto
no incluye mecanismos adicionales de chequeo de los
parmetros de entrada, por ejemplo, su tamao, de tal forma que
en funcin de estos la funcin podra ser utilizada para ejecutar
cdigo no autorizado o forzar un comportamiento anmalo.
Obviamente, no siempre una funcin insegura introducir una
vulnerabilidad, pero, como se ver posteriormente, es una
condicin necesaria y permite validar de forma sencilla
software que podra facilitar la ejecucin de exploits. En
cualquier caso dejara en evidencia que el software publicado
no se audita correctamente. De hecho, existen mltiples
funciones no recomendadas desde un punto de vista de la
seguridad en Linux (programacin en C). Actualmente, con los
plugins desarrollados, se detecta las siguientes casusticas:
- La funcin gets()
Esta funcin permite leer de la entrada estndar un flujo de
bytes y los almacenarlos en un array de bytes. El uso de esta
funcin puede producir un desbordamiento de buffer o buffer
overflow si dicho array es ms pequeo que la fuente de entrada.
- La funcin scanf()
Esta funcin permite leer la entrada estndar y clasificarla en
funcin de un formato especfico que es indicado por el usuario.
Si el usuario especifica %s, se leern los caracteres del flujo de
entrada en un buffer hasta que se llegue a un carcter no-ASCII.
Esta situacin puede provocar un desbordamiento de buffer.
IV. ANALIZANDO
FUNCIONES
INSEGURAS
DETECTADAS EN REPOSITORIOS UBUNTU
En este apartado se destacan los resultados obtenidos al
procesar y analizar una serie de funciones potencialmente
inseguras, no recomendadas, procesando 45.153 paquetes de
los repositorios configurados en Ubuntu 14.10 (otras funciones
estn en proceso de estudio).
-
Funcin strcpy.
12.830 paquetes software (28,41% del total del repositorio)

tienen presentes en alguno de los ficheros que conforman su
cdigo fuente alguna funcin strcpy. De hecho, estos 12.830
paquetes software tienen un total de 252.029 ficheros de cdigo
fuente que contienen al menos el uso de una funcin strcpy. En
realidad, el nmero total de funciones strcpy detectadas son
899.500. Lo que hace una media de 3,56 funciones strcpy por
paquete software.
-
Funcin sprintf.
12.523 paquetes software (27,73% del total del repositorio)

tienen presentes en alguno de los ficheros que conforman su
cdigo fuente alguna funcin sprintf. De hecho, estos 12.523
paquetes software tienen un total de 265.809 ficheros de cdigo
fuente que contienen al menos el uso de una funcin sprintf. En
realidad, el nmero total de funciones sprintf detectadas son
1.333.925. Lo que hace una media de 5,01 funciones sprintf por
paquete software. En funcin de cmo se utilice esta funcin
podra introducir un problema de seguridad. Por ejemplo, un
mal uso de esta funcin sera el siguiente:
char buffer[10];
sprintf(buffer, %s, longitud mayor que 10);
En este ejemplo de cdigo se producir un desbordamiento de
buffer al copiar una cadena (string origen) de mayor tamao a
un buffer destino de menor tamao. Dependiendo de dnde y
cmo se ejecute un ejemplo conceptualmente parecido a este se
podra o no ejecuta cdigo arbitrario.
- La funcin strcpy()
Esta funcin permite realizar una copia de un buffer a otro. Esta
situacin provoca que si el buffer de origen es mayor que el
buffer de destino se desemboque un desbordamiento del buffer
destino. La explotacin de este tipo de vulnerabilidades puede
provocar la ejecucin de cdigo arbitrario por parte de un
usuario malicioso.
- La funcin sprintf()
Esta funcin permite imprimir de manera formateada un buffer.
Si el buffer de destino es menor que el de origen se provocar
un desbordamiento de buffer.
En algunas situaciones el uso inapropiado de las funciones
anteriores puede provocar que otras funciones desemboquen en
situaciones de riesgo para el usuario dando lugar a otras
vulnerabilidades como puede ser la denominada Use After
Free.
95
Funcin scanf
1780 paquetes software (3,94% del total del repositorio) tienen

presentes en alguno de los ficheros que conforman su cdigo
fuente alguna funcin scanf. De hecho, estos 1.780 paquetes
software tienen un total de 5.737 ficheros de cdigo fuente que
contienen al menos el uso de una funcin scanf. En realidad, el
nmero total de funciones scanf detectadas son 24348. Lo que
hace una media de 5,01 funciones sprintf por paquete software.
En funcin de cmo se utilice esta funcin podra introducir un
problema de seguridad. Por ejemplo, un mal uso de esta funcin
sera el siguiente:
char buffer[10];
scanf(" Content-Type: %s ", buffer);
JNIC2015
La funcin scanf lee de la entrada estndar los caracteres

correspondientes al formato que se le especifica. En el cdigo
de ejemplo se puede visualizar como se declara un buffer de
tamao 10 octetos. Al utilizar la funcin scanf se leer de la
entrada estndar un flujo de bytes esperando una cadena, es
decir, una cadena que acabe con un byte \0. Si el flujo de bytes
es mayor de 10 octetos se provocar un buffer overflow, ya que
la funcin no controla el tamao de informacin que se recoge
de la entrada estndar. En funcin de dnde y cmo se ejecute
este ejemplo se podra o no ejecutar cdigo arbitrario.
-
Funcin gets
funciones strcpy que reciben como parmetro de entrada el

valor obtenido de getenv (contenido en 408 paquetes).
Por ejemplo, los siguientes paquetes tienen en su cdigo la
siguiente instruccin:
strcpy(disp_buf, getenv( "DISPLAY"))
Paquetes: cnee.txt, gnee.txt, libxnee-dbg.txt, libxnee-dev.txt,
libxnee0.txt, xnee.txt, xnee-doc.txt, etc.
Por ejemplo:
./xnee-3.19/libxnee/test/disp.c
38: strcpy(disp_buf, getenv("DISPLAY"));
945 paquetes software (2,09% del total del repositorio) tienen

presentes en alguno de los ficheros que conforman su cdigo
fuente alguna funcin gets. En funcin de cmo se utilice esta
funcin podra introducir un problema de seguridad. Por
ejemplo, un mal uso de esta funcin sera el siguiente:
En el caso de argv, un ejemplo podra ser:

strcpy(host, argv[1])
char s[8];
printf(Introduce tu nombre, por favor: );
gets(s);
En el caso de que la variable s reciba un tamao de octetos
superior al buffer que tiene reservado, en este ejemplo 8 octetos,
se producir un desbordamiento. En funcin de dnde y cmo
se ejecute este ejemplo se podra o no ejecutar cdigo arbitrario.
V. DETECTANDO APLICACIONES VULNERABLES
EN UBUNTU
En el apartado anterior se ha dejado de manifiesto que la
presencia de funciones no recomendadas es, por desgracia, ms
habitual de lo deseable. No obstante, que una funcin sea
potencialmente insegura no implica necesariamente que el
software que la contenga tenga una vulnerabilidad que pueda
ser explotada, quizs validaciones previas contrarrestan los
posibles inconvenientes de usar dicha funciones. Por este
motivo, en este apartado, dentro de esta investigacin en curso,
se va analizar si entre ese enorme nmero de funciones no
recomendables puede detectarse alguna que facilite la
explotacin. En nuestra investigacin, entendemos por
explotacin alguna vulnerabilidad que afecte al funcionamiento
habitual del programa, por ejemplo, denegacin de servicio, o
ejecucin de cdigo arbitrario.
En este artculo se centran los esfuerzos en la funcin no
recomendable strcpy, su uso es masivo con 899.500 llamadas,
y la posibilidad de detectar fallos tan tpicos como buffer
overflow. De hecho, existen algunas casusticas del uso de la
funcin strcpy que podra, si no existen validaciones
adicionales, establecer un vector de ataque para cualquier
usuario con conocimientos mnimos de explotacin de
vulnerabilidades. Por ejemplo, se pueden observar 13.880
funciones strcpy que reciben como parmetro argv[], es
decir se introduce el parmetro desde teclado a la funcin
strcpy, estas funciones se concentran en 2.923 paquetes, o 1347
96
encontrndose en paquetes del estilo a: apcupsd.txt, apcupsdcgi.txt, apcupsd-doc.txt, libpgpool-dev.txt, libpgpool0.txt,

libxpa-dev.txt, libxpa1.txt, pgpool2.txt, python-pyds9.txt, tclxpa.txt, xpa-tools.txt
Conocido esto se est recurriendo a diversos procedimientos y
tecnologas, proceso en definicin y en curso, para aadir
mayor grado de certeza de si los paquetes detectados introducen
o no funciones finalmente vulnerables, antes de proceder a un
anlisis manual ms exhaustivo.
En cualquier caso, en este punto se ve interesante documentar
algunos de los paquetes ya analizados y verificados
manualmente.
CASO 1: Chemtool. Aplicacin grfica
Una de las vulnerabilidades encontradas con la plataforma de
deteccin de funciones potencialmente inseguras es un Memory
Corruption en la aplicacin Chemtool 1.6.14. La aplicacin
permite realizar ecuaciones qumicas orgnicas de forma
grfica. La plataforma detect el uso de la funcin insegura
strcpy() y la concatenacin con el uso del paso de parmetros
argv[x] sin chequear dicho uso. Durante la etapa de
comprobacin de posible vulnerabilidad se instal la aplicacin
en una mquina de prueba con la versin de GNU/Linux
Ubuntu 14.10.
Esta vulnerabilidad denominada Memory Corruption permite a
un atacante crashear la aplicacin introduciendo una entrada
maliciosa. Este hecho puede provocar tras un anlisis
exhaustivo que un atacante podra ejecutar cdigo arbitrario
ante un desbordamiento de buffer. En este caso particular un
atacante solo puede explotar esta vulnerabilidad de forma local.
El anlisis realizado refleja dos vas de explotacin. La primera
de ellas introduciendo un valor grande como parmetro 1 de la
aplicacin, el cual provoca que la copia de este flujo de entrada
JNIC2015
a un buffer interno se desborde. De esta forma se consigue el

crasheo de la aplicacin por buffer overflow. Para
ejemplificar este hecho se indica la lnea a ejecutar $chemtool
$(perl -e 'print "A"x900'). Durante el anlisis exhaustivo se
descubri que se utilizaba la misma funcin para analizar el
contenido que se carga en un fichero desde la aplicacin, vase
Figura 2. Se prepar un pequeo cdigo que genera un archivo
malicioso con el objetivo de forzar un comportamiento anmalo
de la aplicacin y poder detectar en qu direccin de memoria
se provoca la prdida del flujo correcto de la aplicacin. La
prdida del flujo normal provoca que sta comience a ejecutar
otras posibles instrucciones. En este instante se ha detectado un
vector para cambiar el flujo para el que la aplicacin fue
desarrollada originalmente. En el caso de Chemtool se provoca
una denegacin de servicio a la aplicacin, ya que no se
controla el flujo por el atacante, sino que solamente se cambia
ste, pero sin control alguno, por lo que se provoca el crash
de la aplicacin. Si, por el contrario, el atacante consiguiese
controlar qu instrucciones se ejecutan despus de cambiar el
flujo nos encontraramos ante un escenario de ejecucin de
cdigo arbitrario. Esto indica que un atacante podra ejecutar
cdigo arbitrario a travs de dicha vulnerabilidad.
#/usr/bin/ruby
buf = "a"*3000
filename = "crash.png"
file = open(filename,'w')
file.write(buf)
file.close
puts "file created!"
Figura 2. Ejemplo de explotacin basada en fichero malicioso.
Tras realizar un responsable disclosure de la vulnerabilidad se

obtuvo
un
identificador
del
tipo
OSVDB
(http://osvdb.org/show/osvdb/118250) y otro identificador
EDB (https://www.exploit-db.com/exploits/36024/), estando
en trmite la asignacin de un CVE.
CASO 2: Mltiples aplicaciones facilitan ataques de buffer
overflow usando strcpy vulnerable.
Como se justific en apartados anteriores se estn detectando
mltiples aplicaciones donde se puede provocar ataques de
buffer overflow. Algunos ejemplos son:
-
flasm
bibcursed
dnsmasq -> dhcp_release
bwbasic
acedb-other-belvu
abcmidi-yaps
La generacin de un ataque de buffer overflow a todas estas

aplicaciones comparte gran similitud en el procedimiento,
pudiendo diferenciarse en pequeos detalles en funcin de los
parmetros que el analista pueda modificar. Por ejemplo, si se
selecciona el programa abcmidi-yaps (converts an abc file to a
PostScript file) una vez detectado que existe una funcin strcpy
que recibe parmetros de entrada de teclado sin validar es trivial
97
provocar un buffer overflow, en este caso insertando 900

octetos. La Figura 3. se demuestra cmo Ubuntu, si tiene
configurado polticas de prevencin con el uso de DEP, podra
mitigar malos hbitos de programacin.
Figura 3. Ataque de buffer overflow a un paquete y mitigacin por parte de

Ubuntu
VI. CONCLUSIONES
Esta investigacin presenta la plataforma diseada e
implementada para el anlisis del cdigo fuente de los paquetes
software presente en repositorios Linux. En este artculo se
analizan los detalles centrando el uso de la plataforma en los
repositorios configurados por defecto en Ubuntu 14.10, una de
las distribuciones de usuarios ms difundida.
Se demuestra la facilidad para detectar funciones
potencialmente inseguras, en el estado actual las funciones ms
sencillas y tpicas. De todas las funciones detectadas, por
cuestin de tiempo, se centran los esfuerzos en una de ellas,
strcpy, y se intenta analizar si son vulnerables centrndonos en
un tipo de explotacin concreta (la ms popular), los ataques
por buffer overflow.
Nuestra investigacin destaca que sin recurrir a procedimientos
de anlisis complejos es posible demostrar que hasta las
cuestiones ms sencillas de codificacin segura no son
analizadas mnimamente por la comunidad Ubuntu. Se
demuestra que existen actualmente aplicaciones que facilitan
introducir fallos de seguridad al sistema operativo por defecto
(los fallos de seguridad sern realmente explotados en funcin
de las contramedidas que se establezcan en cada sistema
operativo). El escenario ms bsico sera fallos de negacin de
servicio y el ms grave, si se puede aprovechar el buffer
overflow, ejecucin de cdigo.
Actualmente se est trabajando en analizar y probar, uno a uno,
los paquetes sospechosos, documentando y registrando (CVE,
OSVDB, etc.) los hallazgos mediante una poltica de
responsable disclosure que facilite a la comunidad Ubuntu
mejorar la calidad del software desarrollado. Del mismo modo
se est verificando si los fallos descubiertos se mantienen y
consumen, por reutilizacin de cdigo, en otros sistemas
operativos Unix/Linux. De momento, y en el caso particular del
sistema operativo Ubuntu, no se ha detectado ninguna
herramienta que permita ejecucin de cdigo arbitrario evitado
la configuracin por defecto de mitigacin de Ubuntu (DEP
Data Execution Prevention).
JNIC2015
REFERENCIAS
[1]
Bello, L. Debian Security Advisory. DSA-1571-1 openssl predictable

random number generator. https://www.debian.org/security/2008/dsa1571
[2]
Heartbleed bug. http://heartbleed.com/
[3]
Shellshock bug.
https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29
98
JNIC2015
Ingeniera inversa: mtodos utilizados y anlisis de

tcnicas para la proteccin de software
Alberto Garca Moro y Vctor A. Villagr Gonzlez
Universidad Politcnica de Madrid - Escuela Tcnica Superior de Ingenieros de Telecomunicacin
alberto.garcia.moro@alumnos.upm.es y villagra@dit.upm.es
Resumen- La ingeniera inversa ayuda a entender cmo
funciona un programa y cmo est diseado. Debido a esto,
es posible hacer uso de ella para desbloquear archivos que
estn protegidos, por ejemplo si necesitan una clave para
funcionar o para acceder a utilidades internas de pago. En
este documento se hace un breve resumen sobre cmo se
puede usar la ingeniera inversa para ello y as estudiar los
mtodos necesarios para impedir el acceso libre a estos
programas mediante herramientas como depuradores,
utilidades muy usadas para desproteger programas.
software.
Por otro lado, est el tipo de interfaz, encargado de conocer
la estructura y el comportamiento de las interfaces que forman
el sistema, sabiendo qu acciones bsicas realiza cada interfaz
manteniendo la lgica interna del programa.
Y por ltimo, destaca el tipo de ingeniera inversa de datos,
que se aplica sobre la parte de cdigo que contiene las bases de
datos para reconocer su estructura y cmo se organizan los
datos en el programa. El proceso de ingeniera inversa [2] se
puede ver en la Fig 2.
I. INTRODUCCIN
La ingeniera inversa [1] estudia un producto, terminado o
con cierto grado de completitud, con el fin de obtener detalles
acerca de su diseo y/o funcionamiento, al contrario que el
proceso clsico de ingeniera o ingeniera directa.
Por tanto, es un proceso que funciona hacia atrs, pudiendo
analizar software y productos electrnicos sobre todo, aunque
tambin se puede utilizar como herramienta de anlisis sobre
cualquier otro producto de ingeniera.
Hay que destacar que en el proceso de ingeniera inversa el
sistema o producto analizado no debe cambiar, sino que se
produce informacin acerca de su funcionalidad.
Fig 2. Desarrollo de ingeniera inversa del software
Fig 1. Diagrama de ingeniera inversa
La ingeniera inversa del software es la rama que se encarga

del estudio de los programas, obteniendo su cdigo fuente para
trabajar posteriormente con l. Hay varios tipos dependiendo
de la parte a estudiar del programa.
Por un lado est la ingeniera inversa del software de
proceso, quiz la ms importante de todas, ya que estudia la
lgica del programa, para comprender el funcionamiento del
Se debe destacar que, a pesar de que en este documento se

va a ver la ingeniera inversa como herramienta de desbloqueo
de programas (y despus de entender su uso, los mtodos para
poder proteger los archivos de su utilizacin), s que el uso de
la ingeniera inversa puede ser legal en Espaa bajo
condiciones de interoperabilidad entre software, si se necesitan
datos de un programa para hacerlo compatible con otro.
Como se ha dicho, muchos programas requieren una clave
de acceso para hacerlo funcionar o tener acceso al programa
completo. Para hacer esto, es necesario hacer uso de tcnicas y
herramientas de ingeniera inversa para descubrir la clave, que
normalmente va embebida en el cdigo para que al introducirla
se pueda comprobar. Aunque hay muchas tcnicas y formas de
desproteger un programa, este documento se centra en hacer
difcil conseguir esta clave de programa.
A continuacin se van a describir estas herramientas y
tcnicas y una serie de mtodos que pueden hacer que el
programa no se pueda analizar o sea mucho ms difcil de
hacer mediante las herramientas descritas para as protegerlos
frente a estos ataques.
99
JNIC2015
II. TCNICAS
A la hora de desbloquear un programa, se puede optar por
parchear el cdigo, de forma que no se haga la comprobacin
pertinente de la clave, o conseguir una clave vlida que se
verifique en el programa. En este captulo se van a ver estas
tcnicas [1], aunque hay muchas ms.
A. Parches
Una de las tcnicas ms utilizadas para superar la proteccin
de algunos programas es el uso de parches de cdigo. Su
principal objetivo es cambiar el cdigo del programa para
variar su flujo natural de ejecucin, con el fin de que ciertas
comprobaciones u operaciones no se lleven a cabo.
La manera de llevar a cabo un parche es el cambio de
instrucciones del cdigo original. La forma ms habitual de
hacerlo es utilizar un depurador como OllyDbg. Sin entrar en
mucho detalle, ya que se ver el depurador en el prximo
captulo, es un tipo de software que permite controlar la
ejecucin del programa objetivo, viendo las instrucciones que
se ejecutan y el estado de las principales variables.
Los cambios que se suelen llevar a cabo son modificaciones,
antes o despus de comparaciones o test que se hacen en el
programa original o variaciones de los tipos de saltos a
subrutinas (o insertando otros nuevos) que se dan en el cdigo.
Los mtodos frecuentes para saber en qu lugar aplicar estos
cambios es mediante la bsqueda de cadenas que puedan ser la
clave o la comprobacin de APIs que ofrecen las bibliotecas,
operaciones que suelen ser las encargadas de verificaciones.
Estos cambios que se hacen son permanentes y se mantendrn
siempre que se ejecute el programa.
Otra opcin para realizar cambios pasajeros en los
programas es mediante el uso de Loaders, programas que
cargan ejecutables en memoria para poder realizar cambios en
ejecucin, volviendo el programa al estado original al finalizar
la ejecucin.
B. Obtencin De Clave
Como se ha mencionado antes, en numerosas ocasiones los
programas que se adquieren en el mercado estn protegidos
con una clave de uso que hay que introducir al iniciar el
programa, ya sea al principio de su uso o despus de un
perodo de tiempo si este tiene una versin de prueba.
En algunas situaciones, esta solicitud de clave se puede
parchear. Por ejemplo, las versiones con un perodo de prueba
suelen utilizar ciertas APIs de chequeo del sistema como son
GetLocalTime o GetSystemTime, entre otras. Con ellas se
llevan a cabo las comprobaciones de cunto tiempo lleva el
usuario utilizando el programa y ver si se ha cumplido ya el
tiempo de prueba del mismo. Buscando en el cdigo estas
APIs, es posible cambiar el flujo para que no se haga la
comprobacin o para que se haga de forma incorrecta.
Sin embargo, esto no siempre es posible, es muy complicado
o simplemente se quiere obtener la clave o serial para no tener
que parchear el programa, que en el futuro puede tener algn
problema. Por todo ello, en muchas ocasiones se estudia el
cdigo del programa mediante un depurador como OllyDbg
para hallar la clave o serial. Esto es un nmero o texto (una
cadena) que es idntico para todos los usuarios y que
normalmente tiene que ir embebido en el propio cdigo.
Para encontrarlo, lo normal es buscar en el cdigo las
cadenas con patrones que pueden ser una clave del producto. Si
hay muchas cadenas (algo que ocurre con bastante asiduidad)
lo que se hace es ir avanzando en el programa con el depurador
para ver qu cadena es la que finalmente se compara al valor
que introduce el usuario y qu operaciones se hacen sobre ella.
C. Elaboracin De Generador De Claves
En la seccin anterior, el programa tena una nica clave,
igual para todos los usuarios. En este caso, el problema es que
la clave para cada uno de los usuarios es distinta o hay multitud
de claves vlidas, existiendo un algoritmo de claves que se
encarga de verificarlas en el programa. Por lo tanto, es posible
crear un generador de claves o keygen mediante un algoritmo
que fabrique claves correctas.
Para conseguir crear este algoritmo que pueda generar claves
vlidas hay que realizar un estudio de ingeniera inversa puro,
para ver cmo se va comprobando y testando el nmero o
cadena de texto de registro introducido en el programa. Hay
una gran variedad de algoritmos utilizados para generar claves,
cuya complejidad es diferente en cada caso, dependiendo del
nmero de operaciones.
Los algoritmos que se aplican pueden ser totalmente
independientes del usuario, como por ejemplo utilizar nmeros
que sean mltiplos de otro o que mantengan cualquier otro tipo
de relacin entre ellos, mientras que hay otros algoritmos que
utilizan algn dato especfico de cada usuario como parte del
clculo del nmero o cadena de registro, como puede ser el
nombre de este usuario o algn dato nico, como el nmero de
identificacin.
III. HERRAMIENTAS
Para llevar a cabo las tcnicas anteriores, en todas se tiene
algo en comn: es necesario conocer el cdigo del programa
porque hay que estudiarlo.
Sin embargo, los programas que se intentan desproteger son
programas de los que solo se tiene un ejecutable compilado y
listo para funcionar, por lo que no se tiene acceso al cdigo de
forma directa.
Debido a ello, entran en juego las herramientas de ingeniera
inversa [3], que ayudan a obtener y estudiar el cdigo de estos
ejecutables compilados.
Hay diferentes herramientas que se pueden utilizar en el
campo de la ingeniera inversa, algunas muy especficas, como
las herramientas CASE [4] o herramientas de insercin de
fallos, y otras ms generales, como los desensambladores.
Para el caso de obtencin de claves para desbloquear
programas, hay dos herramientas que marcan la diferencia
respecto a las dems y que son las ms usadas para este tema:
el desensamblador y el depurador. A continuacin se van a
estudiar estas dos herramientas fundamentales.
A. Desensamblador
Como su propio nombre indica, los desensambladores son
herramientas destinadas a convertir cdigo mquina en
lenguaje ensamblador, un lenguaje legible para analizar, y as
revelar las instrucciones que son usadas en el cdigo del
programa. Este cdigo mquina es especfico para cada
arquitectura de hardware.
Cualquier desensamblador debe hacer ciertas suposiciones a
fin de presentar el cdigo que se intenta desensamblar de
100
JNIC2015
manera clara. Estas suposiciones que se hacen pueden variar el

cdigo obtenido, ya que no es algo trivial el orden de
desensamblado.
Hay principalmente dos tipos de algoritmos para hacer un
desensamblador: linear (lineal) y flow-oriented (orientado a
flujo). El algoritmo lineal es ms fcil de implementar, pero
tambin es ms propenso a errores.
La principal diferencia entre los algoritmos anteriores es que
mientras que el mtodo lineal analiza cdigo de manera
secuencial en la memoria sin importar de que tipo sean las
instrucciones, el algoritmo orientado a flujo estudia el tipo de
cada instruccin para hacer supuestos y examinar mejor el
cdigo.
Esta diferencia puede entenderse mejor con los saltos
condicionales. Cuando el algoritmo lineal se encuentra con una
instruccin que es un salto condicional, este algoritmo suele
analizar la rama falso, de forma que hara como si el salto no se
fuese a cumplir, y seguir desensamblando linealmente.
Sin embargo, el algoritmo orientado a flujo se comportara
de otra forma. Al llegar al salto condicional, tambin se
seguira la rama falso. Sin embargo, antes de saltar a otra
subrutina por encontrar un salto incondicional, por ejemplo, se
volvera a la instruccin anterior del salto condicional para
desensamblar la otra rama. Por tanto, este algoritmo es mucho
ms completo.
B. Depurador
Los depuradores son herramientas que se utilizan para
controlar la ejecucin de otros programas. Permiten avanzar
paso a paso por el cdigo, rastrear fallos, establecer puntos de
control y observar las variables y el estado de la memoria en un
momento dado del programa que se est analizando
(depurando). Son muy valiosos a la hora de determinar el flujo
de procesamiento del programa.
Los depuradores avanzados suelen incorporar de serie un
desensamblador, opciones de reensamblado o edicin
hexadecimal, dado que el software a analizar, como se ha dicho
anteriormente, es ya un programa compilado (normalmente) y,
por tanto, no se tiene acceso al cdigo fuente. Los depuradores
permiten, de forma general:
- Ejecutar instruccin a instruccin un programa.

- Detener la ejecucin temporalmente en una instruccin
concreta o bajo determinadas condiciones de ejecucin.
- Visualizar el contenido de las variables en un determinado

momento de la ejecucin.
- Cambiar el valor del entorno de ejecucin para poder ver

el efecto de una correccin en el programa.
- Cambiar el orden de ejecucin de un programa.

Generalmente, cuando se est analizando un programa, la
preocupacin o el objetivo principal es saber qu hace, por lo
que, en condiciones normales, no es necesario conocer el
propsito de cada una de las llamadas dentro del programa a
analizar. Esto sucede, por ejemplo, cuando dentro de un
programa se carga una librera y no se quiere conocer cada uno
de sus detalles, lo que ahorra una gran cantidad de tiempo a la
hora de realizar el anlisis.
Para llevar a cabo este ahorro de instrucciones hay que
diferenciar entre las opciones de step-over o step-into para
avanzar por las instrucciones del programa. Cuando se hace

step-over, lo que en realidad se est haciendo es un bypass.
Para entenderlo mejor, si se lleva a cabo un step-over sobre una
funcin, la siguiente instruccin que se ver en el depurador es
la posterior al return de la funcin referida anteriormente.
En cambio, si se hace un step-into sobre esa funcin, hara
que se analizaran todas sus instrucciones, por lo que la
instruccin que aparecer en el depurador despus de la
llamada a la funcin ser la primera instruccin de esta.
Para llevar a cabo el anlisis, el usuario del depurador activa
puntos de parada o breakpoints en el programa ejecutado. Un
breakpoint es una instruccin que permite al depurador parar la
ejecucin del programa cuando cierta condicin se cumpla. Por
ejemplo, cuando un programa accede a cierta variable, o llama
a cierta funcin, el depurador puede parar la ejecucin en ese
momento. Estos puntos de parada se pueden realizar de distinta
manera y se detalla en los siguientes prrafos
Por defecto, los depuradores ms usados utilizan breakpoints
basados en software, que son implementados introduciendo
una INT 3 (se ver con ms detalle en siguientes secciones)
modificando el primer byte de esa instruccin. Se pueden
aadir de manera ilimitada, ya que el gasto de memoria para
guardar los cambios es mnimo.
Por otro lado, tambin se pueden implementar puntos de
parada llevados a cabo por hardware, en los que se compara,
cada vez que se ejecuta una instruccin, si el puntero de la
instruccin es igual que la direccin del breakpoint. Una
ventaja que tiene sobre los breakpoints por software es que se
pueden hacer respecto a una determinada direccin de
memoria, sin importar lo que se haga en ese lugar de la
memoria ni el cdigo que se est ejecutando. Sin embargo,
tienen una clara desventaja respecto a los anteriores: solo se
puede disponer de un nmero limitado de breakpoints hechos
por hardware.
Por ltimo, otro tipo de breakpoints utilizados son los puntos
de parada condicionales, que solo se producen si se dan ciertas
condiciones. Son breakpoints implementados por software, por
lo que el depurador, cuando llega al punto de parada, examina
las condiciones y si no se cumplen, sigue con la ejecucin
normal.
El uso de breakpoints lleva consigo un retardo considerable
respecto a la instruccin original, con lo que no es
recomendable utilizar breakpoints en una instruccin o funcin
que es llamada con mucha frecuencia. Estos cambios y paradas
hechos sobre la ejecucin de un determinado programa sirven
para comprobar su ejecucin, pero a su vez, el uso de un
depurador puede afectar al modo de ejecucin. De hecho, el
software a menudo se ejecuta de manera distinta en un
depurador, debido a los cambios que este realiza sobre la
temporizacin, lo que hace difcil en ocasiones seguir algunos
errores.
Por otro lado, la funcionalidad que tiene un depurador se
puede utilizar como herramienta de cracking para evitar la
proteccin anticopia, gestin de derechos digitales y otro tipo
de protecciones que tiene el software, lo que le hace ser una de
las herramientas ms usadas para ingeniera inversa.
Como se ha explicado antes, ciertos programas requieren
una clave de entrada que se introduce al arrancar el ejecutable.
Sin poseer esa clave, no se puede acceder a las utilidades del
programa, ya sea total o parcialmente. Una tcnica para
101
JNIC2015
averiguarla es utilizar ingeniera inversa para analizar el inicio

del ejecutable, en el momento en el que se introduce la clave
para su posterior verificacin.
Un depurador, como por ejemplo OllyDbg, ofrece un
desensamblado del cdigo y una vista de los principales
registros durante la ejecucin, que ayuda a consultar el estado
del programa. Para obtener la clave hay que analizar el
ejecutable mediante depurador. Dependiendo de la forma en
que est hecho, ser ms fcil o difcil, o habr que mirar unas
secciones de cdigo u otras.
Lo primero que hay que hacer es ejecutar el programa para
ver cmo funciona. En principio, la estructura bsica de estos
programas es sacar algn tipo de pantalla de bienvenida que te
solicita, directa o indirectamente, la clave del programa. Tras
insertarla, normalmente saldr un mensaje de verificacin o
bienvenida al programa o de negacin de uso, en el caso de que
sea incorrecta.
Por tanto, la estrategia bsica es ejecutar el programa con
puntos de parada en los momentos clave, como son la insercin
de la clave y la verificacin. Para ello se insertan breakpoints
en la funcin que recoge la clave insertada y la funcin que
saca el mensaje final por pantalla. Los depuradores, y en este
caso concreto OllyDbg [5], posee una utilidad que permite ver
qu funciones se estn usando en el programa y aadir un
punto de parada en cada una de las veces que esa funcin es
utilizada en el cdigo.
Una vez aadidos los breakpoints se procede a ejecutar el
programa bajo el depurador. Esto har que se tenga que
introducir una clave de programa a modo de prueba para que el
programa siga la ejecucin. Esta clave de prueba puede ser una
gran ayuda a la hora de estudiar el programa, ya que se puede
seguir lo que se hace con ella en la ejecucin, como
comparaciones u otras operaciones, y as averiguar la clave.
IV. MTODOS ANTI-REVERSING
Los procesos de ingeniera inversa pueden llegar a ofrecer
muchos detalles sobre un programa. Si el anlisis se hace de
una forma correcta y el software objeto de estudio no tiene
cierta proteccin, la obtencin de informacin est garantizada,
como se ha visto para obtener una clave de programa.
Para que esto no suceda con tanta facilidad, existen los
llamados mtodos anti-reversing [6], [7] y [8]. El reversing es
la obtencin de cdigo de un programa, y por tanto, estos
mtodos, como su propio nombre indica, son procedimientos a
la hora de construir el cdigo que hacen que sea ms difcil
conseguir el cdigo fuente de un programa.
Es decir, aadir obstculos a la hora de obtener el cdigo
mediante el uso de las herramientas anteriormente descritas. A
continuacin se vern distintos tipos de mtodos anti-reversing
para las herramientas anteriormente descritas.
A. Anti-Desensamblado
El anti-desensamblado se basa en utilizar cdigo o
estructuras de datos diseadas en un programa para hacer que
los desensambladores funcionen de manera incorrecta.
De esta forma, el cdigo se descompone en instrucciones
incorrectas o en desorden. Esta tcnica se puede llevar a cabo
con herramientas en el momento de construccin del software
o bien directamente sobre el cdigo de forma manual. Adems,
el desensamblado no es algo simple. Una secuencia de
instrucciones puede tener diferentes representaciones al

desensamblar, algunas de ellas invlidas, que hacen que el
trabajo sea mucho ms difcil.
Por tanto, las tcnicas de anti-desensamblado buscan
aprovechar eso, crear secuencias de cdigo que pueden
engaar al desensamblador.
La mayora de los desensambladores tienen problemas
cuando tienen que hacer ciertas suposiciones en bifurcaciones,
como con saltos condicionales. Precisamente esto es lo que se
puede aprovechar para hacer la tarea ms difcil al
desensamblador.
Una posibilidad es poner dos instrucciones de salto
condicionales seguidas con el mismo objetivo. Si se ponen dos
instrucciones de salto seguidas con el mismo objetivo y se
selecciona de manera oportuna el tipo de saltos, se puede
confundir al desensamblador. Por ejemplo, si se utiliza el salto
condicional jz (que salta si es igual o si es cero), seguido de un
jnz (que salta si no es igual o si no es cero), ambos con el
mismo destino, lo que en realidad se est realizando es un salto
incondicional. Sin embargo, el desensamblador no es capaz de
interpretar esto como un salto incondicional, ya que no puede
interpretar ms de una instruccin a la vez. Esto implica que en
el proceso de desensamblado se analizarn las dos
instrucciones por separado y, como se ha visto anteriormente,
se analiza primero (normalmente) la rama falso de los saltos
condicionales. Por tanto, se analizar el cdigo pasando por los
dos saltos condicionales en la condicin de falso, cuando en la
ejecucin del cdigo es imposible, ya que las dos instrucciones
juntas son iguales a un salto incondicional.
Otra posibilidad es utilizar un salto condicional con una
condicin interpuesta anteriormente que siempre se cumpla.
Sigue el mismo principio anterior, ya que en realidad la
construccin es un salto incondicional tambin, pero el
desensamblador no es capaz de interpretarlo as, por lo que se
analizar la rama falso.
Hay muchas ms tcnicas y construcciones especiales para
realizar anti-desensamblado. Por ejemplo, los manejadores de
excepciones tambin suelen suponer algunas dificultades a los
desensambladores, ya que no saben interpretarlos.
B. Anti-Depurado
El anti-depurado es una de las tcnicas ms usadas a la hora
de impedir los procesos de ingeniera inversa. Se basan
principalmente en hacer que el software sepa que est
ejecutndose bajo un depurador.
Desde el momento en que eso ocurre, el programa puede
variar su flujo natural de ejecucin y as esconder parte de su
funcionalidad, provocar errores o hacer creer que el programa
funciona correctamente cuando en realidad se est ejecutando
de otra manera, que hace el proceso de ingeniera inversa ms
tedioso.
Hay dos maneras principales de efectuarlas: detectar que el
depurador est funcionando, y as cambiar el modo de
funcionamiento, o el estudio del comportamiento de un
programa en el depurador. A continuacin se expondrn
algunos de los mtodos ms utilizados en la prctica.
Hay APIs que incluyen funciones que pueden ser usadas por
un programa para determinar si est corriendo bajo un
depurador o no. Estas funciones, como IsDebuggerPresent o
CheckRemoteDebuggerPresent (entre otras) permiten consultar
102
JNIC2015
la informacin de la cabecera de los procesos del programa

para saber si la ejecucin se est llevando a cabo bajo un
depurador. Cabe destacar que estas comprobaciones tambin se
pueden efectuar manualmente sin hacer uso de las funciones
anteriores.
Por otro lado, en cuanto a estudiar el comportamiento del
programa dentro del depurador, hay varias opciones. Una de
ellas es la bsqueda de interrupciones en el cdigo. La INT 3
es la interrupcin de software ms usada en los depuradores
para reemplazar, de manera temporal, una instruccin del
programa en ejecucin. Es la forma bsica de crear un
breakpoint. El cdigo de operacin de la INT 3 es 0xCC, de
manera que al crear un breakpoint en el depurador, en el cdigo
se inserta 0xCC. De esta manera, si un programa quiere evitar
estas interrupciones, no tiene ms que buscar ese cdigo
durante la ejecucin y si lo encuentra, desviar el flujo de
control del programa hacia un cdigo incorrecto para no poder
usar de forma adecuada el depurador.
Otra tcnica es realizar checksums en el cdigo. Parecido al
mtodo anterior, solo que en vez de realizar una bsqueda de
cdigos de la interrupcin INT 3, se hace una comprobacin
con CRC (cyclic redundancy check) o MD5 checksum. Es un
mtodo menos utilizado que el anterior, pero es igual de
efectivo, ya que se basan los dos en el mismo principio.
La comprobacin de tiempos es otro mtodo muy utilizado
tambin. Basado en que la ejecucin de un programa, en
presencia de un depurador, es siempre ms lenta, por ejemplo
cuando se ejecuta instruccin a instruccin. Hay dos opciones
(frecuentes) a la hora de realizar esta comprobacin: realizar
un timestamp cuando se lleven a cabo un par de operaciones y
luego tomar otro valor y compararlos para ver si hay lag o
tomar un timestamp antes de la lanzar una excepcin y otro
despus. Si el programa no est siendo depurado, la excepcin
ser manejada de forma rpida y viceversa.
Por ltimo, se puede interferir en el depurador haciendo que
se ejecute cdigo antes del punto de entrada que aparece en el
depurador o aprovechando posibles vulnerabilidades del
depurador que lo hagan funcionar de manera incorrecta.
C. Cdigo Ofuscado
Las tcnicas anti-reversing vistas anteriormente son buenas
para retrasar al analista que est tratando de hacer ingeniera
inversa para obtener el cdigo. Sin embargo, esta tcnica no
har mas difcil la obtencin del cdigo, sino que lo que har
ser hacer el cdigo menos comprensible para el analista.
La ofuscacin de cdigo se basa en complicar el cdigo con
el fin de que no se entienda bien. Se aaden variables y
operaciones que no se utilizan en nuestro cdigo inicial y que
hace que el analista obtenga mucha informacin, pero poco
relevante acerca de nuestro cdigo. Esta complejidad que se
aade al cdigo se puede medir y se denomina potencia de
ofuscacin.
Ms all de la complejidad adicional introducida, la
ofuscacin producida debe ser (o debe intentar ser) una
transformacin que no se pueda deshacer fcilmente, ya que es
posible crear desofuscadores.
Un desofuscador es un programa que implementa varios
flujos de datos y algoritmos de anlisis en un programa
ofuscado que, a veces, le permiten separar la informacin
importante de la prescindible y automticamente eliminar todas
las instrucciones irrelevantes y restaurar la estructura del

cdigo original.
Adems, una ofuscacin de cdigo suele tener un coste que
va asociado a la transformacin. Este coste puede ser tener un
cdigo ms grande que el original, tiempos de ejecucin ms
altos o el aumento de consumo de memoria durante el tiempo
de ejecucin.
La mayora de estas transformaciones se pueden hacer
automticamente mediante la ejecucin de un ofuscador para
un programa ya terminado y compilado. Sin embargo, muchas
de estas transformaciones se pueden aplicar manualmente.
La ofuscacin automtica es, obviamente, mucho ms
eficaz, ya que permite introducir confusiones en el programa
entero y no solo en pequeas partes de l. Adems, la
ofuscacin automtica se realiza normalmente despus de que
el programa sea compilado, lo que significa que el cdigo
fuente original no se hace menos legible, mientras que si se
hace manualmente el cdigo original ser menos comprensible.
Unos de los ofuscadores ms utilizados son aquellos que
transforman el cdigo en ByteCode de lenguajes como Java,
dado que llevar a cabo la descompilacin de sus ejecutables es
sencilla.
V. EJEMPLO DE CDIGO OFUSCADO
Una opcin bastante til es usar la ofuscacin con lenguajes
cuyo cdigo se puede sacar a travs de descompiladores. Un
descompilador es una herramienta que devuelve el cdigo del
ejecutable en lenguaje de alto nivel, como por ejemplo Java,
pero que necesita que se incluyan muchos metadatos en el
cdigo para poder llevar a cabo la descompilacin.
En el caso de Java, al correr sobre mquina virtual (JVM,
Java Virtual Machine), utiliza un lenguaje intermedio que
incluye mucha informacin que un descompilador puede usar
para obtener el cdigo del ejecutable. Hay ms lenguajes a
parte de Java que tienen estas caractersticas.
Esto hace que, por ejemplo, sacar el cdigo en claro de un
ejecutable .jar sea muy sencillo, ya que con el simple uso de un
descompilador se tiene acceso a l.
Es por eso que, en este caso, el uso de la ofuscacin sera
una gran idea para impedir llevar a cabo un estudio del cdigo
mediante ingeniera inversa, ya que el cdigo siempre se va a
poder obtener. Pero si sobre ese cdigo se pasa un ofuscador,
de manera que cambie los valores de las variables, mtodos,
etc., a la vez que se aaden ms variables, se aade dificultad.
De esta forma, despus de ofuscar un ejecutable .jar, si se
descompila de nuevo para comparar el cdigo obtenido
despus de la ofuscacin con el de antes de la ofuscacin. el
resultado es distinto. Ahora el cdigo que se obtiene, si bien es
el mismo en la forma, no es igual en el contenido, ya que los
nombres de variables y dems han sido cambiados de forma
aleatoria, por ejemplo.
Es decir, cuando se ofusca un cdigo, este se obtiene, pero
solo se tiene la informacin de sus operaciones, no de los
nombres de los elementos que tiene el programa, lo que hace
mucho ms difcil la obtencin de informacin.
Un ejemplo de esto se puede encontrar en [9], donde se
desarrolla un caso prctico en el que se ofusca un archivo .jar
y, posteriormente, se descompila el ejecutable (que mantiene su
funcionalidad despus de la ofuscacin) para ver el resultado,
103
JNIC2015
que se recoge en la Fig. 3.
Por tanto, si se quiere dificultar o imposibilitar que se pueda

obtener la clave (o cualquier otro mtodo de burlar la seguridad
de un programa) mediante ingeniera inversa, aparte de mejorar
el algoritmo de claves, se pueden aadir mtodos antireversing que dificulten el uso de las herramienta de ingeniera
inversa, sobre todo del depurador.
Por supuesto, el tiempo que se tarda en obtener el cdigo es
proporcional al tiempo que se tarda en protegerlo. Si se toman
pocas (o ninguna) medidas anti-reversing, el cdigo fuente se
obtendr de manera lo suficientemente limpia para poder
trabajar con l y obtener la clave.
Por otro lado, si se usan muchas de las tcnicas antireversing analizadas, de manera conjunta, se puede lograr que
cueste mucho esfuerzo y tiempo conseguir un cdigo para
poder analizarlo.
En definitiva, cuantos mas mtodos anti-reversing se usen a
la hora de construir el programa, ms seguro se estar frente a
cualquier ataque que quiera desproteger el programa.
REFERENCIAS
Figura 3. Ejemplo de ofuscacin
[1]
Como se puede observar, los nombres de las clases han

cambiado por letras de manera aleatoria, y adems los nombres
de variables, mtodos, etc. tambin estn cambiados dentro de
cada clase, por lo que la informacin obtenida ha sido reducida
de forma destacada.
Al cambiar solo nombres de variables, mtodos, etc, no
conlleva un coste de ejecucin superior, ya que las operaciones
son las mismas en ambos casos y, por tanto, la ejecucin es la
misma.
A su vez, si se hubieran introducido operaciones adicionales
para dificultar la comprensin del programa, s que habra un
coste de ejecucin aadido, ya que el programa tendra ms
instrucciones.
VI. CONCLUSIONES
El uso de claves en los programas para permitir su uso es
una prctica extendida. Los desarrolladores ponen una clave
que los usuarios tienen que adquirir por algn tipo de proceso
comercial que hace que se puedan sufragar los gastos que
conlleva el desarrollo del software. Por otro lado, tambin hay
muchas otras tcnicas para proteger los programas, como el
cifrado y descifrado del cdigo.
En este documento se han visto una serie de tcnicas y
herramientas que se pueden usar para salvar la clave de los
programas y tener acceso a su uso, a la vez que otra serie de
formas de desprotegerlos. La herramienta ms til en este
aspecto es, sin duda, el depurador. Un depurador permite
analizar y estudiar un programa en ejecucin, sin tener que leer
todo el cdigo que se puede obtener, por ejemplo, en un
desensamblador.
Adems, permite parar la ejecucin del programa y estudiar
los momentos ms importantes del programa, como la
insercin de la clave, de una manera sencilla. De esta forma, la
obtencin de la clave o del algoritmo generador de claves es
posible. Su obtencin depender de las operaciones y
comparaciones que se lleven a cabo con la clave introducida, lo
que puede complicar su consecucin, o si la clave est en claro
dentro del cdigo, lo que facilita su obtencin.
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
104
Ricardo Rodrguez, Introduccin a la ingeniera inversa,

Universidad de Zaragoza, 2011. webdiis.unizar.es/~ftricas/
Asignaturas/seguridadD/Transparencias/RicardoRodriguez.pdf
Ingeniera inversa. http://www.programacion.com.py/varios/
ingenieria-inversa
Slideshare, Ingeniera inversa y reingeniera de software.
http://es.slideshare.net/moimedinaq/ingeniera-inversa-yreingeniera-de-software
Herramientas CASE. http://www.monografias.com/trabajos14/
herramicase/herramicase.shtml
OllyDbg. http://www.ollydbg.de/
Michael Sikorski y Andrew Honig. Practical Malware Analysis:
The Hands-On Guide to Dissecting Malicious Software. Edicin
2012, editorial No Starch Press.
Eldad Eilam. Reversing: Secrets of Reverse Engineering.
Edicin 2015, editorial John Wiley & Sons.
Dennis Yurichev. Reverse Engineering for Begginers. Edicin
2015, licencia Creative Commons.
Alberto Garca Moro. Trabajo Fin de Grado Anlisis de tcnicas
de ingeniera inversa del software, Universidad Politcnica de
Madrid, 2015.
JNIC2015
Prototipado rapido de un analizador de malware

para Android empleando Razonamiento Basado en
Casos
Francisco J. Ribadas-Pena, Manuel Banobre-Gomez
Departamento de Informatica, Universidade de Vigo
Edificio Politecnico, Campus As Lagoas, S/N. 32004 Ourense
ribadas@uvigo.es, mbgomez2@esei.uvigo.es
ResumenSe presenta un trabajo en curso para el desarrollo

de un prototipo de marco generico para el analisis y deteccion de
aplicaciones maliciosas (malware) sobre la plataforma Android.
La aproximacion seguida emplea un esquema de razonamiento
basado en casos (CBR, Case Based Reasoning) adaptativo, que
enriquece la representacion de las muestras analizadas mediante
el uso de modo iterativo de diversos extractores de caractersticas. El esquema CBR implementado hace uso de herramientas
habituales en el campo de la Recuperacion de Informacion para
hacer posible el soporte de grandes colecciones de muestras.
I. I NTRODUCCI ON
El analisis y deteccion de software malicioso (malware) es
un a rea de investigacion muy activa, especialmente en el caso
de la plataforma Android, donde, debido a la abundancia de
dispositivos y aplicaciones disponibles, existe un gran numero
de aproximaciones y tecnicas descritas en la bibliografa.
De un modo general se diferencian dos grandes aproximaciones a la hora de enfrentar el problema del analisis de
malware [5]. En primer lugar estan las tecnicas basadas en el
analisis estatico de determinadas caractersticas de la propia
aplicacion bajo estudio, bien en forma de codigo ejecutable o
de su codigo fuente original. En el otro gran grupo estan las
tecnicas de analisis dinamico, o basado en el comportamiento,
que extraen informacion mediante la monitorizacion de la
aplicacion y su contexto, durante su ejecucion en un entorno
controlado. Por otra parte, en cuanto a la deteccion de malware
propiamente dicha, tambien hay dos grandes familias de
metodos. Los metodos basados en firmas emplean una base de
datos con muestras especficas de malware conocido a modo
de firmas identificativa. Los metodos heursticos o basados
en anomalas, emplean un modelo, normalmente construido
mediante tecnicas estadstica y/o de aprendizaje automatico,
capaz de definir y diferenciar el comportamiento benigno y
aislarlo del malicioso.
La propuesta de marco de analisis y deteccion de malware
en la que estamos trabajando puede englobarse en este segundo
tipo, aunque presenta ciertas caractersticas que la aproximan
a los metodos basados en firmas. Nuestro sistema emplea un
esquema de razonamiento y aprendizaje basado en la analoga,
denominado Razonamiento Basado en Casos [6]. Sobre esta
base conformamos un marco donde se pueden integrar de
forma conveniente diversas tecnicas de analisis, tanto estaticas
como dinamicas, que usa este esquema de razonamiento por
analoga de un modo adaptativo. Ante una aplicacion a analizar

se decide, en base a las experiencias previas, cual es el analisis
mas convenientes para ser aplicado sobre ella. Una vez incorporada esta nueva informacion, se repite el proceso para tomar
una nueva decision sobre la muestra, bien para identificarla
como maligna, benigna o indeterminada, o bien para decidir
aplicar un nuevo analisis que anada informacion adicional
que enriquezca la representacion de la muestra analizada.
La intuicion detras de este esquema es que sera el propio
sistema quien, en base a su experiencia anterior, decida como
ir analizando las muestras estudiadas y que nueva informacion
debe incorporar a la representacion de la misma para facilitar
su categorizacion final. Esta intuicion se corresponde tambien
con la idea de que es conveniente afrontar la tarea de deteccion
de malware desde distintas dimensiones, manejando diferentes
fuentes de informacion y evidencias.
En la seccion II esbozamos los fundamentos del metodo
de deteccion de malware desarrollado, para, a continuacion
presentar en la seccion III la arquitectura general y los
componentes que conforman nuestra propuesta. Por u ltimo,
en la seccion IV detallamos los experimentos de validacion y
evaluacion de la herramienta y las lneas de trabajo futuras.
II.
F UNDAMENTOS DE S ISTEMA DE A N ALISIS

D ESARROLLADO
Los fundamentos de nuestro prototipo de analizador de

malware se asientan sobre dos campos de investigacion bien
conocidos y estudiados: el Razonamiento Basado en Casos y
los sistemas de Recuperacion de Informacion.
II-A.
Razonamiento basado en casos
El Razonamiento Basado en Casos (Case Based Reasoning,

CBR) es un paradigma para la construccion de sistemas
inteligentes basados en el conocimiento. Emplea la analoga
como principio basico para dar soporte al razonamiento y al
aprendizaje o incorporacion de nuevo conocimiento. De un
modo general, los sistemas CBR manejan el concepto de Caso,
una representacion del problema que se pretende resolver, que
incluye una representacion de la solucion correcta a dicho
problema. Normalmente se trata de la solucion propuesta por
el sistema, junto con una indicacion de si e sta se considero
exitosa o no por parte de un supervisor externo. El nucleo
105
JNIC2015
de los sistemas CBR es la Base de Casos, una coleccion de

Casos etiquetados, normalmente estructurada e indexada, que
aglutina todo el conocimiento que el sistema posee sobre un
dominio de aplicacion concreto.
Sobre esa Base de Casos, la operacion de los sistemas CBR
para procesar un nuevo Caso a Resolver se organiza en cuatro
etapas:
Recuperar. Donde se consulta la Base de Casos para
obtener la lista de Casos Similares mas parecidos al Caso
que se presente resolver, de acuerdo a una metrica de
similaridad entre casos especfica de cada dominio.
Reutilizar. Donde se explota la informacion presente en
los Casos Similares (previamente resueltos) para proponer una solucion para el Caso a Resolver. Habitualmente
esta solucion combinara la experiencia codificada en las
soluciones dadas a los Casos Similares. En los esquemas
mas simples se trata de una simple votacion, de modo
similar al funcionamiento de los metodos de aprendizaje
basados en proximidad (k nearest neighbours), pero es
posible emplear modelos mas complejos y potentes.
Revisar. Se evalua la bondad de la solucion propuesta
para el Caso a Resolver, normalmente con la intervencion
de informacion experta externa, bien un usuario real u
otro tipo de supervision precodificada. Tambien se anota
si la solucion propuesta fue adecuada o no, corrigiendola
si es necesario.
Retener. Una vez completado el ciclo de un Caso a
Resolver, se decide si es relevante incorporarlo a la Base
de Casos para que la experiencia encapsulada en este caso
concreto pueda tomar parte en la resolucion de futuros
Casos similares.
En nuestra propuesta, empleamos un ciclo CBR ligeramente
distinto. Las muestras de aplicaciones Android analizadas
pasan a traves de este ciclo de forma iterativa. En cada pasada
se decide que nueva informacion es conveniente incorporar al
Caso que representa a la aplicacion Android analizada, con
la finalidad de mejorar su posterior categorizacion. De hecho,
desde el punto de vista de las tecnicas de aprendizaje automatico, este comportamiento puede verse como una especie
de seleccion de caractersticas (feature selection) previa a la
clasificacion final de la aplicacion analizada.
II-B.
Recuperacion de informacion
En nuestro sistema hacemos uso de tecnicas y herramientas

tomadas del campo de la Recuperacion de Informacion (RI),
en concreto el Modelo Vectorial [7] de RI, para manejar de
forma eficiente la Base de Casos de nuestro sistema CBR. En
concreto, utilizamos un motor de indexacion de codigo abierto,
Apache Lucene [2], para dar soporte a la fase de Recuperacion
del ciclo CBR. Con ello pretendemos que sea posible trabajar
con grandes colecciones de muestras de aplicaciones Android,
previamente analizadas segun el ciclo CBR iterativo descrito,
anotadas y, finalmente, indexadas.
En el Modelo Vectorial de RI, cada documento, que en
nuestro sistema se corresponden con un Caso, que a su vez
almacenan el conjunto de representaciones extradas de una
muestra de una aplicacion Android bajo estudio, se representa
como un vector numerico. Los valores de este vector se

corresponden con el peso 1 o importancia que para dicho
documento tiene cada uno de los terminos de indexacion que
lo componen. En el caso de documentos textuales los terminos
de indexacion son los tokens o palabras que lo constituyen. En
nuestro caso estos terminos seran las caractersticas extradas
por los analizadores aplicados sobre la aplicacion Android
vinculada a cada Caso.
En tiempo de consulta, a cada termino de indexacion
presente en la consulta original se le asigna un peso y se
recuperan los documentos cuyos vectores sean mas similares
al vector consulta. En nuestro sistema las consultas sobre el
ndice Lucene se emplean durante la fase Recuperar para
identificar los Casos mas proximos a uno dado. Para construir
la consulta a lanzar sobre Lucene se utilizan como terminos
de busqueda el conjunto de caractersticas descriptivas de
dicho Caso, unidos por un operador OR global. En esencia,
lo que hacemos es utilizar el ndice Lucene para realizar
una busqueda por contenido que devolvera un ranking de los
documentos/casos mas parecidos al usado como muestra. A
la hora de consultar el ndice para recuperar la lista de Casos
Similares, los distintos tipos de caractersticas extradas del
Caso actual por los respectivos analizadores, se ponderan de
forma distinta, atendiendo al grado de credibilidad vinculado
al analizador que las genero. De nuevo, este parametro es
dinamico y se ajusta en cada iteracion en funcion de los pesos
que ese analizador tuviera asignados en el conjunto de Casos
Similares recuperados en la iteracion anterior. Dichos casos
fueron los responsables de la decision de incorporar ese tipo de
analisis en la representacion del Caso utilizada en la iteracion
actual.
III.
A RQUITECTURA DEL A NALIZADOR DE M ALWARE
Haciendo uso del esquema esbozado en la seccion anterior,

la arquitectura de nuestro prototipo de analizador de malware
para Android se estructura en tres grandes componentes:
Motor de analisis basado en CBR. Es el elemento
responsable de coordinar el ciclo CBR iterativo que
gobierna el proceso de analisis de las aplicaciones Android. Consulta el repositorio de muestras analizadas para
extraer los Casos Similares y, en funcion de ellos, decidir
si detener el ciclo CBR actual y proponer una categorizacion o seleccionar un nuevo analizador a aplicar sobre
la muestra considerada con la finalidad de enriquecer
su descripcion. En caso de decidir aplicar un nuevo
analizador, las caractersticas obtenidas se utilizan en la
siguiente iteracion del ciclo CBR.
Repositorio de muestras analizadas. Se corresponde
con la Base de Casos y consiste esencialmente en un
ndice Lucene que almacena las representaciones de las
aplicaciones analizadas. Tambien incluye al conjunto de
archivos binarios originales y a los metadatos vinculados
1 En RI existen diferentes esquemas de asignaci
on de pesos, siendo unos de
los mas utilizados los esquemas TF - IDF y BM 25. En ambos se combinan dos
aspectos: la importancia del termino en el documento concreto (cuantificado
a partir de su frecuencia de aparicion en ese documento) y una media de
la exclusividad o especificidad de dicho termino, que tiene en cuenta el
numero de documentos en los e ste aparece.
106
JNIC2015
a cada aplicacion Android, almacenados en documentos

JSON.
En el ndice Lucene cada documento se corresponde
con una aplicacion Android y posee tantos campos 2
como analizadores hayan sido empleados para generar
su representacion actual.
Coleccion de analizadores. Se trata de un conjunto de
analizadores que reciben una muestra de una aplicacion
Android y generan, o bien una representacion susceptible
de ser incorporada en el ndice Lucene (es decir, un
conjunto de terminos de indexacion) y que sera utilizada
en las consultas de similaridad (analizadores extractores
de caractersticas), o bien una indicacion del grado de
peligrosidad de la muestra analizada (analizadores evaluadores), o bien ambas cosas (analizadores mixtos).
En la version actual del prototipo casi todos los analizadores son de tipo estatico, aunque la plataforma esta
abierta a incorporar herramientas de analisis dinamico.
La mayor parte de estos analizadores hacen uso de la librera de ingeniera inversa para Android Androguard [1].
n-gramas de codigos de operacion. Extrae la lista de
bigramas y trigramas a partir de las secuencias de codigos
de operacion extradas de los bytecodes de la muestra
analizada. Dado que estos n-gramas seran posteriormente
indexados, el esquema resultante es hasta cierto punto
similar al descrito en [4], aunque de un modo mucho mas
simple y limitado.
permisos solicitados. Es un analizador mixto que extrae
la lista de permisos solicitados en el manifiesto de la
aplicacion Android. Adicionalmente, tambien valora la
peligrosidad de los mismos en base a una tabla de riesgo
estatica.
permisos utilizados. Es otro analizador mixto similar
al anterior, que se alimenta de los permisos vinculados a
las llamadas al API de Android que se realizan desde el
codigo de la aplicacion.
cadenas de texto. Extrae las cadenas de texto (mensajes,
errores, etc) presentes en el codigo de la muestra.
llamadas al API. Extrae los nombres de las clases y
metodos del API de Android invocados desde la aplicacion
analizada.
nombres de clases. Extrae los nombres completos de las
clases que conforman la aplicacion analizada.
Adicionalmente, se incluye a modo de muestra un analizador mixto que hace uso de la API publica del servicio
VirtusTotal [3]. Este analizador cuantifica el nivel de
peligrosidad de la muestra a partir de los resultados
devueltos por esta API y caracteriza la muestra de cara
a su indexacion tomando nota los antivirus que declaran
a la muestra como malware y el tipo de malware que
le vinculan. Idealmente, este analizador sera el u ltimo
recurso en caso de que el ciclo CBR iterativo no llegara a
alcanzar un decision concluyente, dado que la invocacion
remota de la API de VirusTotal lo hace muy costoso.
IV.
para Android desarrollado. El trabajo realizado hasta el momento ha sido fundamentalmente de desarrollo y validacion
de la herramienta, no habiendose realizado aun pruebas de
rendimiento exhaustivas sobre colecciones de aplicaciones
Android de referencia. Tampoco se ha realizado un ajuste
de parametros (numero maximo de casos similares a considerar, esquema de ponderacion a utilizar en Lucene [tf-idf vs.
BM25], analizadores semilla con los que inicializar el ciclo
CBR, etc), ni su comparacion con otras propuestas en el campo
del analisis de malware en Android.
En el proceso de validacion ha hecho uso de la coleccion
de muestras de malware Android recopiladas por el equipo del
Android Malware Genome Project) [8], junto con un conjunto
de alrededor de 180 muestras de aplicaciones legtimas recopiladas por los autores. Las pruebas se han centrado en comprobar el efecto de los distintos analizadores en la categorizacion
de las muestras, pero no son suficientemente exhaustivas, ni
comparables con los resultados de otros sistemas, dado que el
conjunto de datos no es totalmente estandar.
El trabajo futuro inmediato es realizar el estudio y ajuste
de los parametros del sistema y evaluar su rendimiento en
comparacion con los sistemas que conforman el estado del
arte actual en la investigacion sobre deteccion de malware en
Android. A medio plazo, se pretende incorporar analizadores
que empleen aproximaciones dinamicas, con la intencion de
emplearlos en los casos donde los analisis estaticos actuales
no sean capaces de concluir una categorizacion definitiva con
suficiente credibilidad.
R EFERENCIAS
[1] Androguard, Reverse engineering, Malware and goodware analysis of
Android applications, en lnea, https://github.com/androguard/androguard,
(ultimo acceso 9/7/2015)
[2] Apache Lucene, en lnea, https://lucene.apache.org/, (ultimo acceso
9/7/2015)
[3] Virus Total, en lnea, https://www.virustotal.com/, (ultimo acceso
9/7/2015)
[4] I. Santos, X. Ugarte-Pedrero, F. Brezo, P. G. Bringas, NOA: An information retrieval based malware detection system, Computing and
Informatics, vol. 32, pp. 1001-1030, 2013
[5] M. Egele, T. Scholte, E. Kirda, and C. Kruegel, A survey on automated
dynamic malware-analysis techniques and tools, ACM Computing Surveys, vol. 44, no. 2, pp. 6:16:42, 2012.
[6] A. Aamodt, E. Plaza. Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches, Artificial Intelligence
Communications vol. 7, no. 1, 39-52, 1994.
[7] G. Salton , A. Wong , C. S. Yang,A vector space model for automatic
indexing, Communications of the ACM, v.18 n.11, pp. 613-620, 1975
[8] Y. Zhou, X. Jiang, Dissecting Android Malware: Characterization and
Evolution, Proc. of the 33rd IEEE Symposium on Security and Privacy.
San Francisco, CA, 2012
DE LA H ERRAMIENTA Y T RABAJO
VALIDACI ON
F UTURO
En este resumen hemos esbozado los fundamentos teoricos

y la arquitectura general del sistema de analisis de malware
2 En Lucene los campos (Fields) son un mecanismo para estructurar un
documento en porciones consultables de manera independiente.
107
JNIC2015

1
Informing Protocol Design Through

Crowdsourcing: the Case of Pervasive Encryption
Anna Maria Mandalari
Marcelo Bagnulo
University Carlos III of Madrid
University Carlos III of Madrid
Abstract Middleboxes play an important role in the

modern Internet ecosystem. They perform advanced functions, but they can turn net into a hostile ecosystem for
innovation. It is therefore essential, when designing a new
protocol, to first understand its interaction with the elements of the path. We show how to make informed protocol design choices by using a crowdsourcing platform. We
consider a specific use case, namely the case of pervasive
encryption in the modern Internet. We perform largescale TLS measurements to advance our understanding on
whether wide adoption of encryption is possible in todays
Internet.
I. Introduction
The indisputable success of the Internet and, consequently, the increasing demand from end-users for more
secure and faster access to the online services drives the
need for continuous innovation. Modern networks often rely on dedicated hardware components generically
dubbed middleboxes to perform advanced processing functions like, for example, enhancing application performance, traffic shaping, optimizing the usage of IPv4 address space or security.
One major criticism of middleboxes is that they might
filter traffic that does not conform to expected behaviors,
thus ossifying the Internet and rendering it as a hostile
environment for innovation [3].
This does not mean that it is impossible to deploy new
protocols, but that in order to ensure success it is imperative to first understand the interaction of the proposed
solutions with the middleboxes active along the path. Recent studies [5],[4] on middleboxes behavior attempt to
provide such information. However, the existing measurements use only a very small number of vantage points,
e.g., in [5] only 142 measurement points are used.
Until recently, large-scale Internet measurement infrastructures necessary to perform this type of analysis were
available only to large Internet players, such as Google,
Akamai and large ISPs. Consequently, the lack of public
access to such resources makes it hard to repeat or verify
their results.
The emerging sea of crowdsourcing (such as the Amazon
Mechanical Turk, Microworkers and others) can provide
an accessible alternative to perform large scale Internet
measurements. By expanding the traditional crowdsourcing focus from the human element to use a diverse and
numerous group of end-user devices as measurement vantage points [2] we can leverage on crowdsourcing platforms
to run Internet wide measurements.
In this paper, we show how to make informed protocol
design choices by using a novel methodology for performing large scale Internet measurements, using a crowdsourc-
Andra Lutu
Simula Research Laboratory
ing solution approach. We exemplify next the efficiency of

our methodology in the case of evaluating the feasibility
of pervasive encryption in the modern Internet ecosystem.
In other words, we need to establish at this point
whether using encryption in traditionally unsecured ports
is even possible in todays Internet. In this paper, we attempt to initiate TLS connections in 68 different ports
that normally do not use any form of encryption and analyze the success of the connection. This is a first necessary
step towards a full comprehension of the behavior of middleboxes relative to pervasive encryption.
II. Methodology
In this section, we describe the measurements methodology we employ to assess the potential success of deploying secure protocols in the Internet using crowdsourcing.
We try to establish TLS connections from a large number of vantage points (from now on, measurement agents
(MAs)) to a large number of ports, which traditionally do
not use TLS in a target server (from now on, measurement
server (MS)), using crowdsourcing based measurements.
Crowdsourcing platforms connect employers and workers
from around the world. The employer is the one who creates the task (or the micro-job) for workers and specifies
the parameters of its campaign, e.g., the size of the set of
users performing the task or their geographical location
at country level.
We argue that this approach can become an important
tool for evaluating innovation solutions, primarily due to
the large number of accessible and diverse measurement
vantage points. Additionally, we can benefit from the freedom of deploying our own custom-designed measurement
tests.
We recruit users through the Microworkers crowdsourcing platform to complete measurements on the feasibility
of pervasive encryption in the current Internet ecosystem.
To capture how effective would pervasive encryption actually be if deployed in todays Internet, we collect and
analyze the results from more than 2,000 MAs that try
to establish TLS connections in a large number of ports
which normally do not use TLS.
The MAs attempt to establish both HTTP and TLS
connections to 68 different ports, namely 10 well-known
ports, 56 registered ports and 2 ephemeral ports. We use
the success rate of the HTTP connections as the benchmark against which we compare the number of TLS successful connections. We establish then the success rate of
the TLS connection by contrasting the result against the
status of an unencrypted HTTP connection established in
the same port. We also store and analyze in detail the
108
JNIC2015

2
TABLE 1: Results
table
Analysis
Port 80 (%)
Average other ports (%)
Aggregated
Fixed
Mobile
Proxy
Non-proxy
16,5
9
25
70
10
5,8
6,95
4,54
4,23
6,8
TABLE 2: Packets analysis

table
Analysis
All
Port 80
Proxy
Non-proxy
Proxy (80)
Non-proxy (80)
Fixed Line
SYN(%) NO SYN(%)
96,8
3,2
88,3
11,7
Mobile
SYN(%) NO SYN(%)
36
64
27,7
72,3
22,2
77,8
12,7
87,3
9,6
90,4
36,4
63,6
server side packet exchanges.

The procedure is as follows. First, we start by asking
the user to connect using a HTTP connection in port 80
to a webpage we provide. Meanwhile, in the background,
HTTP and HTTPS connections are performed from the
measurement devices to our servers in all the other 67
ports. In this case, data about the performance are collected in the MS.
Second, the webpage we provide contains a short form
asking for additional input about the type of Internet access they are using. Finally, on the server side, we also
collect and store metadata on each of the MAs that connect to our servers, such as the IP address, the user agent
type, the language, and any other information included in
the HTTP header.
III. Results
In the campaigns for fixed lines, we recruit 1,165 workers from 53 different countries. The MAs are hosted in
286 ASes overall.
For the mobile case study, we recruit 956 workers, from
45 different countries and 183 ASes.
Considering that each MA performs 68 connections to
our MS, we build a complex dataset for a total of 114,228
connections 1 .
Table 1 refers to the results obtained from aggregated
results, for both fixed line and mobile network (label Aggregated ), the results from users that use a fixed line and
from users connected to a cellular network (labels Fixed,
Mobile). We also compare the rate of successful TLS connections for users we detect using a proxy and for users
that do not (labels Proxy, Non-proxy) in mobile network
scenario. To better understand how proxies or other middleboxes behavior impacts the performance of the TLS
protocol in unconventional ports, we focus on the packet
analysis, splitting the analysis for fixed line, mobile and
for users that use or not a proxy.
Table 2 refers to the percentage of SYN we receive when
users try to establish a TLS connection to our MS from
fixed line use case and from mobile network, considering
all port and particularizing the analysis for port 80 (labels
1 The
data
set
is
freely
http://it.uc3m.es/amandala/dataset.php
available
on
All, Port 80 ). Moreover, in the case of mobile network we

particularize the analysis for proxy/non-proxy case (labels
Proxy, Non-proxy, Proxy (80), Non-proxy (80)).
We observe that in the case of proxies, 90% of the SYN
packets are missing. While this may seem non causal at
first (as the SYN packet is forwarded before the middle
box actually knows whether this is a regular HTTP connection or a TLS connection), proxies usually wait until
they receive the GET from the client to establish the connection to the server in order to apply their policies. This
explains why in the case of TLS, we miss a high number
of SYN packets.
We also try to understand if the filtering of TLS is consistent across the different ports for a given MA. In other
words, if the TLS connection fails in a given port, how
likely is that it will fail in other ports. In order to quantify this, we estimate the conditional probability of failure
in a given port X given that the TLS connection in port
80 has failed. We choose the port 80 as it is in general
a port with high failure rate. We estimate the aforementioned conditional probability for the case of fixed line and
for the case of mobile network without proxies. We can
see that the estimated conditional probability is around
90% in both cases (slightly higher in the fixed line case),
implying that when the TLS connection fails in port 80,
it is very likely that it will fail in the other ports.
IV. Conclusion
In this paper we describe an experimental model for using crowdsourcing platforms to perform large-scale Internet measurements. Our research efforts expand the traditional crowdsourcing focus from the human element to use
a diverse and numerous group of end-user devices as measurement vantage points. We demonstrate the described
approach while assessing the feasibility of deploying encryption by default in the Internet. We focus our crowdsourcing campaigns on building a representative dataset to
show the potential success of widespread adoption of TLS
encryption for existing protocols in their native ports.
We find that in average the failure rate of TLS over
different ports is near the 6%. We also find that in the case
of mobile networks where proxies are used, the failure rate
can be as high as 70%. We conclude that it is probably
feasible to roll out TLS protection for most ports except
for port 80, assuming a low failure rate (6%).
We believe that our results can serve as a lower bound
for the failure rate for using protocols other than expected
in different ports.
References
[1] A. Bittau et al. The case for ubiquitous transport-level encryption. In USENIX, 2010.
[2] A. Doan et al. Crowdsourcing systems on the world-wide web.
ACM, 2011.
[3] M. Handley. Why the internet only just works. BT Technology
Journal, 2006.
[4] B. Hesmans et al. Are TCP extensions middlebox-proof? In
Workshop on Hot topics in middleboxes and network function
virtualization. ACM, 2013.
[5] M. Honda et al. Is it still possible to extend TCP? In ACM
IMC, 2011.
109
JNIC2015

1
Cifrado de datos con preservacion del formato

V. Gayoso Martnez1 , L. Hernandez Encinas1 , A. Martn Mu
noz1
J. M. de Fuentes2 , L. Gonzalez Manzano2
1
Instituto de Tecnologas Fsicas y de la Informacion (ITEFI)
Consejo Superior de Investigaciones Cientficas (CSIC), Madrid
{victor.gayoso, luis, agustin}@iec.csic.es
2
Computer Security Lab (COSEC), Universidad Carlos III de Madrid, Leganes, Madrid
{jfuentes, lgmanzan}@inf.uc3m.es
ResumenEn esta contribuci

on se introducen las t
ecnicas
de cifrado con preservaci
on del formato, las cuales tienen
una importancia fundamental en el cifrado de bases de datos en las que, por motivos de compatibilidad, no se desea
realizar modificaciones en el formato de los tipos de datos.
De manera adicional, se presentan los detalles de implementaci
on de uno de los algoritmos m
as conocidos sobre este
tema, aportando un ejemplo completo de cifrado y descifrado que permitir
a comprobar sus propias implementaciones
al lector interesado.
n
I. Introduccio
El uso de las Tecnologas de la Informaci
on y de la Comunicacion (TIC) se ha generalizado en el da a da de empresas y usuarios de internet. Esta situaci
on, aunque por
un lado facilita el intercambio de grandes vol
umenes de informaci
on, conlleva al mismo tiempo importantes riesgos
y amenazas [1].
Uno de los pilares b
asicos de cualquier estrategia de ciberseguridad lo constituyen las tecnicas de cifrado, que tienen como objetivo principal asegurar la confidencialidad
de la informaci
on, de manera que un atacante no pueda
acceder a los datos originales.
Dentro de esas tecnicas, se encuentran las de clave
simetrica, donde los dos extremos de la comunicacion utilizan la misma clave (mencionada habitualmente como clave
secreta), y las de clave asimetrica, que utilizan durante su
ejecuci
on un par de claves (a las que se suele denominar
clave p
ublica y privada) [2]. En ambos casos, el resultado
de cifrar cualquier tipo de informaci
on es una secuencia
binaria aparentemente aleatoria y cuya longitud depender
a del algoritmo utilizado.
Los algoritmos de clave simetrica tienen como ventaja sobre los de clave asimetrica su mejor rendimiento y
menor longitud de clave, debido principalmente a que las
operaciones matematicas empleadas en ese caso son mas
sencillas que las equivalentes utilizadas en los algoritmos
de clave asimetrica. En cuanto a los principales algoritmos
y funciones de clave simetrica, los mas conocidos son DES
y su sucesor AES [3].
La especificaci
on de AES describe c
omo cifrar bloques
de 128 bits empleando claves de 128, 192 o 256 bits, obteniendo como resultado un bloque cifrado de 128 bits [4].
Aunque empleando AES con cualquiera de los modos de
operaci
on recomendados [5] es posible cifrar cualquier da-
to, su utilizaci
on no permite garantizar el cumplimiento
de un requisito que, aunque parezca secundario, en determinados entornos es fundamental: la preservaci
on del
formato de los datos.
En el mundo empresarial y de las administraciones
p
ublicas existen circunstancias en las que, ademas de ser
necesario cifrar los datos, estos deben mantener el mismo
formato que los datos originales. Ello se debe principalmente a la necesidad de asegurar la compatibilidad con
las bases de datos y aplicaciones ya existentes, y que fueron dise
nadas para gestionar ciertos tipos de datos con
formatos predefinidos.
Obviamente, sera posible modificar dichas bases de datos y aplicaciones para que manejaran los datos cifrados
mediante, por ejemplo, el algoritmo AES, pero el coste
econ
omico y los plazos de modificacion para realizar tales
cambios aconsejan la b
usqueda de soluciones alternativas.
Y precisamente la mejor alternativa en esas situaci
on lo
constituye lo que en ingles se conoce como Format Preserving Encryption (FPE), o cifrado con preservaci
on del
formato.
Utilizando las tecnicas de FPE es posible, por ejemplo,
cifrar n
umeros de tarjetas de credito de manera que el
dato cifrado tambien sea un n
umero de tarjeta de credito,
o cifrar identificadores de DNIe de forma que el resultado
sea un DNIe distinto. Esto permite almacenar los datos
cifrados en bases de datos sin modificar su formato de
manera que, aunque su contenido sea hecho p
ublico, los
datos verdaderos no sean conocidos.
El presente trabajo tiene como primer objetivo realizar
una introduccion a las tecnicas de cifrado con preservaci
on del formato, la cual est
a recogida en la Seccion II.
La Secci
on III describe los procesos de estandarizacion en
este campo, mientras que la Seccion IV proporciona los
detalles de implementacion de uno de los algoritmos propuestos para su estandarizacion. Por su parte, la Seccion
V incluye un ejemplo completo de cifrado y descifrado
utilizando una implementacion Java del algoritmo anteriormente mencionado. Finalmente, la Seccion VI contiene
nuestras conclusiones junto con la identificacion de algunos potenciales problemas cuya solucion, al igual que la
implementacion del algoritmo en dispositivos con recursos
limitados, constituye un reto para los investigadores en el
campo de la ciberseguridad.
110
JNIC2015

2
n del formato
II. Cifrado con preservacio
Los orgenes de las tecnicas FPE pueden situarse en
1981, cuando se public
o la norma FIPS 74 [6] que contena un procedimiento basado en DES que permita que
el alfabeto de los mensajes en claro y los mensajes cifrados fuera el mismo. Posteriormente, en 1997, Smith y
Brightwell [7] ahondaron en la misma idea, refiriendose a
este concepto como datatype-preserving encryption debido a su utilizaci
on para preservar los tipos en las bases de
datos.
A pesar de la novedad que representaron esos documentos, en los dos casos mencionados el tratamiento no era
lo suficientemente profundo, por lo que suele considerarse que la primera contribuci
on consistente en este campo
fue la de Black y Rogaway [8], quienes se centraron en
c
omo cifrar un entero del rango {0, N 1} de manera que
el mensaje cifrado representara otro n
umero del mismo
rango.
Para resolver este problema, Black y Rogaway propusieron tres soluciones. El primer metodo, descrito por los
autores como prefix cipher, consista en realizar una permutacion de los n
umeros enteros del rango entre 0 y N 1.
Para ello, sugeran utilizar una funci
on de cifrado simetrico con una clave secreta aleatoria, de manera que se procesaran todos los n
umeros del rango y se ordenaran los
resultados (es decir, los mensajes cifrados) por orden alfabetico.
Por ejemplo, dados los n
umeros del 0 al 9, empleando
por sencillez en la explicaci
on la funci
on resumen SHA- 1
en lugar de una funci
on de cifrado simetrico con una clave
aleatoria, la ordenaci
on alfabetica de los res
umenes generara la secuencia 9, 4, 1, 3, 7, 5, 0, 6, 2 y 8, tal como
puede comprobarse con los res
umenes mostrados a continuacion, donde el prefijo 0x indica que la cadena situada
a continuacion est
a representada en formato hexadecimal.
0:0xB6589FC6AB0DC82CF12099D1C2D40AB994E8410C
1:0x356A192B7913B04C54574D18C28D46E6395428AB
2:0xDA4B9237BACCCDF19C0760CAB7AEC4A8359010B0
3:0x77DE68DAECD823BABBB58EDB1C8E14D7106E83BB
4:0x1B6453892473A467D07372D45EB05ABC2031647A
5:0xAC3478D69A3C81FA62E60F5C3696165A4E5E6AC4
6:0xC1DFD96EEA8CC2B62785275BCA38AC261256E278
7:0x902BA3CDA1883801594B6E1B452790CC53948FDA
8:0xFE5DBBCEA5CE7E2988B8C69BCFDFDE8904AABC1F
9:0x0ADE7C2CF97F75D009975F4D720D1FA6C19F4897
dada la siguiente secuencia (representada en la Fig. 1), el

resultado de cifrar el n
umero 2 sera el valor 9.
c1 = EK (2) = 6 + 7 = 13 13 mod 17
c2 = EK (13) = 39 + 7 = 46 12 mod 17
c3 = EK (12) = 36 + 7 = 43 9 mod 17
Fig. 1: Ejemplo de cifrados sucesivos

(fuente: www.di-mgt.com.au).
El tercer metodo, denominado generalized-Feistel cipher por los autores, permita una mayor flexibilidad en
el proceso de cifrado mediante el empleo de un esquema
Feistel. En este metodo, el n
umero a cifrar (presumiblemente de muchas cifras) se descompona en dos n
umeros
de aproximadamente el mismo tama
no, procediendose a
continuacion a realizar varias rondas hasta obtener un valor final. En cada ronda (ver Fig. 2) se utilizara una clave
Ki derivada de un elemento que podra ser hecho p
ublico,
y que habitualmente se denomina tweek. En caso de que
el elemento cifrado estuviera fuera del rango permitido,
se podra utilizar este metodo junto con el anteriormente
expuesto.
Fig. 2: Esquema de una ronda Feistel

(fuente: Wikimedia Commons).
Con ello, al realizar una operaci

on de cifrado el n
umero
0 se transformara en el 6, el 1 en el 2, y as sucesivamente.
El segundo metodo, denominado por los autores cyclewalking cipher, consista en utilizar una funci
on de cifrado
simetrico cuyo dominio fuera mayor que el conjunto de elementos a cifrar, realizando tantas operaciones de cifrado
como fuera necesario hasta obtener un mensaje cifrado
que perteneciera al conjunto de n
umeros validos.
Por ejemplo, dados de nuevo los n
umeros del 0 al 9, si
tuvieramos una funci
on de cifrado del tipo (ax + b) mod n
y seleccion
aramos los valores a = 3, b = 7 y n = 17,
Aunque las tres propuestas estaban bien argumentadas,

y su seguridad fue objeto de estudio en [8], no estaban
exentas de limitaciones.
Debido a la necesidad de generar (y almacenar de forma
segura) la ordenaci
on de los elementos, el primer metodo
solo estaba indicado para rangos de valores peque
nos. Por
su parte, el segundo metodo presenta como inconveniente el hecho de que, si la diferencia entre el dominio de
la funci
on de cifrado y el cardinal del conjunto a cifrar es
grande, cada proceso de cifrado necesitara un valor potencialmente elevado de operaciones de cifrado simetrico, por
lo que su uso estaba recomendado para valores cuya longitud en bits no difiriera mucho del tama
no de bloque de
111
JNIC2015

3
un algoritmo de cifrado simetrico. Por otra parte, la seguridad el metodo basado en la estructura Feistel dependa
del n
umero de rondas, y no era un metodo indicado para cadenas de datos de poca longitud (como por ejemplo
las cadenas que representan el n
umero de una tarjeta de
credito).
La Tabla 1 muestra un resumen de las longitudes en
bits y en dgitos recomendables para cada una de las tres
propuestas. Los datos de dicha tabla fueron calculados
por Rerence Spies [9], quien ademas fue el investigador
que utilizo por primera vez la expresion format-preserving
encryption [10].
Metodo Tama
no en bits N
umero de dgitos
Metodo 1
120
16
Metodo 2
5063
1619
Metodo 3
40240
1280
Tabla 1: Comparativa de longitudes recomendadas.
n
III. Estandarizacio
Debido al interes y aplicabilidad de las tecnicas de cifrado con preservaci
on del formato, el National Institute
of Standards and Technology (NIST) inici
o el trabajo de
estandarizacion de estas tecnicas aprobando como esquema general el conocido como FFX, propuesto por Bellare,
Rogaway y Spies en 2010 [11].
Posteriormente, el 9 de junio de 2011 procedio a solicitar propuestas concretas de algoritmos de FPE que se
ajustaran a dicho modelo. De entre las recibidas, el NIST
incluyo tres en el primer borrador de su documento SP
800-38G [12], publicado en 2013. En concreto, las tres propuestas incluidas en dicho borrador fueron:
FFX[Radix] (denominado FF1 internamente en el documento), desarrollado por Bellare, Rogaway y Spies [13].
VAES3 (FF2 en el documento), propuesto por Joachim
Vance [14].
BPS (FF3 en el documento), presentado por Eric Brier,
Thomas Peyrin y Jacques Stern [15].
Tras la publicacion del borrador, el NIST anunci
o la
apertura de un perodo de comentarios, el cual finaliz
o el
3 de septiembre de 2013. De los comentarios recibidos, el
mas importante fue un analisis de VAES3 [16] que afirma
haber descubierto un ataque de texto plano escogido que
demostrara que la seguridad de esa propuesta es menor
de los 128 bits requeridos por el NIST. En el momento de
escribir esta contribuci
on, todava no se ha publicado la
versi
on definitiva del documento, desconociendose cuando
se realizar
a dicha publicacion.
En paralelo a las actividades del NIST, el American National Standards Institute (ANSI) inici
o un trabajo equivalente con la idea de generar dos est
andares relacionados con el FPE: X9.119 [17], publicado en 2013, y que
define los requisitos de seguridad mnimos para proteger
datos sensibles de tarjetas en las transacciones comerciales, y X9.124, centrado en las tecnicas FPE, y que todava
est
a en desarrollo, sin que exista informaci
on disponible
para el p
ublico interesado.
n
IV. Implementacio
Puesto que el est
andar X9.119 no permite su libre
distribuci
on, y no hay informacion p
ublica de la norma
X9.124, el borrador del documento SP 800-38G es el u
nico est
andar relacionado con las tecnicas FPE libremente
disponible para la comunidad academica.
Con el objetivo de realizar una implementacion software
de alguna de las tres propuestas incluidas en ese documento, VAES3 fue descartado debido al analisis recogido en
[16]. De las dos restantes, la propuesta elegida para su implementacion fue FFX[Radix] debido a que, a diferencia de
BPS, dispone de vectores de prueba con los que contrastar
que la implementacion realizada es correcta [18].
Tal como se describe en [12], dada una cadena de caracteres X de longitud n, representada en la base radix, una
cadena de bytes T , de longitud t (el componente tweak ) y
una clave de cifrado K a utilizar con el algoritmo AES, el
proceso de cifrado consiste en los siguientes pasos:
1. Calcular los valores u = n/2 y v = n u.
2. Obtener los elementos A = X[1 . . . u] y B = X[u +
1 . . . n] (es decir, A representa los primeros u caracteres
de la cadena X, y B el resto).
3. Calcular los valores b = v log2 (radix )/8 y d =
4b/4 + 4.
4. Generar el elemento P = [1]1 ||[2]1 ||[1]1 ||[radix ]3 ||[10]1 ||
[u mod 256]1 ||[n]4 ||[t]4 , donde la expresion [x]y se utiliza
para representar una cadena de y bytes todos ellos con el
valor numerico x, y el smbolo || indica la operaci
on de
concatenaci
on.
5. Comenzando con i = 0, repetir los siguientes pasos
mientras i < 10, incrementando en cada iteraci
on el valor
de i en una unidad:
a) Generar el elemento Q = T ||[0]tb1 mod 16 ||[i]1 ||
[numradix (B)]b , donde numradix (x) es una funci
on que sirve para calcular el valor numerico asociado a la representacion x en la base radix.
b) Obtener el elemento R = PRF(P ||Q), donde PRF(x)
es una funci
on que genera una salida de 128 bits a partir
de una entrada cuya longitud sea m
ultiplo de 128, para lo
cual utiliza varias iteraciones de la funci
on de cifrado AES
(para mas detalles, consultar [12]).
c) Identificar el elemento S como los primeros d bytes
de la cadena R||AESK (R [1]16 )||AESK (R [2]16 )|| . . . ||
AESK (R[d/161]16), la cual est
a formada por d/16
bloques, y donde el simbolo representa la operaci
on
XOR.
d ) Calcular el valor y = num2 (S), es decir, el valor
numerico de la representacion binaria de S.
e) Realizar la asignacion m = u si el valor de i es par,
en caso contrario hacer m = v.
f ) Calcular el valor c = (numradix (A) + y) mod radix m .
g) Generar el elemento C = STRm
radix (c), donde la funon del valor
ci
on STRm
rad (x) permite obtener la representaci
numerico x como una cadena de m caracteres empleando
la base radix.
h) Realizar las asignaciones A = B y B = C en el orden
indicado.
6. Devolver A||B.
112
JNIC2015

4
En cuanto al proceso de descifrado, que b

asicamente
consiste en repetir los mismos pasos pero en orden inverso, dada una cadena de caracteres X de longitud n
representada en la base radix, una cadena de bytes T de
longitud t y una clave de cifrado K, est
a compuesto por
los siguientes pasos:
1. Calcular los valores u = n/2 y v = n u.
2. Obtener los elementos A = X[1 . . . u] y B = X[u +
1 . . . n].
3. Calcular los valores b = v log2 (radix )/8 y d =
4b/4 + 4.
4. Generar el elemento P = [1]1 ||[2]1 ||[1]1 ||[radix ]3 ||[10]1 ||
[u mod 256]1 ||[n]4 ||[t]4 .
5. Comenzando con i = 9, repetir los siguientes pasos
mientras i > 0, decrementando en cada iteraci
on el valor
de i en una unidad:
a) Generar el elemento Q = T ||[0]tb1 mod 16 ||[i]1 ||
[numradix (A)]b .
b) Obtener el elemento R = PRF(P ||Q).
c) Identificar el elemento S como los primeros d bytes
de la cadena R||AESK (R [1]16 )||AESK (R [2]16 )|| . . . ||
AESK (R [d/16 1]16 ).
d ) Calcular el valor y = num2 (S).
e) Realizar la asignacion m = u si el valor de i es par,
en caso contrario hacer m = v.
f ) Calcular el valor c = (numradix (B) + y) mod radix m .
g) Generar el elemento C = STRm
radix (c).
h) Realizar las asignaciones B = A y A = C, en ese
orden.
6. Devolver A||B.
Los datos iniciales, calculados antes de ejecutar las 10

rondas, son A = 12345678, B = 90123456, n = 16, u = 8,
v = 8, b = 4, d = 8, P = 0x01020100000A0A0800000010
0000000A y T = 0x39383736353433323130. A continuaci
on, las Tablas 2 a la 11 muestran los datos intermedios
obtenidos en cada ronda, donde el elemento m toma siempre el valor 8.
Es importante se
nalar que, tal como est
a descrita la
operativa de descifrado en [12], esta contiene varios errores
de transcripci
on (m
as concretamente, en los pasos 5-(a),
5-(f) y 5-(h)).
La implementacion del algoritmo FFX[Radix] se ha
realizado utilizando el lenguaje de programacion Java
Standard Edition 8. Para ello, se ha empleado la clase
BigInteger [19], que permite operar con n
umero enteros
de cualquier longitud, superando de esta manera las limitaciones de los tipos primitivos int y long [20].
V. Ejemplo
Con el fin de demostrar la aplicabilidad de esta tecnica
al campo del comercio electronico, y puesto que ninguno
de los cinco vectores de test incluidos en [18] se refiere
al cifrado de una cadena de 16 dgitos, que es el caso de
los n
umeros de las tarjetas de credito, en los siguientes
apartados se muestra un ejemplo de cifrado y descifrado
obtenido mediante nuestra implementacion Java.
A. Cifrado
A continuacion se incluyen los datos del ejemplo de cifrado para la cadena 1234567890123456
(con representacion decimal), para lo cual se ha
empleado la cadena tweak 9876543210 y la clave
0x2B7E151628AED2A6ABF7158809CF4F3C a utilizar por el
algoritmo AES.
113
Q 0x393837363534333231300000055F2CC0
R 0xA63A9DBAAAB229E8CC093726AF2CFAB8
S
0xA63A9DBAAAB229E8
y
11978059583998536168
c
10881846
A
90123456
B
10881846
Tabla 2: Ronda 0 del proceso de cifrado.
Q 0x39383736353433323130000100A60B36
R 0xB145E2726676AC58DF76B53984E55C29
S
0xB145E2726676AC58
y
12773864899079482456
c
69605912
A
10881846
B
69605912
Q 0x39383736353433323130000204261A18
R 0x44A46670E32AB291F7BBBF5CAB2C2864
S
0x44A46670E32AB291
y
4946190925793243793
c
4125639
A
69605912
B
04125639
Q 0x393837363534333231300003003EF3C7
R 0xF2987448C3DE1143C7391C098CA2408E
S
0xF2987448C3DE1143
y
17480849809511158083
c
80763995
A
04125639
B
80763995
Q 0x39383736353433323130000404D05C5B
R 0xE68B9CF4E1D79BE885B6C4C2C1321FDE
S
0xE68B9CF4E1D79BE8
y
16612544226061163496
c
65289135
A
80763995
B
65289135
JNIC2015

5
Q 0x39383736353433323130000503E43BAF
R 0xF6ED3ADC4E6892E097175E3AABEF3B38
S
0xF6ED3ADC4E6892E0
y
17792942420693390048
c
74154043
A
65289135
B
74154043
ABF7158809CF4F3C para la funci

on AES que en el ejemplo
anterior. La inclusi
on de los datos asociados al proceso de
descifrado sera u
til para los potenciales implementadores
de este algoritmo, puesto que los vectores de prueba de [18]
no contienen los valores intermedios de ning
un ejemplo de
descifrado.
Los datos iniciales, calculados antes de ejecutar las 10
rondas, son A = 49561199, B = 13561817, n = 16, u = 8,
v = 8, b = 4, d = 8, P = 0x01020100000A0A0800000
0100000000A y T = 0x39383736353433323130. Puesto
que en cada ronda de descifrado los elementos Q, R, S,
y y m coinciden con los de la correspondiente ronda de
cifrado, la Tabla 12 muestra u
nicamente los elementos c,
A y B obtenidos en cada ronda (donde el lector debe recordar que, en el proceso de descifrado, la primera ronda
ejecutada es la n
umero 9, y la u
ltima la n
umero 0).

Q 0x393837363534333231300006046B803B
R 0xA94C81462E19F661CDDB6D22EC50940B
S
0xA94C81462E19F661
y
12199267629060978273
c
26267408
A
74154043
B
26267408
Ronda
9
8
7
6
5
4
3
2
1
0

Q 0x3938373635343332313000070190CF10
R 0xFA71EAF5C58B4D3FC795BB4323188D43
S
0xFA71EAF5C58B4D3F
y
18046463523152416063
c
26570106
A
26267408
B
26570106
c
26570106
26267408
74154043
65289135
80763995
4125639
69605912
10881846
90123456
12345678
A
26570106
26267408
74154043
65289135
80763995
04125639
69605912
10881846
90123456
12345678
B
49561199
26570106
26267408
74154043
65289135
80763995
04125639
69605912
10881846
90123456
Tabla 12: Datos obtenidos en las rondas de descifrado.
Q 0x39383736353433323130000801956D7A
R 0xD3ADCC550C3C295F5A072FD2604ACD95
S
0xD3ADCC550C3C295F
y
15253072178623293791
c
49561199
A
26570106
B
49561199
Una vez concluida la u

ltima ronda de descifrado,
se puede concluir que el resultado final es el n
umero
1234567890123456, obtenido al concatenar los elementos
A y B.
A ttulo ilustrativo, el tiempo medio de ejecuci
on de 100
procesos de cifrado ha sido 326 milisegundos, mientras que
el tiempo medio de ejecuci
on de 100 descifrados ha sido
323 milisegundos. Tal como era de esperar, debido al dise
no del algoritmo los tiempos de cifrado y descifrado son
practicamente iguales. Para la realizaci
on de las pruebas,
se ha utilizado un PC con sistema operativo Windows 7
Professional y procesador Intel Core i7 a 3.40 GHz.

Q 0x39383736353433323130000902F43E6F
R 0x9AD091D9651C215FF52BC77234D59DE5
S
0x9AD091D9651C215F
y
11155576639886991711
c
13561817
A
49561199
B
13561817
VI. Conclusiones

Una vez concluida la u
ltima ronda, se puede concluir
que el resultado final es el valor obtenido al concatenar
los elementos A y B o, lo que es lo mismo, el n
umero
4956119913561817.
B. Descifrado
A continuacion se incluyen los datos del ejemplo de descifrado correspondientes a la cadena 4956119913561817
(con representacion decimal), utilizando la misma cadena
tweak 9876543210 y la misma clave 0x2B7E151628AED2A6
En esta contribuci
on, se ha presentado y descrito uno
de los algoritmos de FPE candidatos para su estandarizacion por el NIST y ANSI. Este algoritmo, denominado
FFX[Radix], es lo bastante flexible para poder ser usado
con distintas bases (decimal, hexadecimal, alfanumerica,
etc.) y con independencia de la presencia del valor tweak.
Tras su implementacion mediante el lenguaje Java, puede observarse que su aplicacion al cifrado del n
umero de
las tarjetas de credito parece limitar su funcionamiento,
puesto que por ejemplo los diversos valores y generados
no difieren mucho entre s en cada iteraci
on del bucle, y
el elemento S siempre se obtiene u
nicamente a partir del
elemento R, lo que aconseja un estudio en mayor profundidad a fin de determinar si dichas caractersticas facilitan la
aparici
on de vulnerabilidades y los consiguientes ataques.
114
JNIC2015

6
Otra lnea de investigacion resultante del trabajo realizado consiste en el estudio de la posibilidad de implementar el mismo esquema en dispositivos con caractersticas
computacionales limitadas, como por ejemplo las tarjetas
inteligentes. Este tipo de dispositivos se caracteriza por su
portabilidad y elevado nivel de seguridad, caractersticas
requeridas en algunos escenarios reales de implantacion
comercial [21].
Como es sabido [22], el lenguaje Java Card tienen por
definicion algunas limitaciones comparado con el lenguaje
Java utilizado en ordenadores personales y servidores, como por ejemplo la imposibilidad de utilizar elementos de
tipo long, String o BigInteger.
Aunque es cierto que en su versi
on 2.2.2 Java Card
present
o la clase BigNumber [23], la cual permite realizar sumas y restas con n
umeros enteros de longitud
arbitraria, en la practica existen varias limitaciones en
su uso. Para empezar, el paquete al que pertenece,
javacardx.framework.math, es opcional, por lo que no
se encuentra implementado en muchas de las tarjetas disponibles comercialmente. Ademas, la especificaci
on Java
Card indica que, en caso de ser implementada la clase
BigNumber, el n
umero mnimo de bytes en los que almacenar el n
umero entero con el que se deseen realizar los
c
alculos es 8 [24], por que lo el correcto funcionamiento
de esta clase con n
umeros que requieran un mayor espacio de almacenamiento no est
a garantizado. Por u
ltimo, la
clase BigNumber no incluye ning
un metodo para realizar
reducciones modulares [24] (como las necesarias en el paso
5-f de los algoritmos de cifrado y descifrado presentados
en la Secci
on IV), por lo que dichas operaciones tendran
que implementarse mediante sucesivas operaciones de sustraccion, lo que desde el punto de vista de la eficiencia
computacional constituye una opci
on demasiado costosa.
Por todo ello, implementar el algoritmo FFX[Radix] en
tarjetas Java Card constituye un reto cuya consecucion
permitira expandir las posibilidades de utilizaci
on de las
tecnicas FPE. Con el fin de conseguir una implementacion que fuera valida en cualquier tarjeta Java Card, sera
necesario desarrollar una clase equivalente a BigInteger
a partir de los tipos numericos disponibles en Java Card,
que permitiera operar con n
umeros de longitud variable
(pero con representaciones mayores de 8 bytes) y que implementara de manera eficiente operaciones de aritmetica
modular.
[4] National Institute of Standards and Technology, Advanced

Encryption Standard, NIST FIPS 197, 2001.
[5] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: Methods and Techniques, NIST SP 800-38A, 2001.
[6] National Institute of Standards and Technology, Guides for
Implementing and Using the NBS Data Encryption Standard,
NIST FIPS 74, 1981.
[7] M. Brightwell y H. Smith, Using Datatype-Preserving Encryption to Enchance Data Warehouse Security, en 20th NISSC
Proceedings, pp. 141149, 1997.
[8] J. Black y P. Rogaway, Ciphers with Arbitrary Finite Domains, Lecture Notes in Computer Science, vol. 2271, pp. 114
130, 2002.
[9] T. Spies, Format Preserving Encryption, in
edito, 2011.
[10] M. Bellare et al., Format-Preserving Encryption, Lecture Notes in Computer Science, vol. 5867, pp. 295312, 2009.
[11] M. Bellare et al., The FFX Mode of Operation for FormatPreserving Encryption, propuesta enviada al NIST, 2010.
[12] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: Methods for
Format-Preserving Encryption, NIST SP 800-38G, 2013.
[13] M. Bellare et al., Addendum to The FFX Mode of Operation
for Format-Preserving Encryption, propuesta enviada al NIST,
2010.
[14] J. Vance et al., VAES3 Scheme for FFX, propuesta enviada
al NIST, 2011.
[15] E. Brier et al., BPS: a Format-Preserving Encryption Proposal, propuesta enviada al NIST, 2010.
[16] National Institute of Standards and Technology, Analysis of
VAES3 (FF2), comentarios al borrador SP 800-38G, 2014.
[17] American National Standards Institute, Retail Financial Services - Requirements for Protection of Sensitive Payment Card
Data - Part 1: Using Encryption Methods, ANSI X9.119, 2013.
[18] Voltage Security, AES FFX Test Vector Data version 1.0,
documento enviado al NIST, 2011.
[19] Oracle Corporation, BigInteger (Java Platform SE 8), 2014.
Disponible en: http://docs.oracle.com/javase/8/docs/api/
java/math/BigInteger.html.
[20] H. Schildt, Java: The Complete Reference (9 ed.). Nueva York:
Mcgraw-Hill Osborne Media, 2014.
[21] W. Rankl y W. Effing , Smart Card Handbook (4 ed.). West
Sussex: John Wiley & Sons, 2010.
[22] V. Gayoso Martnez et al., Java Card implementation of
ECIES using prime and binary finite fields, en 4th International Conference on Computational Intelligence in Security for
Information Systems (CISIS 2011), pp. 160167, 2011.
[23] Oracle
Corporation,
Release
Notes
Java
Card
Specifications - Version 2.2.2, 2006. Disponible en:
http://www.oracle.com/technetwork/java/javacard/
documentation/releasenotes-jcspecspw-2-2-2-142671.html.
[24] Oracle Corporation, Application Programming Interface - Java
Card Platform - Version 2.2.2, 2006. Disponible en: http://www.
oracle.com/technetwork/java/javacard/specs-138637.html.
Agradecimientos
Este trabajo ha sido parcialmente subvencionado por
la Comunidad de Madrid (Espa
na) bajo el proyecto
S2013/ICE-3095-CM (CIBERDINE) y por el Ministerio
de Economa y Competitividad (Espa
na) bajo el proyecto
TIN2014-55325-C2-1-R (ProCriCiS).
Referencias
[1] Departamento de Seguridad Nacional, Estrategia de ciberseguridad nacional, Presidencia del Gobierno, 2013.
[2] A. F
uster Sabater et al., T
ecnicas criptogr
aficas de protecci
on
de datos (3 ed.). Madrid: RA-MA, 2004.
[3] A. F
uster Sabater et al., Criptografa, protecci
on de datos y aplicaciones. Madrid: RA-MA, 2012.
115
JNIC2015

1
Codigos monomiales vistos como subespacios

vectoriales invariantes
M. I. Garca-Planas, M. D. Magret, L.E. Um
Resumen Es bien sabido que los c
odigos cclicos son
muy u
tiles en aplicaciones en general y a los criptosistemas
en particular, ya que no resultan costosos desde un punto
de vista computacional, adem
as estos c
odigos alcanzan la
mayor distancia mnima posible de acuerdo a su longitud
y dimensi
on. Por otra parte, es bien conocida la relaci
on
existente entre los c
odigos cclicos y los subespacios invariantes. En este trabajo se presenta una generalizaci
on de
esta relaci
on considerando c
odigos monomiales sobre un
cuerpo finito F y subespacios hiperinvariantes de Fn con respecto una apropiada aplicaci
on lineal. Usando t
ecnicas de
Algebra
Lineal es posible deducir ciertas propiedades para
este tipo particular de c
odigos, generalizando resultados
conocidos sobre c
odigos cclicos.
n
I. Introduccio
Es bien sabido que los codigos correctores de errores y
los sistemas criptograficos tienen objetivos opuestos, ya
que con los codigos se trata de proteger la informaci
on
de los errores ocasionales consecuencia de su manipulaci
on es cecir, los que intentan resolver las dificultades
planteadas por falta de fiabilidad del canal y en los sistemas criptograficos tambien llamados codigos secretos,
se trata de garantizar su confidencialidad, integridad y
seguridad. Sin embargo tambien tienen objetivos complementarios. La dificultad para descodificar los c
odigos
correctores de errores se ha aprovechado para construir
sistemas criptograficos a partir de dichos codigos. Entre
dichos sistemas se encuentra el ya conocido de McEliece
para clave p
ublica. En tal sistema la clave privada de cada
usuario constituye la matriz generatriz G de un c
odigo lineal C sobre un cuerpo finito Fq junto con un algoritmo de
descodficacion. La matriz G se enmascara mediante una
matriz de permutacion obteniendo as la clave p
ublica, [1],
[2], [3].
Paralelamente el empleo de la criptografa para proteger las comunicaciones, esta la tecnica conocida como esteganografacuyo uso va en aumento y que consiste en el
disimulo de informacion y que se utiliza con el fin de proteger alguna informacion en un soporte numerico anodino
y es el soporte que es enviado sobre un canal p
ublico de
transmisi
on. Estas tecnicas de disimulo de informaci
on
est
an basadas en los codigos cclicos sobre el anillo Z4 ,
[4],[5]. Posiblemente se pueda mejorar la eficacia en el disimulo utilizando una generalizacion de los codigos cclicos
como pueden ser los codgos monomiales.
Una primera generalizacion de los codigos cclicos
fueron los codigos constacclicos introducidos por E. R.
Berlekamp en [6]. Una mas amplia generalizaci
on es la de
c
odigos monomiales y una primera aproximaci
on usando
algebra lineal para estudiar este tipo de codigos fue intro
ducido en [7]. los codigos monomiales tienen aplicaciones
pr
acticas ya que pueden ser codificados con registros de
desplazamiento.
Sea p sea un n
umero primo, q = pk para un cierto
k 1. Un c
odigo monomial q-ario de longitud n, se
puede definir a traves de una n n-matriz generadora con la propiedad de que cada fila (salvo la u
ltima)
(c1 , c2 , . . . , cn ), ci GF (q), define la siguiente fila como
(an cn , a1 c1 , a2 c2 , . . . , an1 cn1 ), donde a1 , . . ., an son
ciertos elementos fijos de GF (q)\{0}. Los c
odigos cclicos
(a1 = . . . = an = 1) y los c
odigos constacclicos (a1 =
. . . = an1 = 1) son subclases especiales de los c
odigos
monomiales de GF (q)n . De forma similar, los c
odigos
monomials pueden ser descritos en terminos de
algebra lineal. Este artculo est
a dedicado al estudio de estos c
odigos,
utilizando
algebra lineal,. Nuestro punto de partida sera
el polinomio caracterstico del endomorfismo de GF (q)n
cuya matriz en la base can
onica es la que representa al
c
odigo monomial.
Recordemos que, dado un endomorfismo de un espacio
vectorial E sobre el cuerpo F, un subespacio V E invariante es hiperinvariante si es invariante por todas las
aplicaciones lineales que conmutan con .
II. Subespacios invariantes por aplicaciones
monomiales
Sea p un n
umero primo, q = pk para alg
un k 1 y F =
GF (q). Consideremos el n-dimensional espacio vectorial
Fn sobre el cuerpo F.
ametros de F
Sea a = (a1 , . . . an ) un conjunto de n par
y consideremos la siguiente aplicaci
on lineal
a : Fn Fn
(x1 , . . . , xn ) (an xn , a1 x1 , . . . , an1 xn1 )
(1)
cuya matriz asociada con respecto la base can

onica {e1 =
(1, 0, . . . , 0), e2 = (0, 1, . . . , 0), en = (0, 0, . . . , 1)} es:
0
a1
Aa = 0
..
.
0
0
0
a2
..
.
...
...
...
..
.
0
0
0
..
.
. . . an1
an
0
0
.
..
.
(2)
Esta matriz recibe el nombre de matriz monomial. Observamos que esta matriz se puede escribir como producto de
una matriz diagonal diag (an , a1 , . . . , an1 ) y una matriz
116
JNIC2015

2
permutacion
0
1
..
.
0
0
1
..
.
...
...
...
..
.
...
Proposici
on 3: El centralizador C(Aa ) de Aa es el conjunto de matrices Ya = SXa S 1 , if Aa S = SAa .
Demostraci
on: Por la proposici
on 2, tenemos Xa Aa =
Aa Xa . Entonces, SXa S 1 Aa = Aa SXa S 1 .
1
0
0
.
..
.
1 0
0
0
0
..
.
Propiedades
Esta aplicacion verifica:
1) AanQ
= a1 . . . an In
n
2) si i=1 ai 6= 0 entonces A1
=
a
( a11 , . . . , a1n ).
Observar que si v = (v1 , . . . , vn ) es un vector propio of

Aa , entonces:
Qn 1
i=1
n1
a i Aa
an vn = v1
a1 v1 = v2
a2 v2 = v3
..
.
= Ata ,
donde a =
3) su polinomio
Qn caracterstico es pa (s) = det(A sIn ) =
(1)n (sn i=1 ai ).
Qn
Proposici
on 1: Supongamos que a = i=1 ai 6= 0. Entonces, la matriz
0 0 ...
0
an
a1 0 . . .
0
0
0 a2 . . .
0
0
Aa =
..
.. . .
..
..
.
.
.
.
.
0 0 . . . an1 0
es equivalente por la relacion
0 0
1 0
Aa = 0 1
.. ..
. .
de semejanza a
... 0 a
. . . 0 0
. . . 0 0
.
.
..
. .. ..
0 0 ... 1 0
Demostraci
on: Es facil probar que
an2 vn2
an1 vn1
0
0
a1 a2
..
.
...
...
...
..
.
...
Qn
0
0
0
..
.
i=1
Qn1
i=1
0
0
..
.
ai
y dado Ya C(Aa ), entonces

Ya v =
S(xn I + xn1 Aa + xn2 A2a + . . . + x1 An1
)S 1 v
a
1
2 1
= xn v + xn1 SAa S v + xn2 SAa S v + . . . +
S 1 v
+x2 SAan2 S 1 v + x1 SAn1
a
2
= xn v + xn1 v + xn2 v + . . . + x1 n1 v
= v
ai
con = xn + xn1 + x2 2 + . . . + x2 n2 + x1 n1 F.
En esta seccion probamos que los subespacios a invariantes son tambien a -hiperinvariantes, (aquellos que
son invariantes por todas las aplicaciones lineales que conmutan con a ), (Ver [8] y [9] para mas informaci
on acerca
de estos subespacios).
Necesitamos calcular el centralizador de Aa , para ello
primero calculamos el centralizador de la matriz Aa .
Proposici
on 2 ([7]) El centralizador C(Aa ) es el conjunto de las matrices Xa de la forma:
x
ax
ax
ax
. . . ax
ax
n
xn1
..
.
Xa = ..
.
x
3
x2
x1
xn
ax1
..
.
x4
x3
x2
x5
x4
x3
abx2
..
.
..
.
x6
x5
x4
...
n2
n1
axn3
axn2
..
.
...
...
...
ax1
xn
xn1
(4)
y tenemos la siguiente proposici

on.
Proposici
o
n
4:
Sea
GF
(q)
un elemento tal que
Qn
n = i=1 ai . Entonces, el subespacio [v] generado por el
vector v dado en (4) es un subespacio hiperinvariante.
Demostraci
on:
Aa v = v
con
0
a1
S =0
..
.
= vn1
= vn
En particular, tenemos que

n1
n2
v=
,
,...,
,1
a1 . . . an1 a2 . . . an1
an1
Aa S = SAa .
(3)
ax2
ax1
xn
Proposici
on 5: Sea F un subespacio invariante de Aa .
Entonces F es hiperinvariante.
Demostraci
on: Basta con observar que, para todo Ya
C(Aa ),
SXa S 1 = xn I + xn1 Aa + xn2 Aa2 + . . . + x1 An1
.
a

Por lo tanto, tenemos que en este caso el retculo de
subespacios invariantes coincide con el retculo de subespacios hiperinvariantes.
Hinv (Aa ) = Inv (Aa ).
Definici
on 1: i) Sea u = (u1 , . . . , un ) y v = (v1 , . . . , vn )
dos vectores in Fn . Definimos un producto interno sobre
F de la manera siguiente:
< u, v >= u1 v1 + . . . + un vn .
ii) Dos vectores u, v de Fn son ortogonales si, y s
olo si
< u, v >= 0.
117
JNIC2015

3
iii) Sea F un subespacio de Fn , definimos el espacio dual

(y lo denotaremos por F ) como
Demostraci
on:
`j
Pn
Pn ì n`
j
=
< ui , vj >= `=1 ì n`
= `=1
j
`
`
j`
Pn
Pn
i
i
nj = a1 . . . an `=1
=
`=1
j P
j

n
`
a1 . . . an P`=1 1 = a1 . . . an n si i = j
n
a1 . . . an `=1 ()` = 0 ( raz de la unidad) si i 6= j
F = {v F | u F, < u, v >= 0}.

Proposici
on 6: Sea F un subespacio invariante de Aa .
Entonces F es un subespacio invariante de A1
.
a
Demostraci
on: Sea v F , entonces, para todo u F
(consecuentemente Aa u F ) tenemos
0 =< Aa u, v >=< u, Ata v >=< u,
v>
< u, A1
a
Qn
i=1
ai An1
v >=
a
Luego A1
v F .
a
Sea F[1 , . . . , n ] una extension algebraica de F =

GF (q)pyQsean 1 , . . . , n los valores propios de a con
n
i = n i=1 i , i =p1, . . . , n, donde es una n-raz primiQn
arbitiva de la unidad y n i=1Qai es un cero fijo, (aunque
Qn
n
trario) del polinomio sn i=1 ai , donde 0 6= i=1 ai F.
Sean vi , i = 1, . . . , n los respectivos vectores propios. En
particular tenemos
De esta proposici
on se puede deducir f
acilmente, la matriz inversa de la matriz S.
digos monomiales vistos como subespacios
III. Co
invariantes
Definici
on 2: Un c
odigo C de longitud n sobre el cuerpo
F recibe el nombre de monomial con respecto a1 , . . ., an ,
si siempre que c = (c1 , . . . , cn ) este en C, entonces sc =
(an cn , a1 c1 , . . . , an1 cn1 ) est
a tambien en C.
La aplicaci
on sc se puede representar en forma matricial

an cn
c1
0 0 ...
0
an

n2
n1

a1 0 . . .
i
i
0
0
Aa vi = i vi , vi =
,
,...,
,1 ,
c2 a1 c1
a1 . . . an1 a2 . . . an1
an1

0 a2 . . .
0
0
c3 = a2 c2
..
.. . .
..
.. .. ..
.
.
i = 1, . . . , n,
.
.
. . .
an1 cn
cn
0 0 . . . an1 0
donde Aa es la matriz de
a : F[1 , . . . , n ]n F[1 , . . . , n ]n
definida como en 2.
Consideremos la base v = (v1 , . . . , vn ) de vectores propios de a . Aplicando el cambio de base a Aa a la base de
vectores propios, obtenemos la siguiente matriz diagonal
1 0 . . . 0
0 2 . . . 0
Da = .
= S 1 AS
... . . . ...
..
0
0 . . . n
y teniendo en cuenta (4) tenemos
n1
1
n1
a1 ...a
n2
1
a2 ...a
n1
..
S=
.
1
a
n1
1
n1
2
a1 ...an1
n2
2
a2 ...an1
...
...
..
.
2
an1
n1
n
a1 ...an1
n2
n
a2 ...an1
..
.
...
...
Definimos ahora los siguientes vectores
n
an1
ui = (i a1 . . . an1 , 2i a2 . . . an1 , . . . , n1 an1 , ni ),

1in
(5)
Proposici
on 7: El conjunto de vectores definidos en (5)
verifican la siguiente relacion.

a1 . . . an n if i = j
< ui , vj >=
0
if i 6= j
que corresponde a la matriz (2) de la aplicaci

on lineal (1).
Observese que en el caso en que ai = 1, para todo i, el
c
odigo es cclico y si a1 = . . . = an1 = 1 es constacclico
(ver [10]).
Si bien aplicando la proposici
on 1 el estudio podra reducirse al caso de los c
odigos constacclicos, vamos a hacerlo directamente sobre c
odigos monomiales. Estamos
interesados enQel caso en que an 6= ai para alg
un i =
n
2, . . . , an1 y i=1 ai 6= 0. En particular, tenemos que
considerar q > 2. Como consecuencia inmediata de la
definici
on 2 tenemos la siguiente proposici
on.
Proposici
on 8: Un c
odigo lineal C de longitud n sobre
el cuerpo F es monomial si, y s
olo si, C es un subespacio
Aa -invariante de Fn .
Como consecuencia de la proposici
on 5 tenemos el siguiente resultado.
Proposici
on 9: Un c
odigo lineal C de longitud n sobre
el cuerpo F es monomial si, y s
olo si, C es un subespacio
Aa -hiperinvariante de Fn .
Suponamos
Qnahora que (n, q) = 1 and pa (s) =
(1)n (sn i=1 ai ) no tiene races m
ultiples y descompone en factores irreducibles m
onicos todos distintos.
Proposici
on 10: Sea C un c
odigo quasicclico, y
pa (s) = (1)n pa1 (s) . . . par (s)
la decomposici
on de pa (s) en factores irreducibles. Entonces C = Ker pai1 (Aa ) . . . Ker pais (Aa ) para ciertos
subespacios Aa -invariantes minimales Ker paij (Aa ) de Fn .
Demostraci
on: Es f
acil ver que Ker pai (Aa ) para i =
1, . . . , r son Aa -invariantes. Para v Ker pai (Aa ), Aa v =
pa1 (Aa ) . . . par (Aa )v = 0.
118
JNIC2015

4
Los subespacios Ker paij (Aa ) son minimales puesto que

los polinomios pai (s) son irreducibles.
Ahora, definimos pbi (s) = pa (s)/pai (s). Teniendo en
cuenta que
mcd(b
p1 (s), . . . , pbr (s)) = 1,
existen polinomios q1 (s), . . . , qr (s) tales que
q1 (s)b
p1 (s) + . . . + qr (s)b
pr (s) = 1.
Sea x C, entonces x = q1 (Aa )b
p1 (Aa )x + . . . +
qr (Aa )b
pr (Aa )x. Llamando xi = qi (Aa )b
pi (Aa )x y teniendo
en cuenta que C es Aa -invariante y que xi Ker pai (Aa )
tenemos que xi C Ker pai (Aa ).

Ejemplo 1: Consideremos la matriz Aa para an =
2, a1 = 4, a2 = . . . = an1 = 1, n = 8 y q = 5. Entonces tenemos p(s) = pa (s) = s8 1. Factorizando
p(s) en factores irreducibles sobre F = GF (5) tenemos
pa (s) = p1 (s)p2 (s)p3 (s)p4 (s)p5 (s)p6 (s) = (s+1)(s+2)(s+
3)(s + 4)(s2 + 2)(s2 + 3). Los factores pi (s) definen subespacios Aa -invariantes minimales Fi = Ker pi (Aa ), para
i = 1, 2, 3, 4, 5, 6.
Definimos un codigo monomial C de la manera
C = F1 F5 = Ker (p1 (Aa )) Ker (p5 (Aa ))
p1 (s) p5 (s) = s3 + s2 + 2s + 2
la matriz siguiente
2 0 0 0 0
2 2 0 0 0
2 4 2 0 0
4 4 4 2 0
0 3 4 4 2
0 0 3 4 4
0 0 0 3 4
0 0 0 0 3
y A3a + A2a + 2Aa + 2I es

1
0
0
0
0
2
4
4
3
3
0
0
0
0
2
4
3
4
0
2
digos monomiales
IV. Matrices de paridad de co
Sea F[1 , . . . , n ] la extensi
on algebraica considerada en
la secci
on II.
Consideremos la base v = (v1 , . . . , vn ) vectores propios
de a . Del corolario 1 y con respecto a esta base tenemos
que c C si, y s
olo si g(Aa )c = 0.
Puesto que Da es una matriz diagonal, la matriz g(Da )
es tambien diagonal y
g(Aa ) = g(SDa S 1 ) = Sg(Da )S 1
La condici
on g(Aa )c = 0 se escribe como g(Da )c0 = 0
donde c0 = S 1 c.
Sin perdida de generalidad podemos suponer que
1 , . . . , n est
an ordenados de tal manera que g(i ) = 0,
para todo 1 i k y g(i ) = i 6= 0, para todo
k + 1 i n (entonces, y puesto que mcd(g(s), h(s))=1,
h(i ) 6= 0, para todo 1 i k y h(i ) = 0, para todo
k+1 i n). Dado c = (c1 , . . . , cn ) y c0 = (c01 , . . . , c0n ) tenemos que g(Da ) = (0, . . . , 0, k+1 c0k+1 , . . . , n c0n ). Equivalentemente:
0
..
.
k+1
a1 . . . an n
..
.
n
a ...a

n1
2
an1 n
1 1
n1 1 a2 ...an1 ... 1
1
c1
n1
2
n
a
...a
a
...a
...
2
1
n1
n1
2
n1
2
2
2
c.2
=
..
..
..
.. ..
.
.
.
.n
cn
2
n1
n a1 ...an1
n a2 ...an1 ... n an1 n
0

.
..
cc1
2
1
0
n
k+1 k+1 a1 ...an1
... k+1 k+1 ..

a1 . . . an1 n
c.n
..
..
.
.n
n n a1 ...an1
...
=0
Ker (Aa3 + A2a + 2Aa + 2I) =

[(1, 4, 2, 1, 3, 4, 2, 1), (1, 0, 4, 0, 2, 0, 1, 0),
(0, 3, 0, 4, 0, 2, 0, 1)] .
Corolario 1: Sea C un codigo monomial entonces existe
g(s) que verifica pa (s) = g(s) h(s) con gcd(g(s), h(s)) = 1
tal que g(Aa )c = 0, c C.
Considerando el producto interno introducido en la
definici
on 1, podemos definir el codigo dual de uno dado.
Definici
on 3: Sea C un codigo lineal de longitud n sobre
F. Definimos el codigo dual de C (y lo denotaremos por
C ) al conjunto de todas las palabras que son ortogonales
a todas las palabras de C.
C = {v Fn |< v, c >= 0, c C}.
Proposici
on 11: Sea C un codigo monomial con respecto a1 , . . ., an . Entonces, su codigo dual C es monomial
con respecto a11 , . . ., a1n .
Demostraci
on: Es consecuencia de la proposici
on 6.
En el caso en que a1 = . . . = an = 1 obtenemos el
resultado bien conocido sobre codigos cclicos.
Corolario 2: El codigo dual de un codigo cclico es
cclico.
n n
Entonces, podemos deducir la siguiente proposici

on.
Proposici
on 12: Sean uij , 1 j r = nk vectores de
la familia (5) correspondientes a ij con g(ij ) = ij 6= 0.
Entonces c es una palabra del c
odigo monomial C si y solo
si
uij c = 0, 1 j r.
Como consecuencia la matriz
A = (uij ) M(nk)n (F[1 , . . . , n ])
es una matriz de paridad del c
odigo monomial sobre el
cuerpo F[1 , . . . , n ].
Ejemplo 2: Sobre F = GF (5) consideramos un c
odigo
monomial C con an = a1 = 2, a2 = .
.. =
a1
= 1 yn = 4
definido por g(s) = s2 2. Sobre
F[ 2, 4 2,
3, 4 3], el
polinomio h(s) = s2 + 2 = (s 3)(s 4 3).
Entonces

3 2 3 3 3 4
3 3 3 2 3 4
es una matriz
de
F[ 2, 4 2, 3, 4 3].
119
paridad
del
c
odigo
sobre
JNIC2015

5
V. Distancia de Hamming
Recordemos que el peso de Hamming de un vector v es
el n
umero se entradas no nulas y lo denotamos por wH (v)
y se define la distancia de Hamming entre dos vectores
como el peso del vector diferencia, por lo que se tiene que
wH (x) = dH (x, 0). El peso mnimo de un c
odigo C es el
mnimo de todos los pesos de todas las palabras de C no
nulos.
wmin (C) = min06=xC (wH (x))
Teniendo en cuenta que dH (x, y) = dH (xz, y z) para
todo z y que en particular dH (x, y) = dH (x y, y y) =
dH (x y, 0) tenemos que sobre un cuerpo, la distancia de
Hamming es invariante por translacion y, en particular,
para c
odigos lineales, el peso mnimo es igual a la distancia
mnima.
Vamos a obtener una cota para la distancia mnima entre dos c
odigos monomiales de una forma similar a la presentada por Roos en [11] para codigos cclicos.
Sea F un cuerpo finito y
A = a1
...
an
a11
= ...
a1`
. . . an1
.. .
.
...
an`
Sea C un codigo lineal sobre F teneindo a A como matriz

de paridad y dH (A) la distancia mnima de C.
Recordemos que dH (A) = d si y solo si, cada conjunto
de d1 columnas es linealmente independiente y hay alg
un
conjunto de d columnas
de A es linealmente
dependiente.
x11 . . . x1n
..
.
..
Para una matriz X = .
con columnas
xm1 . . . xmn
xi Fm para 1 i n no nulas, consideramos
A(X) = x1 a1
...
xn an
Es bien conocido el siguiente resultado debido a Roos

([12]).
Lema 1: Si dH (A) 2 y cada m (m + dH (A) 2) submatriz de X tiene rango maximo, entonces dH (A(X))
dH (A) + m 1.
Definici
on 4:QSea M = [i1 , . . . , i` ] un conjunto de `
n
races de sn i=1 a i en F[1 , . . . , n ]. Diremos que
M es un conjunto consecutivo de longitud `, si existe una
n-raz p
primitiva
de la unidad
pQn y un exponente i tal que
Qn
M = [ n i=1 ai i , . . . , n i=1 ai i+`1 ].
Definici
on 5: a) Sea Q= [j1 , . . . , j` ] un conjunto de
n
ceros del polinomio sn i=1 ai . Definimos la matriz
j1 a1 . . . an1
..
A =
.
j` a1 . . . an1
M`n (F[1 , . . . , n ]).
2j1 a2 . . . an1
..
.
2j` a2 . . . an1
. . . nj1
..
.
. . . nj`
b) Sea U = [x1 , . . . , xm ] un conjunto consecutivo de ceros

del polinomio sn 1. Definimos la matriz
x1 x21 . . . xn1
..
.. M
XU = ...
mn (F[1 , . . . , n ]).
.
.
xm x2m . . . xnm
Sea C un c
odigo monomial definido por el polinomio
pa (s) = g(s) h(s) sobre el cuerpo de descomposicion
F[1 , . . . , n ] de pa (s) y consideramos ahora el conjunto
de todos los ceros de h(s). Siguiendo la proposicion
12 la matriz A es la matriz de paridad del c
odigo C, si
la distancia mnima de C sobre F[1 , . . . , n ] es dH (A ).
Entonces, la distancia mnima de C sobre F es al menos
dH (A ), puesto que C sobre F es un subc
odigo sobre un
subcuerop de C sobreF[1 , . . . , n ].
Observaci
on 1: N
otese que los menores de A son del
tipo de Vandermonde.
Teorema 1: Sea el conjunto definido en 5 y U un conjunto consecutivo de races de sn 1 tal que dH (A ) 2
0. Then, dH (A (XU )) dH (A ) + card U 1.
Demostraci
on: Es suficiente observar que en esta particular configuraci
on dH (A ) 2, entonces, podemos aplicar
el lema 1.
Como corolario deducimos de forma an

aloga al resultado obtenido por Radkova y Van Zanten,en [10], el siguiente teorema.
Teorema 2: Sea C un c
odigo monomial de longitud n
sobre F, y pa = g(s)h(s). Para ciertos n
umeros enteros
`, m 1, supongamos que h(s) tiene una cadena de m
ceros consecutivos: h(` ) = h(`+1 ) = . . . = h(`+m1 ) =
0. Entonces, la distancia mnima de C es al menos d.
Ejemplo 3: Sean n = 9, q = 7, an = 2, a1 = 3, a2 =
. . . = an1 = 1 y sea una 18-raz primitiva de la unidad.
Teniendo en cuenta que (x18 1) = (x9 1)(x9 + 1), es
una raz de x9 +1 y 2 = es una raz primitiva de x9 1.
Queremos clasificar los ceros con respecto a los divisores
irreducibles de x9 + 1. Determinamos las clases laterales
ciclot
omicas de 7 m
odulo 18 conteniendo los enteros impares: C1 = [1, 7, 13], C3 = [3], C5 = [5, 17, 11], C9 = [9],
C15 = [15].
Sean i los ceros de h(s) con i C1 C5 , por lo tanto
h(s) = (s )(s 7 )(s 13 )(s 5 )(s 17 )(s 11 ).
Dado que i = i = 2i+1 los ceros de h(s) pueden
escribirse como 2 ,3 ; 5 ,6 ; 8 , 9 . Luego h(s) tiene
una cadena de dos ceros consecutivos. Entonces, los dos
c
odigos monomiales tienen una distancia mnima d 3.
Referencias
[1] R.J. McEliece, A public key cryptosystem based on algebraic
coding theory. DNS Progress Report, pp. 42-44. Jet Propulsion
Laboratory- California Inst. Of Tech, (1978).
[2] E. Martnez Moro, C. Munuera G
omez. Un Sistema criptogr
afico
de clave p
ublica a partir de c
odigos correctores en Avances en
criptologa y seguridad de la informaci
on, Directores B. Ramos
Alvarez,
A. Ribagorda Garnacho, pp. 125-130, (2004).
[3] E. Celikel Cankaya, S. Nair, H. C. Cankaya. Applying error correction codes to achieve security and dependability. Computer
Standards & Interfaces. 35, pp. 78-86, (2013).
[4] H. Jouhari, El M. Souidi. A New Steganographic Scheme based
on First Order Reed Muller Codes. In Proceedings of the International Conference on Security and Cryptography, Sevilla, Spain,
pp. 351-356, (2011).
120
JNIC2015

6
[5] H. Jouhari, El M. Souidi. Application of Cyclic Codes over Z4

in Steganography. Journal of Applied Mathematical Sciences, 6,
(139), (2012).
[6] E.R. Berlekamp, Algebraic Coding Theory. Mc Graw-Hill,
NewYork (1968).
[7] M.I. Garcia-Planas, M.D. Magret, M.E. Montoro, Cyclic Codes
as Hyperinvariant Subspaces. Proceedings of 6th International
Conference on Physics and Control (PhysCon 2013,) (2013).
[8] P. Astuti, H.K.,Wimmer, Characteristic and hyperinvariant
subspaces over the field GF(2). Linear Algebra and its Applications, 438(4), pp. 1551-1563, (2013).
[9] P.A. Fillmore, D.A. Herrero, W.E. Longsta, The hyperinvariant
subspace lattice of a linear transformation. Linear Algebra and
its Applications, 17(2), pp. 125-132, (1977).
[10] D. Radkova, A.J., Van Zanten, Constacyclic codes as invariant
subspaces. Linear Algebra and its Applications, 430, pp. 855-864,
(2009).
[11] C. Roos, A New Lower Bound for the Minimum Distance of
a Cyclic Code. IEEE Transactions on Information Theory II-29
(3), pp. 330-332, (1983).
[12] C. Roos, A generalization of the BCH bound for cyclic codes,
including the Hartmann Tzeng bound . J. Comb. Theory Ser.
33, pp. 229-232, (1982).
121
JNIC2015
Towards Automatic Integration of Information

Security Governance and Management
using a BPMS approach
Angel J. Varela Vaca and Rafael M. Gasca
Universidad de Sevilla, Dpto. Lenguajes y Sistemas Informticos,
Avda. Reina Mercedes S/N, 41012, Sevilla, Espaa
Quivir Research Group, http://www.lsi.us.es/~quivir
{ajvarela, gasca}@us.es
Abstract- The information security management is more and

more carried out by means of business processes although
disregarding the quality of management enough. In order to
improve that quality, we propose to carry out the automation of the
information security governance. To achieve a high maturity level in
the information security management, the integration of processes
for good governance is needed, which enables to ensure the maturity
level 4: Qualitatively Controlled, such as ISO/IEC 21827:2008
proposed. This level allows establishing measurable quality goals
and objectively managing performance. This work enables to reach
these levels by using business process management systems to
implement a good information security governance, combined with
the integration of business processes for the information security
management.
I.
INTRODUCTION
Nowadays, Information has become in a corner stone in the

information society. Information is a crucial asset to any
business therefore it must be correctly protected. Currently, it
is common to find organizations that offer and consume
services and processes over the Internet. These services and
processes consume a wide range of information (social
network opinions, news feeds, financial data, etc.) that is
probably used for decision-making processes. For this reason
information assurance is an essential factor that has to be
ensured in the IT systems for the organizations. Since, an
information leakage can suppose terrible consequences [1]
such as lack of reputation or privacy loss among others.
Organizations are using business processes as core for the
business enterprise management. According to this idea,
business processes are being created to the Information
Security Management (ISM). In the majority of cases a Good
Governance of the IS is left out instead of becoming to a
strategic asset in the last years. For instance, Small and
Medium Enterprises (SME) composed almost the 98 percent of
the business landscape in Spain. Indeed, the 19.5 percent of
Spanish enterprises are currently breaking security regulations
like LOPD or LSSI [2] because of an incorrect way of directing
Information Security Governance (ISG).
The Governance and Management of the IS in conjunction
allows protecting the information provided by processes that
comply with the security requirements related to the
authenticity, integrity, confidentiality, availability and

traceability.
The question is how to propose the automatic integration of
both competencies with the idea to reach the level of maturity
in the security management according to the business goals.
This vision is being carried out for the ISG/ISM in the area of
development of projects of R&D in the Research Group
Tecnologas Inteligentes y de Seguridad en Sistemas de
Informacin which belongs to Foundation for Investigation
and Development of Information Technologies of Andalusia
(FIDETIA) and has been certified in the standard ISO/IEC
27001:2013 [3] in the last years.
The rest of the paper is structured as follows: Section II
show an overview of ISG by means of introducing the basis
and the framework followed; Section III brings both
automation and business processes up for a good ISG; Section
IV shows a successfully case study where processes and
mechanisms to automate ISG are shown in practice; in Section
V conclusions are drawn and future work is proposed.
II.
INFORMATION SECURITY GOVERNANCE
It is widely accepted that Information Security Governance

(ISG) is a subset of corporate or enterprise governance. The IT
Governance Institute (2001) defines enterprise governance as
the set of responsibilities and practices exercised by the board
and executive management with the goal of providing
strategic direction, ensuring that objectives are achieved,
ascertaining that risks are managed appropriately and verifying
that the enterprises resources are used responsibly. Then by
extending this definition, ISG could include: security
responsibilities and processes, risk assessment and
management, compliance with security policies, rules,
regulations and legislation, monitoring and control of security
activities. Our proposal is focused in the automation of ISG
with computational tools.
The framework followed; such as shown in Fig. 1,
implements three main processes:
Direct where Security Governance can establish

policies and define a pack of metrics to be measured in an
interactive and step by step way.
122
JNIC2015
Monitor where measurements are gathered during the

processes are enacted. Monitoring requires to include
pieces of software at the processes (imperceptible for
customers) that enable to collect information about the
metrics.
Evaluation which enables the Security Governance to

analyse the different metrics in order to decide whether new
countermeasures should be applied. This process can be
carried out manually when governance needs or a report
can be obtained regularly.
Automated Security Governance
Policies
Bussiness
rules
Constraints
Direct
Monitor
Logs
Evaluate
KPI
Trails
Analysis
Diagnosis
Connectors/
Validators
practical guidance for information security professionals and

other interested parties at all levels of the enterprise.
But all this theory of these standards is necessary to put in
practice furthermore integrating it within information security
management.
III.
AUTOMATIC INFORMATION SECURITY GOVERNANCE

USING BPMS
To accomplish the objectives previously set for the ISG, we

propose to automate those processes by means of Business
Process Management Systems (BPMS). This kind of systems
enables to align the processes of good ISG with the
information security management (ISO 27001/2013) and also
carry out the main tasks for the ISG: Direct, Evaluate and
Monitor. In order to do that, we propose to integrate together
the processes already established for the Information Security
Management and the processes for ISG. Therefore the
following items must be defined in those systems:
The organizational structure which governs the
information security in which information security
management must be integrated.
The business processes of ISG which has to be
integrated with the management processes in such a
way which enables to carry out the governances task
from the task in the information security management.
The business rules established by the direction that
have to be included in the business processes of the IS
Governance.
All of that enables to reach a level of maturity in the IS
management within organization which rise up to maturity
level 4 Qualitatively Controlled proposed by ISO 21827:2008,
moreover it enables to establish measurable quality goals
objectively managing performance of the IS.
Report
IT Business Process Management
Figure 1. Security Governance framework

The most important international standards related to ISG
have been established in the publications of S. H. von Solms
and R. von Solms [3], the recent ISO/IEC 27014:2013 [5] and
COBIT 5 for Security Information [6].
S.H. von Solms and Rossouw von Solms [7][8][9] have
published a wide number of articles related to ISG, but from a
theoretical point of view. In their book Information Security
Governance [4], they established a specific description of ISG.
Also, ISO/IEC 27014:2013 standard established that ISG is a
system by which an organization's information security
activities are directed and controlled and COBIT 5 provides a
framework that helps enterprises in achieving their objectives
for the governance and management of enterprise IT in a
holistic manner. COBIT 5 for Information Security is
integrated on the COBIT 5 framework. It focusses on
information security and provides more detailed and more
Nowadays, Business Process Management (BPM) has

become a cutting-edge field in IT arena. BPM [10] consists of
a strategy to administrate and improve the operational aspects
of businesses by means of a cycle encompassed by the
following stages: modelling, enactment, and evaluation. It
constitutes a methodology of good practices within a
technological solution. Currently, Business Process
Management Systems (BPMS) constitute a set of services and
tools that make easy the management of business processes.
Here, the management is considered as: analysis, definition,
execution, simulation, monitoring, and control of processes.
Furthermore, these systems enable the human interaction with
processes by web forms providing mechanisms to enact
automatic tasks even they can be integrated with third-external
applications.
In the next section a case study which shows how to carry out
the integration of ISG with processes for the identity
management of an entity engaged in development of projects
of R&D.
123
JNIC2015
IV.
defined and structured. These two processes are shown in Fig.

6-8 at the Appendices.
CASE STUDY
In this case study we show how to automate the ISG by

means of a BPMS particularly BonitaSoft environment [11].
The case study focuses on an entity which needs to implement
an adequate identity management procedure to accomplish
with current regulations such as article 93.3 from RD
1720/2007 from Spanish Government: When the
authentication mechanism is based on password must have a
procedure to assign, distribute and to store which guarantees
the confidentiality and the integrity. Furthermore, ISO/IEC
27001:2013 standard requires the definition of a control about
the rights access revocation and reassignment at procedure
A.9.2.6. These business goals enable ISG to ensure the
achievement of maturity level 4 maturity according with the
required at ISO/IEC 21827:2008.
The two main drawbacks have been identified are: firstly it
is the time of registration process since it is too long; secondly
passwords have been chosen by the users are usually so weak,
up to the point that in several occasions privacy and
confidentially has been compromised. All processes to support
the tasks for the identity management at the entity have been
carried out manually without monitoring mechanisms. In order
to improve those processes the entity has proposed to automate
the identity management by using a BPMS. Therefore the goals
of this project are the following:
1. The compliance of the particular policies (95% of total
passwords comply the established rules) and ISO/IEC
27001:2013 by means of the implementation and
deployment of the corresponding processes for ISG in a
BPMS.
2. Once deployed must be carried out simulations to check
the compliance of the following SMART (Specific,
Measurable, Achievable Relevant and Time-targeted)
objectives [12] proposed by the ISG:
a. Current user registration process takes at least 3 days
from user/password is requested until is received. Users
(researchers, administration staff, and third parties) by
the time they are contracted, they are added to the
Human Resources (HR) database which contains all the
users. On the other hand, there is a LDAP database in
the Communications Administration Service which
contains all users used by other applications. The entity
pursues to improve the time of user/password
assignment in 60% from the submission until reception.
b. The relation of users that exists daily in HR and LDAP
database is 1.0 and all the users in LDAP database are
in the HR database.
The entity has identified various critical assets in form of
groups and roles of people who take part in and the processes
that are involved such as shown in Fig. 2. The processes to
registration, assignment, and revoke user/passwords are well
Project R+D
GROUPS
Information
Security
Govern
Management Team
of Information
Security
Human
Resources
Staff
ROLES
Bussiness
Manager
Establish policies
System
Administrator
Register new Doctors

and Nurses*
Administrative
staff
Researcher
Register user in HR
database
Ask for registration in

LDAP
Modiy user
in HR database
Modiy user
information
*Previously must be registered in

LDAP
Monitor KPIs
Register users leaving
Get reports
Modiy user
information
Role
Group
Business
Process
Legend
Figure 2. Roles, groups and business processes of the entity.

The ISG has directed these requirements by means of:
Defining a set of metrics (Key Performance
Indicators, hereinafter KPI).
Proposing a set of particular policies.
Requesting reports to see the compliance of the
established metrics.
A. Establishment of KPIs
The KPIs establishment requires a previous work for the ISG
that enables the metrics how, what, and when must be defined.
In this case, we propose to use a template such as proposed in
ISO/IEC 27004:2009 [13] where the most relevant information
about the metrics can be established. Templates are a formal,
organised and systematic way to define a metrics since the
most relevant information is established in that template such
as controls to be carried out or the decision criteria has to be
applied. An example metrics definition looks like as following
Table 1, where a KPI is defined to measure the password
quality in the registration process for the entity.
Once the KPIs are defined, the ISG has to introduce that
information in the systems by launching the Direct ISG
process.
B. Direct ISG process
In Figure 7, the business process shows the control-flow
which is composed of two sub-processes:
1. A manual process that enables the ISG two options: to
establish a new policy and to evaluate a metrics.
2. An automatic process where metrics (KPI) are
collected and reported monthly.
The entity needs to establish a policy to check possible
discrepancies between HR and LDAP databases. Firstly, in
order to define the policy the role in charge, login at the system
and automatically provides the available options: Register a
124
JNIC2015
new policy or Check a KPI. In this case, a specific policy

wants to be established and a web form is given to establish the
policy such as shown in Fig. 8. The form is prepared to pick up
all the parameters required in the control. Once Send button
is clicked on all those values are stated in a database of
policies. This database is used as the basis to check the
decision criteria of compliance or non-compliance during the
registration process.
Table 1: Example of KPI formalization
KPI
Name
LDAP and HR database discrepancies
ID
KPI-003
Purpose
To assess the quality of the authorized users
Goal
Check whether users registration process in the

organization is conform to Control Objective A.9.2.6 in
ISO 27001:2013
Measurement Specification
Objects
of
Measurement
1. LDAP database
2. HR database
Attributes
1.
2.
3.
4.
FileWriter writer;
Method
1. Check for each entry in LDAP database whether it is

contained in HR database.
2. Check for each entry in HR database whether it is
contained in LDAP database.
1. Integer value
2. Integer value
Scale type
1. Cardinal and text.

2. Cardinal and text.
Measure unit
Amount of users and identifiers of users.
On demand of ISG team.
File file = new File("LogregisterTimes.log");
1. Registration in LDAP
2. Registration in HR
Scale
Reporting
Frequency
Long end = System.currentTimeMillis();
Basic measures
1. Objective measure
2. Objective measure
Daily
C. Monitor process
Monitoring of KPI implies to include an imperceptible piece
of software (BonitaSoft connectors) in the processes that
allows collecting information during the execution of
processes. For instance, regarding the time of registration of a
new, two timestamps are logged: the first check-point is
released when a registration process is initiated, and the second
check-point is released when the user has received a response
from Human Resource (HR) Department and LDAP. This
information is dumped in a database prepared for KPIs. On the
other hand, regarding the quality of passwords a validation
script is prepared to be performed through all users
registration. An example of Groovy script is shown in the Fig.
3. This piece of script shows a mechanism to write the log
registration time.
Number of users in LDAP database

Number of users in HR database
Id. of users that are not in LDAP database
Id. of users that are not in HR database
Measurement type
Analysis
Frequency
writer = new FileWriter(file, false);

Long second = (end-start) / 1000;
writer.write(segundos.toString()+"\n");
writer.close();
Figure 3. Example of Groovy script
Another script enables to count the number of noncompliance against the compliance and stated this value
in the database of KPIs. The other KPIs are developed in
the same way, that is by means of Groovy scripts where
timestamps are stated and queries to database are needed
to check the required time of the registration process.
Indicator Specification and Reporting

Description
a) Conformity Ratio
b) List of non-authorized users.
Analytical
model
a) Divide the total number of users in LDAP database

by total users in HR.
b) Select the users that are in LDAP database but not
in HR database.
Incdicator
Interpretation
a) Resulting ratio should be 1.0 to meet the control

objective satisfactory
b) List should be empty for meeting the control
objective satisfactory
Reporting
Format
A dashboard with charts where the amount of users

registered in each database are represented and the list
of id. of users that are in a LDAP database but not in
HR database.
Reporting Client
ISG Team
Collecting
Frequency
Each registration user
D. Evaluate process
The evaluation of KPIs can be carried out in two directions:
manually and automatically. Manually by means of the options
provided to the ISG within Direct process or a monthly report
is generated. As a result of the monitoring of processes a
dashboard can be presented to the governance such as shown in
Fig. 4. In the bar chart we can observe the number of users
registered in LDAP (blue colour) and HR (yellow colour)
database. In this example we can observe a non-compliance
example which a discrepancy is shown due to one user that is
in HR database but is not registered in LDAP database. In that
case the chart is showing. Therefore, the ISG can peek the
compliance of policies in seconds at real-time.
125
JNIC2015

KPI: LDAP and HR database discrepancies
[8]
Ratio = 0.91
[9]
Ratio = 0.91
[10]
[11]
[12]
[13]
LDAP
HR
The next users are not in LDAP database:

user28
The next user are not in HR database:
user35
user42
Figure 4. Example of dashboard.

V. CONCLUSIONS AND FUTURE WORK
In any organization the importance of ISG is emerging as a
key factor in the assurance and protection of information. To
build on developments of information security practices,
research in effective governance processes that can be aligned
with these practices has been undertaken.
BPMS offers a framework which helps to assess and
implement this ISG component of information security. It was
analysed and applied to the identity management of users/roles
for the ISG/ISM in the development of R&D Projects in a
Research Group of a Spanish Foundation. This implementation
provides a framework of different processes to perform the
information security governance (evaluate, direct, monitor, and
communicate). These processes show the adequate integration
between governance and management of information security.
As future work, we propose to expand the scenarios for
ISG/ISM in order to achieve the same goals but collaborating
several enterprises or organizations
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
INCIBE,
Available
at:
https://www.osi.es/gl/actualidad/avisos/2011/10/sony-bloquea-93000cuentas-de-su-playstation-network, 2015.
SIGMA DATA SECURITY CONSULTING S.L., Estudio sobre el
cumplimiento de la LOPD por la PYME Espaola, 2010.
ISO/IEC 27001:2013, - Information security management.
Rossouw von Solms, S.H. von Solms, Information Security Governance.
Springer, 2009.
ISO/IEC 27014:2013, Information technology Security techniques
Governance of information security.
COBIT 5 for security information. ISACA 2012
Jacques Coertze, Rossouw von Solms: A software gateway to affordable
and effective Information Security Governance in SMMEs. ISSA 1-8,
2013.
126
Rahul Rastogi, Rossouw von Solms: Information Security Governance:

A Re-Definition. IICIS 2004: 223-236, 2003
Rossouw von Solms, S.H. (Basie) von Solms: Information Security
Governance: A model based on the DirectControl Cycle. Computers &
Security 25: 408412 2006.
Howard Smith and Peter Fingar. Business Process Management (BPM):
The Third Wave. Meghan-Kiffer Press.
Bonita Soft, Available at: http://www.bonitasoft.com, 2015.
Business Motivation Model v1.1 OMG 2010
ISO/IEC 27004:2009, Information technology. Security techniques.
Information security management Measurement.
JNIC2015
APPENDICES
Figure 5. Registration process in the entity.
Figure 6. Log process of registration, modification and unregister of a user.
Figure 7. Direct Process for the ISG.
127
JNIC2015
Figure 8. Example of web form to establish a password policy.
128
JNIC2015
Evolving from a static toward a proactive and

dynamic risk-based defense strategy
Pilar Holgado , Manuel Gil Perez , Gregorio Martnez Perez , and Vctor A. Villagra
Departamento de Ingeniera Telematica, Universidad Politecnica de Madrid, 28040 Madrid, Spain

Departamento de Ingeniera de la Informacion y las Comunicaciones, University of Murcia, 30071 Murcia, Spain
Email: pilarholgado@dit.upm.es, mgilperez@um.es, gregorio@um.es, villagra@dit.upm.es
AbstractThe automatic prevention, detection, and reaction

for intrusion management has been a key issue for years, focusing
on the use of IDS-based approaches. In addition, dynamicity and
the changing nature of the technology and threats have led to
consider other approaches. In this paper, we present two R&D
projects whose purposes are addressing the above shortcomings.
First, we present the RECLAMO project, where an architecture
for an Automated Intrusion Response System is proposed to
divert a given attack to a honeynet, dynamically built based
on the attack information. Secondly, we also describe an ongoing
R&D project, called DHARMA, where an efficient Dynamic Risk
Assessment and Management is proposed to measure the risk
level on the organizations assets at real time, taking the required
actions as a response from a proactive defense model.
I. I NTRODUCTION
Automatic prevention, detection and reaction systems for
intrusion management is a key topic in the last few years [1].
Yet, most of the solutions have a narrow scope and certain
difficulties and limitations when dealing with large scale and
distributed attacks like coordinated spam, phishing attacks or
DDoS [2]. To this end, concepts like autonomic system, trust
and reputation management, collaborative intrusion detection
and prevention systems, virtualized honeynets, and semantic
web should be part of novel IDS/IPS systems.
Despite the progress in intrusion management, dynamicity
and heterogeneity should consider other alternatives that take
into account input from a large pool of heterogeneous sensors
and contextual changes in the organization, beyond traditional
network attacks. In this context, new dynamic risk assessment
and management processes have emerged to provide an answer
to this shortcoming, allowing the current solutions to acquire a
dynamic assessment of the risk of the organizational assets and
the continuous evolution of threats. A dynamic risk assessment
and management allow updating the risk level on the assets of
an organization at real time, as well as dealing with dynamicity
and the changing nature of the technology and threats.
attack, in order to obtain as much information as possible from

each [3], [4]. RECLAMO is aimed at designing and creating
an advanced Automated Intrusion Response System (AIRS) to
enhance the current attack detection and reaction proposals.
Self-protection is the key concept driving the components of
RECLAMO, providing a way of inferring the most appropriate
response for a given intrusion, taking into account not just the
intrusion, but also other related parameters, such as the context
and the confidence on the network sources. This information
is evaluated with a set of security metrics represented in a
formally defined behavior specification language, in order to
reason and to infer the most appropriate response.
As stated before, dynamicity and heterogeneity is key for
making automated management of intrusions a reality. As a
second contribution, we propose an efficient Dynamic Risk
Assessment and Management (DRAM), which is part of a
project called DHARMA (Dynamic Heterogeneous threAts
Risk Management and Assessment) [5]. This is a multilevel
architecture with a large number of heterogeneous sensors
capturing changes in the organization context. The DHARMA
framework enables to deploy specific sensors, integrating their
information in a DRAM engine that will provide updated
information on the risk levels to allow a quick reaction and
minimizing the exposure time to potential risky situations for
the organization. As a possible reaction of the DRAM is taking
into account the AIRS proposed in RECLAMO.
B. Organization of the paper
Section II presents the novel automated response system to
attacks developed in the RECLAMO project, where a special
emphasis is placed upon deception responses according to the
dynamic honeynets generated on virtualized platforms. We
describe in Section III a framework for achieving an efficient
DRAM, which is the main aim of an ongoing project called
DHARMA. Finally, Section IV summarizes our contributions.
II. V IRTUAL HONEYNETS WHERE DIVERTING ATTACKS
A. Our contributions
As a first contribution, we propose an approach to intrusion
response, building and deploying honeynets where the attacks
will be diverted. This is a result of the RECLAMO (Virtual and
Collaborative Honeynets based on Trust Management and Autonomous Systems applied to Intrusion Management) project,
where honeynets are created ad-hoc and optimized for each
The main objective of RECLAMO [4] is the application

of novel approaches for reacting to attacks, by means of
defining, developing, and validating an intelligent AIRS able
to conduct new and advanced reactions [6]. A special focus is
taken on the so-called deception-based responses: diverting
attacks to dynamically ad-hoc generated honeynets for being
129
JNIC2015
adequately confined to mitigate them and learn from them.

Thus, an intrusion is analyzed in real time by using a model
of intrusions, responses, and security metrics that are formally
defined with knowledge and behavior definition languages.
Fig. 1 illustrates the main functional blocks of RECLAMO,
which are described next in the following subsections.
Autonomous
systems
Collaborative intrusion
detection networks
Ontologies and formal

behavior definition
languages
Self-protecting
systems
Virtualization of
reactive networks
Multi-step
attacks
Trust and reputation

management
Fig. 1. Main functional blocks proposed in the RECLAMO project
The components belonging to each block defined in Fig. 1

are included within an envisaged architecture for RECLAMO,
which are depicted in Fig. 2.
Ontology
Evaluation &
Learning
formatted alerts
Network and
System Context
REASONER
IRSA
context
CIDNA
Trust &
Reputation
Metrics
Parser
IDS
alerts
..
IDS
Preventive
Passive
Active
responses
CIDNB
...
CIDNX
Other
CIDNs
alerts &
attacks
Virtual
Honeynets
Deployment
Fig. 2. System architecture of RECLAMO
As seen, concepts like autonomous system, ontologies, trust

and reputation management, collaborative intrusion detection
and prevention networks, self-protection as well as virtualized
honeynets are clearly identified in Fig. 2. All of these concepts
are considered as a key part of the novel automated response
system to attacks proposed in RECLAMO. It is worth pointing
out that all the related software of RECLAMO, regarding the
components shown in Fig. 2, is publicly available at [4].
A. Autonomous systems applied to intrusion management
Autonomous computing systems are systems capable of
managing themselves and dynamically adapting to changes,
according to business rules and the objectives given by the
system administrators. An autonomous computing system, or
self-management system, has the following functions [7].
Self-configuration. The system is able to immediately
adapt to the deployment of new components or changes
in the environment and configure itself automatically,
without human intervention.
Self-healing. The system is able to detect when, where,

and why there are faults in the system, and carry out the
appropriate fault-correction actions.
Self-protection. The system detects hostile or intrusive
behavior, such as unauthorized access attempts, virus, and
denial of service attacks, and implements the appropriate
actions to protect itself from them or cascading failures.
As shown in the previous definitions, the main feature of an
autonomous system is the ability to specify their own behavior,
in order to manage and protect itself and dynamically adapt
to different conditions. The concept of self-protection, which
the most important of any autonomous system, is the main
component of the RECLAMO system, providing the ability
to infer the most appropriate response for a given intrusion.
This takes into account not just the intrusion, but also many
other related parameters, such as the context or the trust and
reputation of the network source. This autonomous system
uses formally defined information models with ontologies for
combining the intrusion information. Furthermore, it considers
additional concepts such as self-evaluation learned parameters,
trust and reputation of the different involved elements, and
information coming from collaborative IDS/IPS systems in the
same or different administrative domains.
There are several ontology languages, such as Ontolingua,
KIF, OCML, OKBC, and F-Login, before the semantic web;
and RDF, RDFS, DAML+OIL, OWL, and OWL2. The main
ontology languages used in semantic web to formally describe
information definitions are OWL and OWL2 [8]. Moreover,
OWL is a knowledge definition language that structures the
information into classes and properties, with hierarchies, and
range and domain restrictions. However, the ability of OWL
to define behavior into defined information is limited, so it is
necessary to use additional rule languages like SWRL. This is
the most widely used rule definition language, which extends
the set of the OWL axioms by defining logical restrictions [9].
In RECLAMO, we use OWL and a set of SWRL rules.
Ontologies are the main semantic information model used
within the scope of Semantic Web, Knowledge Management,
and Artificial Intelligence. It formally represents a set of
concepts, their meaning, and interrelation between them [10].
Initially, the propose of ontologies was to allow different and
heterogeneous agents to share and reuse knowledge.
One of the main advantages when using ontologies is the
formalization of the information semantics. This is important
when dealing with heterogeneous information sources that can
represent the same resource with different format and syntax.
Another great advantage of using ontologies are the tools
to define information and behavior, improving the usage of
ontologies and rule languages in several environments.
As a first task, it is required to design a formal definition
about vulnerabilities, attacks, and response actions based on
different taxonomies. These ontologies define a subset of
vulnerabilities, attacks, and responses and allow specifying
the behavior of the autonomous system when an intrusion
is detected. So that, the system can reason and infer new
knowledge from different inputs.
130
Evaluated cost
Network IRS
Cost-sensitive
IDAM&IRS
Proactive
Stakhanovas
EMERALD
FAIR
Adaptive
CSM
The AIRS is able to understand heterogeneous alerts and

to know whether they are referring to the same intrusion
or not. Nowadays, there are several data format standards
for alerts representation, such as IDMEF (Intrusion Detection
Message Exchange Format) [11]. This is defined in XML to
represent, exchange, and share the information about intrusion
detection, but with no additional knowledge representation.
IDMEF can be useful for the AIRS in order to correlate alert
information with other additional data, such as network context
and rules. RECLAMO uses ontology mapping technologies,
such as D2RQ [12], which allows mapping between relational
databases and OWL/RDFS ontologies.
ADEPTS
AAIRS
JNIC2015
Semantic coherence
TABLE I
F UNCTIONALITIES OF EXISTING AIRS
B. Autonomous intrusion response systems: Self-protecting

AIRSs are security technologies to trigger dynamic reaction
against detected intrusions. The system infers the mot suitable
response and triggers it automatically without participating an
administrator. The state of the art in AIRSs is not as mature
as with IDSs, although several systems have been proposed
in recent years: AAIRS, ADEPTS, EMERALD, CSM, FAIR,
and IDAM&IRS. For example, Stakhanova presented in [13] a
taxonomy of autonomous intrusion response systems, together
with a review of current trends in intrusion response research.
According to this paper, AIRSs can be classified in different
ways according to various features:
By ability to adjust: static and adaptive. The response
selection mechanism remains the same during the life
of the AIRS in static AIRSs. Adaptability is a powerful
feature that can automatically modify the chosen response
according to other external factors, like the previous
response effectiveness or changes in the environment.
By response selection mechanism: static, dynamic, and
cost-sensitive mapping. There is an increasing interest
in recent years in developing cost-sensitive models for
response selection. The primary objective of these models
is to ensure an adequate response without sacrificing the
normal system functionality. That is to say, the system
takes into account the complexity and cost of the reaction,
besides the impact of the intrusion.
By time of response: proactive and delayed. Proactivity
is the ability of the AIRS to react against an intrusion or
attack before it takes place. A reactive AIRS infers and
activates the reaction when the intrusion is detected.
By response cost model: static, static evaluated (S), and
dynamic evaluated cost (D). This refers to the evaluation
mechanism that the AIRS uses to get the response cost.
To achieve an optimal response in the shortest time, it is
required that the AIRS is adaptive, cost-sensitive mapping, and
proactive. But there is another feature, the semantic coherence,
that is not present in this taxonomy and it is especially crucial
in a heterogeneous intrusion detection environment.
In TABLE I, we show the features of some related AIRSs,
where only ADEPTS and the Stakhanovas IRS offer adaptive,
proactive, and cost-sensitive functionalities. However, none of
them provides mechanisms to archive semantic coherence. Due
to this, the AIRS proposed by RECLAMO supports semantic
coherence by using ontologies, formal behavior specification

languages, and reasoning mechanisms, as well as fulfilling the
rest of requirements. Moreover, our system includes a formal
mechanism to evaluate the cost of responses, giving feedback
to the system for improving responses in future attacks.
The use of ontologies and formal languages, so as to define
the behavior of the autonomous system, is essential to provide
AIRSs with the self-protection capability, and so fixing the
problem of semantic coherence. Due to its expressiveness and
flexibility, they also enable AIRSs to meet other requirements:
adaptability, proactivity, and response cost-sensitive.
Another key feature to take into account is the cooperation
capability: autonomous and cooperative. Network-based IRSs
are often built in such a cooperative way, because they provide
more effective responses than single and autonomous systems.
An example of it is EMERALD. Due to this, the RECLAMO
project follows the cooperative way.
Finally, the autonomous response system is combined with
other technologies, e.g, the correlation of the alerts, as well
as further information such as the trust and reputation of the
IDSs together with their network context [14]. Therefore, the
response system of RECLAMO is capable of detecting attacks
in a given organization, and reacting against them quickly in
an autonomous and optimal way, with no intervention from
network administrators. The reaction includes the inference of
the optimal response in a diagnosis phase, and the deployment
of that response in a reaction phase.
C. Collaborative intrusion detection systems
Collaborative intrusion detection systems (CIDS) emerged
in recent years to deal with detecting distributed attacks, where
pieces of evidence are gathered at different network locations
to be subsequently correlated. This distributed nature of attack
execution is due to the way in which attackers perform their
malicious practices, evolving toward a new mode of operation
more global and distributed. In case a collaborative strategy is
not used, alerts generated by the IDSs are viewed as isolated
incidents, with no relevance when analyzed separately [2].
Due to this, alerts should be treated as a whole from a more
global viewpoint for knowing the actual state of the network,
by detecting distributed attacks after deploying multiple IDS
instances among security domains. A partnership of all IDSs
131
JNIC2015
will form an overlay layer for sharing security data among

peers: alerts and incidents detected by each IDS individually.
This cooperative system is a Collaborative Intrusion Detection
Network (CIDN) that allows building a collective knowledge
base of isolated alerts within a given security domain [15],
whereas the union of several CIDNs shapes a Collaborative
Alert System (CAS) to detect attacks more distributed among
several security and/or administrative domains.
Where to place the pool of IDSs is a key point for sharing
alerts properly among them. A survey on how the IDSs can
be distributed is given in [2], which is focused on centralized,
decentralized, and distributed architectures. Instead, we think
that a partially-decentralized approach is the best placement
model to tackle the drawbacks implicit in the other. Partiallydecentralized schemes address the problems of having a single
point of failure and the lack of scalability, from centralized
approaches; and the overhead and management difficulty, from
decentralized and distributed schemes. A schematic example
of the system architecture of RECLAMO is shown in Fig. 3,
which is based on a partially-decentralized scheme.
CIDNY
CAS
Wise Committee
WCLA
IDS
alerts
..
IRSY
IDS
...
WCLY
...
..
IDS
IDS
alerts
IRSA
CIDNA
WCLX
Administrative
Domain 2
...
IDS
IRSX
CIDNX
alerts
..
Administrative
Domain 1
alerts &
attacks
IDS
Let us suppose that a given IDS j wants to share a new alert

with the rest of the CIDN members for correlation purposes.
This IDS sends the alert to the WC for being assessed before
its publication to the rest of IDSs. The WC members compute
the js reputation, Rep(j), to decide if the alert is a true
or false positive depending on that reputation score. To this
end, the WCL only queries recommendations to those IDSs
with similar detection skills than j; otherwise, the IDSs could
not know the satisfaction on the alerts detected by j. These
recommendations will be finally aggregated and shared by the
WCL with the rest of the WC members, where each W Ci will
assess its trust on j, TW Ci (j) [0, 1], as given in (1).
|IDS|
M
i,k Repi (k) Reck (j)
TW Ci (j) =
L
where |IDS| is the total number of IDSs in the CIDN;
defines an aggregation operation chosen by the administrator;
Repi (k) [0, 1] is the reputation of k from the perspective
of W Ci ; Reck (j) [0, 1] defines the recommendation value
gathered from k on j; 1 represents the pace at which W Ci
forgets recommendations; and i,k [0, 1] is the weight
that W Ci can deposit on the type of IDS that k represents.
For example, i,k may be divided into separate three weights
according to the ks group: i for NIDSs, i for HIDSs, and
i for the WCs NIDSs, with i + i + i = 1.
The recommendation element is a key factor to assess alert
satisfaction. The recommendation of IDS k on IDS j at a
given time t is computed by (2), taking into consideration the
previous recommendation values already computed by k.
(t)
(t1)
Reck (j) = k Reck
Fig. 3. Partially-decentralized scheme of a CAS
This partially-decentralized scheme is built with the help

of a pool of supernodes (or superpeers) that act as the heads
of their security domain, thereby shaping a Wise Committee
(WC), one per CIDN. They are in charge of assessing the
alerts generated by the IDSs before being finally shared with
the rest of the CIDNs IDSs (intra-domain knowledge base) or
other administrative domains at the CAS level (inter-domain
knowledge base) [16]. Sharing the internal knowledge base of
alerts of a CIDN with other CIDNs is carried out by the most
trustworthy IDS of the CIDN, called WC Leader (WCL).
D. Trust and reputation management
CIDSs assume that the IDSs cooperate each other honestly
to correlate security incidents: alerting when a threat occurs or
not alerting when the system is safe. However, honesty may
produce a misleading perception on the security state in case
the IDSs exhibit a malicious behavior, reporting bogus alerts to
provoke errors to other IDSs. Identifying malicious attitudes
can be achieved by using trust and reputation mechanisms,
with which to model the behavior of the IDSs [17].
(1)
k = 1,
k 6= i
(t)
(j) + (1 k ) Satk (j)
(2)
where k [0, 1] is the weight to previous recommendation

values and Satk (j) [0, 1] represents the satisfaction of IDS
k on the alert published by j, according to the configurations
declared by IDSs k and j in their bootstrapping phase. Satk (j)
may vary by several factors, depending on whether k has direct
or indirect evidences about the alerts published by j.
The configuration of both IDSs comes into play to determine
possible evidences in assessing alert satisfaction. First, if both
IDSs are deployed in the same network, the alert shared by j
would also have been produced by k, provided that the they are
implementing similar detection skills. In case k has produced
an alert to warn the same incident, the satisfaction of k on j
would be the highest according to the js reputation (from the
perspective of k) and the alert severity.
Secondly, when the two IDSs are deployed in the same
network, but with different configurations in detection, k has to
infer the detection skills that j used to produce the alert when
the former did not generate it. To this end, IDS k can base
its decision on the detection skills of other IDSs in its same
network and their attitude with respect to the alert produced
by j (indirect experience-based approach). Specifically, k can
follow a majority-based voting scheme, taking into account
132
JNIC2015
both the configurations implemented by the other IDSs that

detected or not the same incident than j, in comparison with
the configuration of k, and the reputation score of each.
Finally, when both IDSs are deployed in separate networks,
there is no actual obligation on k to alert about the incident
detected by j. Yet, it is possible that k had to detect it in case
a number of its neighbors in this same network did detect it. In
this case, IDS k should only compute the new recommendation
value of IDS j as defined in (2).
As final step to compute Rep(j), the reputation on IDS j is
computed by aggregating all partial trust values given by (1),
calculated by every W Ci . This aggregation process is carried
out by the WCL through computing (3).
Rep(j) =
|W C|
TW Ci,j
(3)
i=1
Depending on the js reputation score, denoted as Rep(j)

in (3), the alerts shared by j are finally published by the
WC to the rest of IDSs of the js CIDN. Furthermore, the
WCL will send these alerts to other WCLs of the CAS if the
alerts severity denotes a potential evidence of a distributed
attack, determined by the severity of such alerts. Information
sharing in a distributed environment requires another trust and
reputation mechanism aimed to work at an inter-domain level.
In this context, the WC that receives an alert from another
domain has to assess the reputation of the latter in order to
decide whether to accept or not the alert and share it with
its members. For this purpose, we adapt the application of a
well-known trust model such as PeerTrust [18].
PeerTrust is a reputation-based trust supporting framework
that includes a coherent adaptive trust model for quantifying
and comparing the trustworthiness of the entities according to
a transaction-based feedback system. Thus, it fits well for an
inter-domain reputation mechanism. PeerTrust introduces three
basic trust parameters and two adaptive factors in computing
trustworthiness of entities, as given by:
I()
T () =
X
i=1
S(, i) Cr(p(, i)) T F (, i) + CF ()
where and denote the normalized weight factors for

both the collective evaluation and community context factor,
respectively; I() represents the total number of transactions
performed by with other domains; S(, i) is the normalized
amount of satisfaction that receives from p(, i) in its i-th
transaction; Cr(p(, i)) denotes the credibility of the feedback
submitted by other domains; T F (, i) represents the adaptive
transaction context factor for the i-th transaction of ; and
CF () is the adaptive community context factor for .
E. Definition of security metrics and behavior of the system
Existing AIRSs make use of several fixed response metrics
to choose the action that the system must execute, such as
the ones used by AAIRS, ADEPTS, CSM, EMERALD, the
Stakhanovas IRS, FAIR, and IDAM&IRS. All the response
metrics allow the AIRS to choose the reaction that may trigger,
but they are fixed and cannot be dynamically chosen (i.e., the
AIRS always uses the same metric, regardless of the intrusion
context or the state of the system).
We defined in RECLAMO a pool of response metrics for
modeling and specifying the behavior of the AIRS [19]. The
knowledge included in the ontology allows inferring the most
appropriate response set for different events. Such metrics are
defined by using a formal language of behavior specification,
so the complete AIRS behavior is defined formally. Their
specification in a flexible and dynamic way requires the use
of a specific language able to express these metrics. We use
SWRL as a formal language to express them.
The following parameters have been identified as the most
relevant ones for inferring the optimum response: the intrusion
impact, the IDSs confidence, the importance of the affected
resources, the severity and cost of the response, and its success.
Regarding the relevance that the compromised resource has for
the organization, the AIRS assigns more or less weight to each
of these parameters. For example, consider that the affected
resource is a user workstation. The response cost may take
priority over its success rate. However, if the attacked resource
is a database server, the AIRS may give more importance to
the response severity and the response effectiveness than the
high cost of executing the response.
In order to choose the responses, three response metrics
have been taken into account in RECLAMO, which are next
presented. Each metric assigns a weight to the parameters in
a different way. Depending on the level of importance of the
resource, the system applies one metric or another.
1) Damage reduction metric: The purpose of this metric
is to strike a balance between the cost of the damage caused
by an unattended attack (the intrusion impact) and the cost
of deploying the response (the response impact). This metric
aims to avoid that the response has a greater negative effect
than can cause the attack on the resources of an organization
(e.g., loss of availability of several resources). The AIRS uses
this metric regardless of the component importance. Note that
this metric is equivalent to the one defined by Stakhanova.
The application of this metric infers the responses, whose
impact is lower than or equal to the product of the intrusion
impact and the IDS confidence, as defined in (4).
Impactintrusion Conf idenceIDS > Impactresponse (4)
Then, the AIRS discards the responses whose impact is

greater than the intrusion impact. Note that his metric depends
on three parameters: the intrusion impact, the IDS confidence,
and the response impact. The AIRS does not compute these
parameters at inference time. They correspond to the properties
of the defined ontology, and their values are input to the
response system which must have previously defined.
2) Minimum cost metric: The AIRS applies the minimum
cost metric when the affected component is not very relevant
for the organization. The purpose with this metric is thus to
minimize the response total cost, as given by (5), so that the
AIRS will trigger the execution of the lower cost response.
133
CostT response = Impactresponse + Costd response (5)
JNIC2015
The response total cost includes the response impact and

the response deployment cost. The former, Impactresponse ,
represents the cost that executing the response involves to
the organization, in terms of the damage that the response
action causes to the resources of the organization. The latter,
Costd response, represents the cost that the deployment of the
response involves to the organization, in terms of the required
resources (e.g., number of the needed routers or the number
of backups). The lower cost responses are usually the lower
complexity responses. Thus, if several responses have the same
cost, the AIRS will select the lower complexity response.
3) Highest severity and highest efficiency metric: When
the compromised resource is critical, the response system
uses the highest severity and efficiency metric, whose purpose
is to maximize the response severity and the success. This
metric depends on the results of the previous executions of the
specific response against a given similar intrusion, the severity
associated with the intrusion, and the severity of the response
itself. Thus, the purpose is to satisfy (6) and maximize (7).
RE |Severityresponse | > Severityintrusion
(6)
max (RE |Severityresponse |)
(7)
As shown in (6) and (7), the metric depends on:

Intrusion severity, Severityintrusion . The AIRS gets the
intrusion severity according to some of the predefined
equivalences between intrusion type and severity.
Response absolute severity, |Severityresponse |, whose
value is previously set by the system administrator.
Response efficiency, RE. It measures the success of the
previous response against an intrusion. Partial efficiency
of the response is calculated after each execution of it,
which is based on machine learning methods [20]. These
methods analyze all the data captured from the context
information (network and system context).
F. Virtualized honeynets as a response system
The reaction phase comes after the diagnosis is completed.
Classical reactions typically consist on deploying new firewall
rules, whereas most recent AIRSs also offer new possibilities
to react against attacks; for example, by creating honeynets.
These honeynets can be specifically adapted to the detected
attack. In this context, the RECLAMO project proposes a
reaction based on the configuration and automatic deployment
of honeynets, which are optimized and adapted to each attack
according to the specifications provided by the AIRS.
A honeynet is defined as a set of honeypot systems (servers,
routers, switches) prepared to be attacked, while monitoring
the attack simultaneously. A honeypot can have low- or highinteraction. As opposite to the low-interaction honeypots that
just emulate operating systems and services, high-interaction
honeypots provide real systems, application, and services to
lure attackers. A honeynet can consist of high-interaction or
low-interaction honeypots, or both of them. A honeynet creates
a highly controlled network, with which the administrators can
control and monitor all the activity that occurs inside it.
Given the complexity involved in launching a honeynet,

the virtualization techniques are an essential tool that greatly
facilitates its deployment and management. These tools can
create multiple logical systems with a single physical machine,
thereby drastically reducing the number of physical systems
required so as to create a honeynet. These honeynets are built
ad-hoc and optimized in order to get as much information as
possible from each attack. This dynamic honeynet generation
uses advanced virtualization techniques capable of generating
large scale heterogeneous honeynets.
Virtualization tools facilitate the definition of the honeynets,
including their topology, addresses, system type, deployment,
and monitoring. So, they hide the complexity of the underlying
virtualization platforms to the final system. Among these tools
available in the market, we can find VNX, VNUML, Netkit,
MLN, and vBET. In RECLAMO, we chose Honeyd and VNX
as the frameworks able to deploy low-interaction honeypots
and high-interaction honeypots [21]. VNX includes the ability
of deploying a virtual network scenario over cluster of servers,
improving the scalability of the solution and also allowing
the creation of very complex honeynets, even over distributed
cluster infrastructures [22].
There are several projects and initiatives that have made use
of virtualization as a basic tool with which to dynamically
create honeynets. One of the most advanced is Collapsar [23],
which combines a powerful distributed traffic capture system
with a server farm, where the interesting traffic is redirected
to dynamically create honeynets that process it.
The dynamic generation of the honeynets require a previous
characterization and parametrization of different honeynets.
The objective is to generate a large and flexible catalog of
honeynets for being used by the AIRS. Each of these honeynets
can be tuned at deployment time for its customization with the
aim of facing specific attacks. This is a key feature since it
provides flexibility to the system, which allows executing the
traditional scenarios with static honeynets as well as advanced
scenarios built for the autonomous system dynamically.
III. T OWARD THE DYNAMICITY FOR RISK ASSESSMENT
AND MANAGEMENT
The RECLAMO project presented in Section II is capable of

reacting to a given input (an intrusion), and getting additional
context and collaborative information with the aim of inferring
the most appropriate response. But this approach is static and
reactive: reacting when there is an intrusion and processing the
context information acquired in that given moment. Thus, the
architecture proposed in RECLAMO (Fig. 2) can be enhanced
with a dynamic and proactive approach, this being the main
objective of the DHARMA (Dynamic Heterogeneous threAts
Risk Management and Assessment) project [5].
DHARMA becomes possible to separate the concepts of
dynamic risk assessment and the consequences after assessing
that risk. This latter can be an automated response triggering,
like the one proposed in RECLAMO, or any other output, such
as dynamic risk visualization in a control panel, updating of
risk assessment methodologies or proactive actions.
134
JNIC2015
The major difference between these projects is that the

main input in RECLAMO is the intrusion, being the context
processed just to enrich the inference process for it, whereas
the intrusion in DHARMA is just another input, and context
changes play a principal role for a dynamic risk assessment.
So, there will be a constant evaluation of the heterogeneous
context parameters in order to assess any change in the risk
level, as stated by the organization. The main components of
DHARMA are detailed in the next sections, which are defined
within the envisaged architecture shown in Fig. 4.
Physical security sensors
Smart Cities sensors
(updates)
Countermeasures
DDRA Inputs
Human and social sensors
Risk Treatment layer
Data processing and data mining

Threats and
Vulnerabilities Detection
Evaluation &
Learning
Context-aware
Security and Privacy
Trust and Sensitivity

Management
Proactive Defence
Rules
HMM
DDRA Engine
Ontology
Risk Assessment
Metrics
DDRA controller
Collaborative Risk Management
Processing and Analysis layer
Specific interfaces for specific sensors
Sensor reconfiguration
Inputs collection generic interface
Input layer
Obligation enforcement
Organization
policies
ICT security sensors
External
External
External
DDRAs
External
DDRAs
DDRAs
DDRAs
Risk treatment interface
RECLAMO
AIRS
Social Image
Promotion
Other dynamic
response mechanisms
Real-time Risk
Visualization
PILAR
Sensor reconfiguration
Obligation enforcement
Fig. 4. Technical architecture of DHARMA proposal
A. Heterogeneous information monitoring mechanisms

The inclusion of new information from different sources is a
key feature for the risk analysis process, which must take into
account the parameters involved in this process as well as those
already used in traditional risk analysis such as assets, threats,
vulnerabilities, and countermeasures. These new sources are
grouped into four main set of sensors: physical security, ICT
security, Smart Cities, and human and social sensors. All these
sensors are represented in the top layer of Fig. 4.
The management of the heterogeneous information allows
correlating and processing information from multiple and
distributed sources, through data mining techniques, in order
to detect any alteration in the monitored parameters as well as
find out malicious attempts on assets. As a consequence, the
dynamic risk assessment controller will capable of taking the
required actions as a response from a proactive defense model,
by using algorithms of machine learning such as neuronal
networks and Hidden Markov Models.
Sharing information between sensors and the (distributed)
dynamic risk assessment controller also requires the definition
of trust and sensitivity management models, similarly to the
one presented in Section II-D. They have to quantify the actual
threat level on the assets, according to the trustworthiness
of the subjects accessing to the assets (threat grows up as
the subjects trust score decreases) and the sensitivity of the
resources, e.g., personal data, contained in the asset (threat
grows up as the assets sensitivity level increases).
B. Distributed and dynamic risk assessment and management

Risk assessment and management (RA/RM) is a common
and extended practice used in the most of large corporations to
identify, analyze, and either accept or apply countermeasures
to mitigate the risk expected likelihood of unfortunate events
and the impact of these events on the assets of the organization.
A lot of mature methodologies, techniques, standards, and
have been specified, developed, and implemented till the date,
such as MAGERIT, ISO 27005:2011, OCTAVE, CRAMM,
EBIOS, NIST SP800-30, COBRA, and RA2, among others.
They have been widely evaluated and tested using well defined
metrics as well as benchmarking schemes.
But now, with the current dynamicity and heterogeneity of
the security threats area, there is a large need for dynamic risk
assessment and management processes that allow systems to
update the level of risk at real time, as well as dealing with
the dynamicity and ever changing nature of the technology
and threats. The traditional approaches of risk management
and assessment do not cover this need because it is not a
continuous process, but the assessment process is repeated
regularly over discrete and large time intervals. Although these
intervals were smaller, they leave a window of opportunity
where assets could be affected.
A new approach, known as Dynamic Risk Assessment and
Management (DRA/DRM), seems to be the solution to the
new need and its aim is to continuously update the risk of any
changes happening in the organization: changes in threats, new
vulnerabilities, new countermeasures or modification of assets.
In the scope of dynamic frameworks for risk assessment and
management, some efforts have been done, but none of the
proposed work is sufficiently mature, and the usage of new
sensors of different nature (such as environmental sensors) as
inputs to the risk analysis could improve the accuracy and
efficiency of the management process.
The DHARMA architecture, depicted in Fig. 4, relies on
the design and integration on different heterogeneous sensors
that continuously monitor different sources that might trigger
a potential threat to the organization. All these sensors are
not limited to the traditional ICT security incidents, but also
to many other sources: environmental sensor (threats coming
from changes in temperature, humidity, etc.), physical sensor
(threats coming from physical presence and/or recognition),
vulnerabilities sensor (threats coming from new vulnerabilities
that might affect the organization assets), and also sensors
trying to evaluate potential threats to the organization raised
from the social networks activity (social networks sensor) or
even from the own organization employees (human resources
sensor that tries to evaluate the level of labor disputes and
conflicts in the organizations). The continuous monitoring of
these highly dynamic context parameters is the key for an
accurate dynamic risk assessment methodology.
C. Deployment and enforcement of dynamic countermeasures
The results of the risk analysis process can be treated
from different approaches: passive, preventive or proactive,
reactive, and collaborative. The deployment and enforcement
135
JNIC2015
of response actions, when needed, requires the definition of

mechanisms with which to treat the computed impact and
risk. They can incorporate the definition of interfaces to the
existing AIRSs, such as the one presented in Section II;
the deployment of social image promotion actions to revert
possible harms in the market on the organizations corporate
image after being victim of a threat; and certain mechanisms
enabling the reconfiguration of sensors as needed to maximize
the information gain [24], depending on the feedback provided
by the distributed dynamic risk assessment controller. In the
former case, the deployment of dynamic countermeasures
as response actions in protecting assets allows inferring the
optimum reaction as a defense strategy, diverting the attack to
a honeynet where to mitigate it and learn from it.
The deployment and enforcement of countermeasures, with
the aim of protecting the assets according to the current risk
level, is shown in the lower layer of Fig. 4.
IV. C ONCLUSION
We have reviewed throughout this paper the main objectives
and relevant topics of two R&D projects. First, the RECLAMO
project deals with important key technologies like autonomous
systems and trust and reputation management, and combine
them in a single solution to provide an automated response
system to attacks. As a promising response for RECLAMO,
we developed the dynamic generation and deployment of
honeynets where the attacks are diverted for isolation.
The proposal of RECLAMO has been extended to manage
the current dynamicity and heterogeneity present in current
systems, due to the large number of heterogeneous sensors,
reporting threats who exploit vulnerabilities on the assets, and
contextual changes in the organization. This new challenge is
being addressed in an ongoing R&D project called DHARMA.
Its main goal is to provide assistance for dynamic assessment
and management of the risk, and dynamically reassessed it
in real time in order to prevent, react, and mitigate potential
threats on sensitive assets of an organization.
ACKNOWLEDGMENT
This work has been partially funded with the support
from the Spanish MICINN (project RECLAMO, Virtual
and Collaborative Honeynets based on Trust Management
and Autonomous Systems applied to Intrusion Management,
with codes TIN2011-28287-C02-01 and TIN2011-28287-C0202, and project DHARMA, Dynamic Heterogeneous Threats
Risk Management and Assessment, with codes TIN201459023-C2-1-R and TIN2014-59023-C2-2-R) and the European
Commission (FEDER/ERDF). Thanks also to the Funding
Program for Research Groups of Excellence granted by the
Seneca Foundation with code 04552/GERM/06.
R EFERENCES
[1] R. Zuech, T. M. Khoshgoftaar, and R. Wald, Intrusion detection and
big heterogeneous data: A survey, Journal of Big Data, vol. 2, no. 1,
pp. 141, Dec. 2015.
[2] E. Vasilomanolakis, S. Karuppayah, M. Muhlhauser, and M. Fischer,
Taxonomy and survey of collaborative intrusion detection, ACM
Computing Surveys, vol. 47, no. 4, pp. 55:155:33, Jun. 2015.
[3] M. Gil Perez, V. Mateos Lanchas, D. Fernandez Cambronero, G.

Martnez Perez, and V. A. Villagra, RECLAMO: Virtual and collaborative honeynets based on trust management and autonomous systems
applied to intrusion management, in Proceedings of the 7th International Conference on Complex, Intelligent, and Software Intensive
Systems, Jul. 2013, pp. 219227.
[4] Universidad Politecnica de Madrid and Universidad de Murcia, Web
site of the RECLAMO project, [Online] http://reclamo.inf.um.es.
[5] Universidad Politecnica de Madrid and Universidad de Murcia, Web
site of the DHARMA project, [Online] http://dharma.inf.um.es.
[6] V. A. Villagra Gonzalez and G. Martnez Perez, RECLAMO: Red
de sistemas de engano virtuales y colaborativos basados en sistemas
autonomos de respuesta a intrusiones y modelos de confianza, Revista
SiC: Ciberseguridad, Seguridad de la Informacion y Privacidad, no.
111, pp. 6465, Sep. 2014.
[7] F. T. M. Bazier, J. O. Kephart, H. Van Dyke Parunak, and M. N. Huhns,
Agents and service-oriented computing for autonomic computing,
IEEE Internet Computing, vol. 13, no. 3, pp. 8287, Jun. 2009.
[8] W3C Recommendation, OWL 2 Web ontology language document
overview (2nd edition), Dec. 2012.
[9] W3C Member Submission, SWRL: A semantic web rule language
combining OWL and RuleML, May 2004.
[10] S. Staab and R. Studer, Handbook on ontologies. Springer Science &
Business Media, 2013.
[11] H. Debar, D. A. Curry, and B. S. Feinstein, The intrusion detection
message exchange format (IDMEF), IETF RFC 4765, Mar. 2007.
[12] R. Cyganiak, C. Bizer, J. Garbers, O. Maresch, and C. Becker, The
D2RQ mapping language, [Online] http://d2rq.org/d2rq-language.
[13] N. Stakhanova, S. Basu, and J. Wong, A taxonomy of intrusion response
systems, International Journal of Information and Computer Security,
vol. 1, no. 1/2, pp. 169184, Feb. 2007.
[14] J. J. Martnez Molina, M. A. Hernandez Ruz, M. Gil Perez, G. Martnez
Perez, and A. F. Gomez Skarmeta, Event-driven architecture based on
patterns for detecting complex attacks, International Journal of Critical
Computer-Based Systems, vol. 1, no. 4, pp. 283309, Nov. 2010.
[15] C. Fung, Design and management of collaborative intrusion detection
networks, Ph.D. dissertation, University of Waterloo, Canada, 2013.
[16] M. Gil Perez, F. Gomez Marmol, G. Martnez Perez, and A. F. Skarmeta
Gomez, RepCIDN: A reputation-based collaborative intrusion detection
network to lessen the impact of malicious alarms, Journal of Network
and Systems Management, vol. 21, no. 1, pp. 128167, Mar. 2013.
[17] M. Gil Perez, F. Gomez Marmol, G. Martnez Perez, and A. F. Skarmeta
Gomez, Building a reputation-based bootstrapping mechanism for
newcomers in collaborative alert systems, Journal of Computer and
System Sciences, vol. 80, no. 3, pp. 571590, May 2014.
[18] L. Xiong and L. Liu, PeerTrust: Supporting reputation-based trust for
peer-to-peer electronic communities, IEEE Transactions on Knowledge
and Data Engineering, vol. 16, pp. 843857, Jul. 2004.
[19] V. Mateos Lanchas, V. A. Villagra, F. Romero, and J. Berrocal, Definition of response metrics for an ontology-based automated intrusion
response systems, Computers & Electrical Engineering, vol. 38, no. 5,
pp. 11021114, Sep. 2012.
[20] P. Holgado, V. A. Villagra, and V. Mateos Lanchas, Redes neuronales
aplicadas al proceso de aprendizaje de un sistema de respuestas a
intrusiones automatico, in XI Jornadas de Ingeniera Telematica, Oct.
2013, pp. 419426.
[21] F. Wenjun, D. Fernandez, and V. Villagra, Tecnology independent
honeynet description language, in Proceedings of the 3rd International
Conference on Model-Driven Engineering and Software Development,
Feb. 2015, pp. 303311.
[22] F. Galan, D. Fernandez, J. E. Lopez de Vergara, and R. Casellas,
Using a model-driven architecture for technology-independent scenario
configuration in networking testbeds, IEEE Communications Magazine,
vol. 48, no. 12, pp. 132141, Dec. 2010.
[23] X. Jiang and D. Xu, Collapsar: A VM-based architecture for network
attack detention center, in Proceedings of the 13th USENIX Security
Symposium, Aug. 2004, pp. 1528.
[24] M. Gil Perez, J. E. Tapiador, J. A. Clark, G. Martnez Perez, and
A. F. Skarmeta Gomez, Trustworthy placements: Improving quality
and resilience in collaborative attack detection, Computer Networks,
vol. 58, pp. 7086, Jan. 2014.
136
JNIC2015

1
How to find an image despite it has been modified

Diego Garca Ordas, Laura Fernandez Robles, Mara Teresa Garca-Ordas, Oscar Garca-Olalla,
Enrique Alegre
Universidad de Leon
Abstract Image manipulation is a technique that can be
carried out by the majority of people. It can be useful in
many situations but it can also be used with malicious purposes. For this reason, image manipulation has become a
problem when we need to identify images in big datasets.
To fight against it, a technique called similarity search is
used. It is based on perceptual hashing, but these methods
are not robust against all kind of possible manipulations.
University of Le
on, within the framework of ASASEC European project, is working to provide a perceptual hashing
solution that outperforms current techniques.
I. Introduction. Image manipulation problem.

It is said that a picture is worth a thousand words and
that is the reason why we are interested in manipulating
images at our will with different purposes. Image manipulation is a powerful process that was born almost at
the same time than photography and it has been used all
along history in numerous contexts, sometimes with cosmetic purposes (Figure 1) and sometimes with politic purposes (Figure 2). Nowadays, this process is open to everyone since the easy access to image manipulation software
means that singular skills are no longer required. One
proof of this is that lots of teenagers with basic computer
knowledge touch up images when sharing them in their
social networks.
In that way, image manipulation has become an obstruction in some domains like the fight against child
pornography, which is the object of our study. One of
the main clues followed by police when investigating this
kind of crimes is the detection of illegal images. At the
beginning of the child pornography prosecution, a suspect image was contrasted against a dataset compound
of previously marked as illegal images, and if there was a
positive match, that new image was also marked as illegal. However at the moment, confiscated images can be
exactly no equal but just visually similar, because they
have suffered any kind of manipulation (compression, size
changes, brightness and contrast changes, face obfuscation, etc.). This becomes a serious obstacle because that
new image will not be categorized as illegal and criminals could take advantage of this deficiency. To avoid this
phenomenon, we can use a process called similarity search
that allows us to find not only identical images but also
images that are similar to a given one. One of the most
commonly used methods of similarity search is robust or
perceptual hashing, which will be discussed later.
ASASEC (Advisory System Against Sexual Exploitation of Children) is an European research project whose
goal is to provide a technological solution to help the fight
against child pornography. A consortium of public and
private entities expert in innovative technology is developing this project; they are INCIBE (Cibersecurity Na-
tional Institute), University of Le

on, Official Association
of University Graduates in Computer Science, Technological Investigation Brigade of the Spanish National Police
and Polytechnic University of Madrid.
University of Le
on is developing and testing one of the
most innovative tasks of ASASEC project, the use of artificial vision techniques to analyse evidences in child pornography databases.
In particular, University of Le
on is working on several
artificial vision methods, among them:
Entity detection: Illegal images usually contain entities or clues that the police, given their experience, can
recognize from past crime scenes. Therefore, scenarios and
evidences can be manually tracked and analysed. University of Le
on is creating an automatic system for clue
detection. Using this system, the police, will be able to
perform this task in an automatized way.
Scene categorization and tampering detection
using perceptual hashes: As we previously said, it is
common to manipulate illegal images (face obfuscation,
watermarking, etc.) making difficult their categorization
using the current cryptographic hash methods. University
of Le
on is creating a perceptual hashing method, robust
against all of these modifications to substitute present systems.
II. Finding images using perceptual hashing
A hash is a unique identificator associated to a file, some
kind of summary of the file based on its content. Broadly
speaking, generating a hash from a file is similar to convert that file in a piece of representative text. Perceptual hashing is a subset of hashing usually applied to images. It consists of extracting a simple representation of
the image, in such a way that small changes over the image from the point of view of human perceptual systems
imply small changes on its perceptual hash, and similarly,
large changes over the image imply large variations of its
perceptual hash (see Figure 3).
As we can see in these pictures (Figure 3), both are
very similar from the point of view of human visual systems, however, a cryptographic hash (MD5 is shown in
the figure) is not able to reflect this similarity. We can use
cryptographic hashing to verify the integrity of a picture,
but this kind of hash does not offer information about the
pictures visual structure. As we can observe, the cryptographic hashes of both images show no similarity at all,
however, perceptual hashes do. When images are similar, distance between their perceptual hashes is very low,
and in the same way, if both images are slightly different,
their perceptual hashes will be very far away in distance
terms. Perceptual hashes reflect the relationship between
137
JNIC2015

2
Fig. 1. Abraham Lincolns head on John Calhouns body (1860).
Fig. 2. Nazi propaganda minister removed from the picture.
the similarity of two images and the distances between

their hashes.
If the perceptual hash of the images in a dataset is
known, it is easy to perform searches and image categorization. If we have a dataset with millions of images and
we want to look for a specific image, an automatic exhaustive search will take too long: Images should be checked
one by one to determine if there is a match. Besides,
if our image has suffered some kind of modification (compression, format and size changes, brightness and contrast
changes), a match will probably not be found, because
there is no image in our dataset that provides a perfect
match with the current one. This problem can be solved

using perceptual hashes. Hence, each image would be associated to a fixed-size hash (usually lower or equal than
512 bits, depending on the used method), which is faster
than when comparing complete images and also robust
against several types of modifications.
Current systems use cryptographic hashes for confiscated images and video indexing. Cryptographic hash
does rely on the image binary structure - the binary code
used to store that image in a computer - rather than on
human perceptual system over an image. For this reason,
the change of one single bit, almost imperceptible for hu-
138
JNIC2015

3
Fig. 3.
Left: original image, right: modified image due to color changes.
MD5 cryptographic hash extracted from
the original image:
bb4f0a96c77e8737d02755457c2e49c8, MD5 cryptographic hash extracted from manipulated image:
6d4d51dfc23becf3edb0019448f78c8c. Perceptual Hash (pHash dct) extracted from original image: 4e1e4967f518cec2, Perceptual
Hash (pHash dct) extracted from manipulated image: 4e1e5d47b518cec0.
man eye, would result in the generation of a completely

different cryptographic hash that will not allow us to discern if both images are the same from human perception
point of view. As mentioned before, it is very common
to manipulate images: colour correction, watermarking,
rotations, scales, compressions, etc. For that reason, University of Leon proposes the use of perceptual hashes, robust against all kind of manipulations within the frame of
the ASASEC project.
hashes are good against rotations or other kind of modifications.

ASASEC project needs a solution robust against all
kind of attacks that images of child pornography usually
suffer. University of Le
on is working in this challenging
task, trying to combine and improve existing methods in
order to diminish their deficiencies and adapt them to our
needs.
III. Current proposal
IV. Conclusions
Nowadays thanks to perceptual hashing, we can detect

almost any manipulated picture that allows the police to
detect illegal images. Let us do an overview to some of the
methods used to generate perceptual hashes. Yuenan Li et
al [1] obtain a hash robust against rotations using a modification of Gabor filter, achieving a good balance between
robustness and discriminability. Longjiang Yu et al.[2]
propose a method robust against compressions and scales
using Cosine Discrete Transform to extract the hash taking into account the low frequencies of the image, that contains the perceptual basic structure of the image. Another
works such as Jinglong Zuo [3], Monga Vishal [4] or Chen
Brenden [5] present robust methods against compressions,
scales and rotations. There are also methods capable of
detecting malicious manipulations, Ahmed Fawad [6], Sujoy Roy [7] and Han-ling Zhang [8], that can be used for
tampering detection. In this research line, Farid [9] proposes a method to analyse compression changes over images to detect artefacts that unveil the presence of spliced
regions. There are also some approaches that solve specific
problems for example Senel Kamil [10] applies perceptual
hashing for face recognition for biometric authentication,
extracting robust hashes from face images.
As we can observe, there is not a perceptual hash capable of solving all types of modifications that an image
can suffer. Some hashes are good against some types of
attacks like changes in scale and compressions and other
Cryptographic hashing methods commonly used are

not very adequate for similarity search, required in child
pornography datasets. For that reason, University of Leon
proposes the use of perceptual hashes. This type of hashes
is generated based on the content of the perceptual structure of the image from a human observer point of view,
instead of being generated based on the binary structure
of the image. However, there are many techniques we can
use to generate perceptual hashes, each of one with their
advantages and limitations, so it is necessary to develop
new useful solutions for our specific problem. University
of Le
on is actively working in the search of this solution in
the frame of the ASASEC European project, collaborating
with several public and private entities.
Once this general purpose hashing techniques are released, their use will not be limited to the exclusive needs
of this project. On the contrary, they can also be used
in different contexts, for example authorship protection in
video sites like YouTube or the search of images by content
on image management systems.
Acknowledgements
This work has been supported by grant DPI2012-36166,
and via the pre-doctoral FPU fellowship program from the
Spanish Government (AP2010-0947)
139
JNIC2015

4
Referencias
[1]
C. Z. Yuenan Li, Zheming Lu and X. amu Niu, Robust image

hashing based on random gabor filtering and dithered lattice
vector quantization, Image Processing, pp. 19631980, 2012.
[2] L. Yu and S. Sun., Image robust hashing based on dct sign,
In Intelligent Information Hiding and Multimedia Signal Processing, pp. 131134, 2006.
[3] J. Zuo and D. Cui., Retrieval oriented robust image hashing,
Industrial Mechatronics and Automation, pp. 379381, 2009.
[4] . V. Monga and M. Mhcak., Robust and secure image hashing
via non-negative matrix factorizations, Information Forensics
and Security, pp. 376390, 2007.
[5] B. Chen and V. Chandran, Robust image hashing using higher
order spectral features, In Digital Image Computing: Techniques and Applications (DICTA), pp. 100104, 2010.
[6] F. Ahmed and M. Siyal., A secure and robust hashing scheme
for image authentication. Fifth International Conference on
Information, Communications and Signal Processing, pp. 705
709, 2005.
[7] S. Roy and Q. Sun., Robust hash for detecting and localizing
image tampering, Image Processing, 2007.
[8] C. q. X. Han ling Zhang and G. zhi Geng., Content based
image hashing robust to geometric transformations, In Electronic Commerce and Security, vol. 2, pp. 105108, 2009.
[9] H. Farid, Exposing digital forgeries from jpeg ghosts, Information Forensics and Security, pp. 154160, 2009.
[10] M. M. a. K. Senel and V. Monga., A learning framework for
robust hashing of face images, In Image Processing (ICIP),
pp. 197200, 2010.
140
JNIC2015
Inseguridad en infraestructuras crticas

Manuel Snchez Rubio, Jos Miguel Gmez-Casero Marichal, Carlos Cilleruelo Rodrguez
UNIR Universidad Internacional de la Rioja, Logroo, Espaa
manuel.sanchezrubio@unir.net;jmgomezcasero@yahoo.es;carloslannister@gmail.com
Abstract Este artculo presenta unas amenazas potenciales

existentes cuando los desarrolladores y empresas despliegan SCADA
para las infraestructuras crticas sin cuidar la seguridad. Est basado
en el motor de bsqueda Shodan y su trabajo cuando los atacantes
renen informacin sobre un objetivo o cuando estn buscando un
activo para atacar. Adems, se muestra en este documento una
prueba de concepto, simuladora de ataques a estos sistemas SCADA,
siguiendo los pasos de un atacante convencional, desde la consulta de
bsqueda en el motor Shodan, hasta que el acceso es concedido a una
infraestructura crtica.
Keywords SCADA, seguridad por defecto, infraestructuras
crticas, shodan, footprinting.
I. INTRODUCCION
Internet de las Cosas (IoT) [1] est terminando de
materializarse, y cada da las personas hacen uso de la tecnologa
para cumplir sus necesidades, desde pequeas consultas cotidianas
hasta poder comprar productos con un solo botn preprogramado.
Un indicador de que el IoT est sobre la sociedad es la
posibilidad de solicitar a la compaa de comercio electrnico
Amazon un botn dash button que, cada vez que el usuario pulsa,
se enviar a su domicilio un pedido segn los parmetros
establecidos en el dispositivo (por ejemplo, para solicitar
productos consumibles y cotidianos).
Lo que parece ser un simple dispositivo electrnico al servicio
del usuario esconde, a su vez, un foco potencial de inseguridad
para el usuario, ya que su utilizacin es nicamente un botn, pero
tras este mecanismo existe, principalmente, un envo de datos a los
servidores de la compaa, donde se realizar un pedido segn la
informacin de la solicitud emitida.
Si cada vez que se pulsa un botn se realiza un pedido, la
pulsacin repetida de este botn supone, por tanto, la realizacin
de un elevado nmero de pedidos, que supondrn un desembolso
para el usuario.
Y si alguien es capaz de copiar ese envo y replicarlo
malintencionadamente infinitas veces? Es consciente el usuario
de que est siendo vctima de este ataque? Y lo que podra ser ms
importante, ha sido el usuario consciente de este riesgo en el
momento de adquirir el servicio?
Aunque es muy probable que esta compaa de comercio
electrnico s haya considerado todos los escenarios, este ejemplo
nos sirve para exponer un problema existente en la actualidad: la
sociedad es consciente de las capacidades de la tecnologa para
suplir sus necesidades, pero no es consciente de los riesgos que
supone apoyarse en ella sin conocer stos.
Llegados a este punto, y pensando ms en las organizaciones y
en los servicios prestados para muchos usuarios, estn las

compaas prestadoras de servicios concienciadas de los riesgos
existentes ante la falta de seguridad en los servicios?
En este estudio nos centraremos en las vulnerabilidades
existentes en las conocidas como infraestructuras crticas (ver
ejemplo en Fig. 1), trmino aplicado generalmente a aquellos
activos cuyo funcionamiento es en beneficio de la sociedad, desde
generadores de electricidad hasta transporte, hospitalesetc.
Todos los sectores que se apoyan en infraestructuras crticas
son, como su nombre indica, necesarios para el funcionamiento de
la sociedad en mayor o menor medida, y su correcto
funcionamiento ser responsable del crecimiento de sta.
Pero en el funcionamiento existe un elemento que no se trata
debidamente, bien porque se trata con menor prioridad o bien
porque simplemente no se trata: la seguridad del entorno. Si los
responsables de una infraestructura crtica no garantizan la
proteccin necesaria para su entorno, entonces no se est
mitigando el riesgo existente ante la posibilidad de que el trabajo
realizado por sta infraestructura no sea el esperado o que incluso
suponga una interrupcin del servicio, provocando prdidas que,
en algunos casos, no tienen cuanta econmica para evaluarse.
Afortunadamente los principales fabricantes han reaccionado
ante este tipo de ataques y muchos de sus productos obligan
durante su proceso de implantacin a ejecutar una serie de pasos
destinados a establecer la configuracin de la seguridad de ste.
Un ejemplo sera los dispositivos de almacenamiento en red de
Synology, los cuales requieren un valor para la contrasea del
usuario admin, cuyo nombre tambin puede ser modificado.
Sin embargo, la complejidad de la contrasea no es evaluada
durante este proceso, lo que lleva la responsabilidad de su fortaleza
al usuario, depurando responsabilidades por parte del fabricante,
pero el problema persiste.
De esta forma, vemos que existen dos escenarios diferentes
pero que ambos han dejado durante el desarrollo el aspecto de la
seguridad en segundo plano, lo que conlleva asumir riesgo por
parte de todas las personas responsables de ste.
La principal puerta de acceso a estos entornos por parte de
entidades externas sin acceso autorizado es mediante las diferentes
vulnerabilidades existentes en el propio sistema SCADA [2], que
se han convertido en objeto de muchos estudios tanto generales
[3],[4] como propios del conocido como hacktivismo [5], mencin
especial al gusano informtico Stuxnet [6], uno de los mayores
ataques contra este tipo de entornos. Entre estas vulnerabilidades
destacaremos la ya mencionada seguridad por defecto como
vulnerabilidad que ofrece acceso a estos sistemas.
En el presente artculo se hace mencin expresa a una
herramienta ampliamente conocida y utilizada para la bsqueda de
141
JNIC2015
estos entornos, Shodan, creada por John Matherly [7], que desde
2009 ha estado realizando un escaneo eterno de todas las
direcciones IP y recolectando la informacin de las cabeceras de
cada servicio que aloja.
Una vez expuestos todos los elementos participantes en el
presente estudio, concluiremos con una prueba de concepto, donde
seguimos la metodologa de un atacante cualquiera desde una
bsqueda en Shodan de una infraestructura crtica, hasta el acceso
a una de stas, donde tendremos control total de la misma.
Finalmente, en la seccin VI se incluyen las conclusiones del
estudio.
La principal motivacin tras este estudio es mostrar. Otro
estudio de referencia, ms enfocados al Internet de las Cosas y a
los accesos abiertos o que no hacen uso de la seguridad por
defecto, es el realizado por Patton [8]. En el caso del presente
estudio, no haremos una bsqueda general de dispositivos con
acceso abierto, sino que nos centraremos en entornos crticos,
donde la seguridad adquiere una importancia an mayor.
Fig. 1. Ejemplo de interfaz de una infraestructura crtica (depuradora de aguas)

con SCADA.
II. SCADA Y ESTRUCTURAS CRTICAS

Para poder tener el estudio en contexto, dedicamos este captulo
para la definicin de algunos elementos clave del mismo.
Los principales protagonistas son las infraestructuras crticas,
un conjunto de estructuras que engloban una pieza clave para el
crecimiento de la sociedad, y que cuyo correcto funcionamiento
debe ser garantizado por sus responsables.
Segn sus siglas Supervisory Control And Data Acquisition,
SCADA es utilizado ampliamente para el control de
infraestructuras crticas. Existe un estudio centrado en la seguridad
de los entornos responsable de la seguridad vial de Estados Unidos
(Ghena et al, 2014 [9]), en el que se realiza un anlisis de cada una

de las partes implicadas en este entorno, cuyo funcionamiento
puede ser simple y sencillo, pero que si un ente externo logra
comprometerlo, podra suponer graves consecuencias.
Su principal ventaja es el control de estas estructuras en remoto,
permitiendo una gestin a distancia de estos activos y as poder
garantizar el buen funcionamiento y gestin del servicio para el
que se trabaja. Uno de los principales elementos principales de un
sistema SCADA es el sistema supervisor, que cuenta con una
interfaz humano-mquina (Human-machine interface HMI),
utilizada como elemento de conexin entre la informacin de la
mquina y las rdenes de las personas designadas como
responsables del entorno.
La utilizacin de estos entornos se ha extendido mucho, y ha
llamado la atencin de los atacantes por el potencial existente a la
hora de tomar el control de infraestructuras crticas, tanto parcial
como totalmente. Ejemplos histricos sobre el inters despertado
en los atacantes es, como se ha mencionado anteriomente, el
gusano informtico Stuxnet, que fue descubierto en 2010 y que
cuya actividad se centr principalmente en sistemas SCADA
desarrollados por el fabricante Siemens ubicados en Irn.
Tanto antes como despus de este conocido malware, los
sistemas SCADA son objetivo de muchos ataques y de
investigaciones que buscan constantemente vulnerabilidades que
puedan ser aprovechadas.
Ms all del perfil del atacante, la seguridad de los entornos
SCADA, las infraestructuras crticas que gobiernan y entornos que
interactan con stos (sistemas de monitorizacin) han sido objeto
de estudio para muchas organizaciones, como el Instituto Nacional
de Tecnologas de la Comunicacin [10], cuyos autores repasan
los principales conceptos relacionados con el desarrollo de
entornos para el sector industrial.
Por ltimo, es importante comentar que existen diferentes tipos
de normativas en los sistemas de control, enfocadas especialmente
en la seguridad, donde se recopilan diferentes modelos y
recomendaciones, as como estndares centrados en diferentes
sectores, como podra ser el energtico. Una recopilacin general
de esta normativa es la que ofrece INCIBE en su pgina oficial
[11]. Existen estudios donde se aplican estas normativas. En el
caso del estudio realizado por Czechowski, Wicher y Wiecha
sobre la seguridad en la comunicacin de entornos SCADA
aplicando la normativa IEC 61850 [12], donde se define una serie
de vulnerabilidades en un escenario. Entre las vulnerabilidades
figura valores de usuario y contrasea por defecto, que
pertenece a un grupo al que dedicaremos un captulo ms adelante,
y que adquirirn importancia en el presente estudio. Como
referencias a diferentes tipos de soluciones SCADA existentes en
la actualidad, se puede recurrir al estudio de Aghajanzadeh y
Keshavarz-Haddad [13].
142
JNIC2015
III. SHODAN
Introducidos en la problemtica existente en SCADA, y
conociendo la criticidad de los entornos que gobiernan, vemos que
estos entornos deben estar expuestos a la Red para mantener la
operativa en remoto, lo que supone aceptar el riesgo inherente de
que cualquier persona conectada a la Red puede tener acceso a
ste. Sin embargo, buscar entornos SCADA preguntando el tipo de
servicio que presta cada direccin IP en la actualidad en cada uno
de sus puertos, puede suponer una tarea muy pesada para un
atacante en particular, adems de dejar una huella digital grande.
Es aqu (y en muchos otros aspectos de seguridad de la
informacin) donde Shodan ha sabido ganarse un sitio en el kit de
utilidades para cualquier experto en seguridad. Creada por John
Matterly, este motor de bsqueda ofrece al usuario resultados
sobre lo que este busque, pero prescindiendo de sitios web, sino
utilizando los banner de los servicios que tienen habilitados los
servidores.
En este punto del estudio, es necesario definir dos tcnicas
utilizadas en la fase de bsqueda de informacin de cualquier test
de penetracin a un sistema: footprinting y fingerprinting [14].
Footprinting hace referencia a cualquier recopilacin de
informacin pasiva-indirecta de un objetivo con respecto del
atacante, esto es, sin que la vctima sea la fuente original directa.
Como ejemplos de esta tcnica, estn la bsqueda de
informacin de una organizacin en diferentes publicaciones en
medios abiertos, utilizacin de motores de bsqueda, informacin
relativa a registradores, DNS, WHOIS, etc.
Por otra parte estn las tcnicas de fingerprinting, ms
agresivas que las descritas anteriormente, ya que su objetivo es
adquirir la informacin directamente del objetivo, como por
ejemplo utilizando un escner de puertos o haciendo anlisis de su
trfico de red.
La principal ventaja de fingerprinting es la obtencin de
informacin muy valiosa, como el funcionamiento de un sistema,
su versin, su sistema operativo, los servicios activos, mientras
que footprinting se trata de recopilacin de informacin desde el
exterior, aunque de menos valor.
Es aqu donde destaca Shodan, ya que lo relevante de este
motor de bsqueda, no es nicamente la disposicin de la
informacin de los sistemas que ha escaneado, sino su mtodo de
funcionamiento, basado en la captura de estados de los servicios,
recopilando informacin en espacio y tiempo, y permitiendo el
acceso a esta informacin de forma atemporal, sin utilizar
informacin relativamente en tiempo real.
Esto tiene la principal ventaja, desde el punto de vista del
atacante, de que obtiene informacin valiosa, tpica de tcnicas de
fingerprinting, a travs de una entidad ajena al objetivo, similar al
footprinting.
En este caso Shodan necesita datos concretos, tales como la

direccin IP de un equipo en concreto (o una subred especfica),
un nmero de puerto especfico, o una cadena que figure en la
cabecera del servicio que Shodan haya identificado al descubrir la
Red. Una vez parametrizada la bsqueda esta se realiza y ofrece
los resultados que responden a la consulta realizada.
Cada elemento de la lista de resultados dispone de informacin
relacionada con los servicios que el equipo tena en
funcionamiento en el momento de su deteccin, as como
informacin propia de una direccin IP, como el proveedor de
servicio, ASN o el pas de localizacin, entre otros. La mayora de
estas detecciones son bien servicios de conexin Telnet/ SSH o
aplicaciones web que sirven como pasarela de acceso al servicio
en s, el cual es accesible a travs de Shodan.
En muchas ocasiones, incluso, se puede acceder al servicio sin
albergar ningn tipo de seguridad, permitiendo ver, por ejemplo,
las imgenes que ofrece una cmara IP, como muestra la figura 2.
Fig. 2. Sesin abierta va web con control

de cmara IP, con acceso desde Shodan.
Por ltimo recalcar la capacidad de expansin que tiene Shodan

y el apoyo comunitario del que dispone, los cuales han permitido
extender el motor de bsqueda a otros desarrollos, como Shodan
Maps, donde disponemos de un mapa mundial con las direcciones
IP de las mquinas reconocidas en Shodan, o Shodan Exploits, un
buscador destinado a la consulta de vulnerabilidades reconocidas,
que pueden ser ordenadas y clasificadas segn origen, plataforma,
fabricante, etc. (ver figura 3).
143
Fig. 3. Buscador de exploits de Shodan
JNIC2015
La aportacin de Shodan al mbito de la seguridad de la

informacin ha sido muy grande, al ser una herramienta de gran
utilidad tanto para atacantes como para expertos en seguridad. Ms
all de los escenarios propios de un ataque, Shodan tambin sirve
para ofrecer informacin propia de un servicio Big Data, al
disponer de informacin de innumerables ordenadores,
dispositivos mviles, entornos crticos, webcams/ cmaras IP, etc.
Adems de Shodan, otros autores han realizado estudios basados
en el potencial de este motor de bsqueda, como Bodenheim,
quien realiz una tesis enfocada en la bsqueda de sistemas de
control de entornos industriales mediante Shodan [15], la cual
sirvi como pie de investigacin y una prueba de concepto en la
que Bodenheim et al (2014) [16] hacan uso de cuatro
programadores lgicos a modo de seuelo para evaluar el grado de
exposicin ante Shodan. El presente estudio tambin ofrece una
serie de pautas para mitigar la exposicin ante el buscador,
mediante la manipulacin de cabeceras de servicio.
Esta informacin se ofrece en forma de informes que publica la
propia pgina de Shodan con cierta frecuencia, ofreciendo a la
comunidad datos estadsticos como el nmero de webcams
existentes en el mundo (ver figura 4).
Fig. 4. Uno de los informes que ofrece Shodan.
Es interesante recalcar que el buscador Shodan y todas sus

utilidades no son gratuitas, sino que existe una licencia vitalicia
para tener acceso a mltiples elementos, como el uso de todos los
filtros de bsqueda, el visionado de todas las pginas de resultados
y una API key para poder realizar desarrollos basados en Shodan.
Tambin dispone de acceso a un sistema de crditos, que existe
en la pgina del propio buscador, donde se pueden comprar
distintos plugins que enriquecern el funcionamiento.
Desde el punto de vista de un experto de seguridad de la
informacin profesional, la utilizacin de una licencia de Shodan
es ms que recomendada para poder observar con todos los
detalles necesarios el estado de los activos que estn expuestos a
la Red y cuya responsabilidad dependa de ste.
IV.
SEGURIDAD POR DEFECTO
Se trata de una vulnerabilidad reconocida por las

organizaciones especializadas en seguridad, como por ejemplo
OWASP [17], que la recoge en su Top Ten [18] personal de
vulnerabilidades ms extendidas.
Existen muchos estudios relacionados con la seguridad por
defecto, como el realizado por Cui y Stolfo, en el que recogen
diferentes datos relacionados con la seguridad por defecto [19],
como que un 13% de los dispositivos descubiertos durante su scan
contaban con valores de seguridad por defecto, que les permitieron
acceder al entorno, que poda ser desde una webcam hasta un
router convencional.
Tpicamente se puede comprobar este formato de credenciales
en los routers de conexin a internet que las operadoras telefnicas
y proveedoras de conexin a la Red proporcionan a los usuarios
en sus viviendas. Ms all del usuario particular, existe un estudio
centrado en la seguridad de la conectividad WiFi (Sagers et al,
2015) [20], en el que se evala el estado actual de la seguridad
WiFi y se realiza una reflexin orientada a los proveedores de
puntos de acceso WiFi.
Para la gran mayora de usuarios, son familiares determinadas
cadenas de caracteres ASCII usadas como claves de paso a los
sistemas, como accesos a portales de router y as gestionar
diferentes aspectos de stos.
No obstante, hay que recalcar otra gran parte de fabricantes que
proveen productos y soluciones hardware/software que ofrecen
este tipo de sistemas de gestin y, durante su proceso de
instalacin e implantacin, solicitan de forma obligatoria la
introduccin de una contrasea para la cuenta de usuario
administrador, con suficiente fortaleza, cayendo la
responsabilidad de cualquier acceso no autorizado en la parte del
responsable de la instalacin, y no en el fabricante.
Afecta esta vulnerabilidad a los sistemas SCADA? Las figuras
5 y 6 muestran capturas de pantalla de un sistema SCADA
destinado a la monitorizacin y gestin de una empresa generadora
de energa solar.
El citado sistema, tiene un control de voltajes para cada panel
solar, as como una variedad de sensores que permiten monitorizar
voltaje acumulado, temperatura, intensidad de luz que percibe, etc.
En general, se trata de una interfaz muy completa, pensada ms
para comprobar el estado de la totalidad de los paneles solares pero
con dotes de control remoto.
Puede afectar la seguridad por defecto a este entorno? Para
ello hay que localizar informacin til relativa a la configuracin
de seguridad de la interfaz. La cabecera del servicio nos notifica
la utilizacin de una aplicacin web que requiere usuario y
contrasea para su acceso.
Haciendo una bsqueda del fabricante, modelo y versin del
sistema SCADA en cuestin, vemos que, al proveer el sistema, se
ofrecen unas credenciales con valor por defecto para poder acceder
al sistema.
144
JNIC2015
las credenciales por defecto han sido modificadas y modificadas

por contraseas de elevada fortaleza [22].
V. PRUEBA DE CONCEPTO
Fig. 5. Interfaz de inicio de sesin de una empresa de energa solar con defectos
graves en las credenciales
En el caso de que las personas responsables de la seguridad de

la granja de paneles solares no hayan pensado en el riesgo
existente a la hora de utilizar credenciales por defecto, un atacante
podra utilizar esta informacin que ofrece el fabricante contra
estos entornos y tener acceso sin restricciones contra las
infraestructuras, obteniendo el control que la interfaz permita al
usuario.
Cules son las consecuencias ante este acceso no autorizado?
En este caso, si el atacante decidiera apagar el sistema, supondra
prdidas econmicas de magnitud alta por cada hora que el sistema
est apagado, suponiendo una amenaza que aumenta en el tiempo
para la organizacin.
Fig. 6. Interfaz de gestin de los paneles solares
El inters por esta vulnerabilidad ha llevado a diferentes

comunidades Open Source a la creacin de amplias bases de datos
con informacin relativa a dispositivos, fabricantes y sus
credenciales por defecto, como por ejemplo la pgina defaultpasswords [21], que permite buscar este tipo de credenciales,
utilizadas para este tipo de ataques.
Para finalizar el captulo, indicar que guas de buenas prcticas
como el NIST recogen entre sus recomendaciones asegura que
Como caso prctico de este estudio, realizamos un seguimiento

de los pasos que realiza cualquier atacante desde la bsqueda de
un host vctima hasta el acceso a una infraestructura crtica, donde
concluiremos la prueba de concepto, pero que desgraciadamente,
no siempre coincide con la conclusin del ataque, ya que la
mayora culmina con la desconfiguracin del entorno, la cada del
sistema, etc.
El comienzo de la localizacin de un objetivo es mediante el
buscador objeto de este estudio, Shodan, preguntando a ste por
diferentes parmetros propios de una cabecera de servicio de un
entorno SCADA. En esta prueba buscaremos acceder a una
estacin depuradora de aguas residuales (ver figura 7).
Debido al objetivo de este entorno, es bastante probable
encontrar el objetivo con palabras que refieran a dichos
dispositivos o similares en elementos como el cuerpo o el ttulo de
la interfaz web del servicio.
Realizando la bsqueda mediante los parmetros
proporcionados, encontramos servicios que cumplen con los
requisitos iniciales, ubicados en un determinado Pas y con cdigo
HTTP 401 requerida autorizacin.
Para otras pruebas de concepto y test de footprinting, hay que
destacar este ltimo detalle, ya que en muchas ocasiones el
buscador mostrar un cdigo 200 OK, lo que significara que el
servicio no requiere de autorizacin y sera libremente accesible,
pudiendo llevarnos directamente al cuadro de mando del entorno
al que intentamos acceder.
[Capte la
atencin de
losBsqueda
lectoresde depuradoras va Shodan
Fig. 7.
mediante una
cita
importante
El detalle e histrico
nos ofrece el resto de pormenores
extradams
del sobre la depuradora: activa desde
necesarios para conocer
documento
o de la bsqueda, otros servicios
hace unos meses desde
el momento
utilice
esteva puerto 8080 por el que se ha
abiertos adems del
HTTP
espacio para
encontrado este servidor.
resaltar
Otros elementos
como un
IP y versiones que maneja el servidor,
punto
clave.
nos podran ofrecer otros
datos de forma indirecta, como la
Paracoordenadas
colocar
geolocalizacin en
de la depuradora y las
el cuadro de
texto en
cualquier
lugar de la
pgina, solo
tiene que
arrastrarlo.]
145
JNIC2015
vulnerabilidades recogidas en la lista CVE [23], que serviran para

ampliar el espectro de accin y vector de ataque.
El acceso al servicio web (accesible va link directo en el
resultado de Shodan) nos muestra una pgina en blanco, con una
ventana emergente que sale casi al instante de intentar acceder al
servicio. En esta ventana, nos pregunta por nuestros credenciales
junto con una informacin del servicio, que muestra claramente el
fabricante y versin del producto que gestiona este servicio, tal y
como se puede observar en la siguiente figura 8.
Fig. 9. Panel de control para gestin de depuradora de agua.
Finalizamos la prueba de concepto, al haber logrado con xito

el acceso no autorizado a una infraestructura crtica. El escenario
se ha centrado en un caso muy particular de infraestructura crtica,
pero el mismo puede trasladarse tanto a objetivos dirigidos
(utilizando una direccin IP especfica y propia de una
organizacin) como a otros tipos de entornos crticos.
VI. CONCLUSIONES
Fig. 8. Ventana emergente del servicio web de la depuradora
An desconocemos si el fabricante proporciona unos

credenciales predefinidos a los clientes que adquieran este
producto, y ni siquiera conocemos estos credenciales, pero la
informacin de esta ventana ser ms que til para este fin.
As, tan slo har falta realizar una consulta en cualquier motor
de bsqueda y buscar esta informacin junto con cadenas de
caracteres comunes.
Esta misma bsqueda nos lleva a una consulta en un foro de
dudas, donde un usuario consulta por estos credenciales, al no
haber tenido oportunidad de acceder al servicio.
Otro usuario resuelve la cuestin indicando los credenciales,
los cuales utilizamos para intentar acceder al servicio objeto de
esta prueba de concepto.
El resultado, como caba esperar, es satisfactorio, y
conseguimos entrar al panel de control con xito, accediendo a
todas las funcionalidades propias de este entorno SCADA, desde
controlar el estado de las alarmas hasta modificar la dosificacin
de sosa y nutrientes (ver figura 9).
Con el presente artculo ofrecemos una percepcin de la

problemtica existente en la ya mencionada seguridad por defecto,
centrndonos en las infraestructuras crticas, SCADA y sus riesgos
y consecuencias en caso de no mitigar problemas como los
descritos.
La prueba de concepto realizada no es ms que una de las miles
de pruebas de concepto (que se transforman en ataques reales) que
vulneran los mecanismos de seguridad de estas estructuras crticas
y suponen una seria amenaza para las organizaciones, sus servicios
y los usuarios de stos.
Las consecuencias que puede tener, por ejemplo, el acceso a
una depuradora que abastece agua a una regin, supone hablar de
trminos que se miden por encima de los daos econmicos, lo
que hace que su seguridad tenga un valor mucho ms elevado que
el habitual, ya que el adjetivo crtico de estas infraestructuras est
claramente justificado.
Debilidades del sistema como uso de credenciales por defecto,
reutilizacin de credenciales y contraseas de fortaleza dbil se
basan en una vulnerabilidad propia de usuarios y administradores,
por lo que su mitigacin es mucho ms difcil de solventar.
Siempre se pueden crear polticas de seguridad que cubran
escenarios como los descritos anteriormente, que incluyan
clausulas como tiempos de expiracin para contraseas,
utilizacin de varios tipos de caracteres, etc.
Sin embargo, la principal solucin para evitar accesos no
autorizados a los entornos SCADA es bastionar las infraestructuras
crticas. De esta forma, incluso el acceso desde Shodan ser muy
difcil o imposible.
La principal seguridad contra este tipo de tcnicas de
footprinting y fingerprinting es aadir una nueva capa de
seguridad a nivel de red, basada en redes privadas tipo VPN, que
sean utilizadas nica y exclusivamente para el acceso a las
interfaces humano-mquina.
146
JNIC2015
De esta forma, el atacante tendr que resolver la problemtica

de enfrentarse a una conexin VPN antes de poder acceder al
entorno SCADA, lo que implica paliar con los diferentes aspectos
de este tipo de redes privadas, mucho ms seguras.
Otras opciones, en caso de ser un sistema de control remoto
especfico y cerrado, como puede ser por ejemplo entre dos sedes
de una organizacin, podra utilizarse un sistema de filtrado por IP
tipo lista blanca, donde slo se permite el acceso al entorno desde
direcciones IP propias de la compaa, impidiendo cualquier
acceso externo.
Es posible que la solucin ms evidente sea que se detenga la
actividad tanto de Shodan, al tratarse de un escaneo de la Red a
gran escala, pero lo que recogemos en este estudio no es el poder
de motores de bsqueda como el desarrollado por John Matherly,
sino la vulnerabilidad existente por naturaleza en los servidores:
su exposicin a la Red para prestar servicio implica ofrecer una
informacin que puede ser utilizada por terceros con intenciones
maliciosas y que estn fuera del alcance y objetivos del servicio a
prestar en s.
No obstante tambin cabe destacar el uso de Shodan en la
actualidad para la actividad destinada a fines estadsticos y de
investigacin, a la hora de ofrecer toda su informacin sectorizada
por protocolos, pases y fabricantes
AGRADECIMIENTOS
This work is partially supported by UNIR Research Support
Strategy 20132015, under the CYBERSECURITICS.es
Research Group [http://research.unir.net].
[11] Instituto Nacional de Ciberseguridad (2015, julio). Normativas de seguridad

en
sistemas
de
control.
Recuperado
de
https://www.incibe.es/blogs/post/Seguridad/BlogSeguridad/Articulo_y_com
entarios/Normativas_seguridad_sistemas_control.
[12] CZECHOWSKI, R., WICHER, P., & WIECHA, B. Cyber Security in
communication of SCADA systems using IEC 61850. Julio 2015
[13] Aghajanzadeh, N., & Keshavarz-Haddad, A. (2015). A Concise Model to
Evaluate Security of SCADA Systems based on Security Standards.
International Journal of Computer Applications, 111(14).
[14] Baloch, Rafay. Ethical Hacking and Penetration Testing Guide. CRC Press,
2014.
[15] Bodenheim, R. C. (2014). Impact of the Shodan Computer Search Engine on
Internet-facing Industrial Control System Devices (No. AFIT-ENG-14-M14). AIR FORCE INSTITUTE OF TECHNOLOGY WRIGHTPATTERSON AFB OH GRADUATE SCHOOL OF ENGINEERING AND
MANAGEMENT.
[16] Bodenheim, R., Butts, J., Dunlap, S., & Mullins, B. (2014). Evaluation of the
ability of the Shodan search engine to identify Internet-facing industrial
control devices. International Journal of Critical Infrastructure Protection,
7(2), 114-123.
[17] https://www.owasp.org/index.php/Main_Page
[18] https://www.owasp.org/index.php/Top10#tab=OWASP_Top_10_for_2013
[19] A. Cui and S. J. Stolfo. A quantitative analysis of the insecurity of embedded
network devices: Results of a wide-area scan. In Proceedings of the 26th
Annual Computer Security Applications Conference, pages 97106. ACM,
2010.
[20] Sagers, G., Hosack, B., Rowley, R. J., Twitchell, D., & Nagaraj, R. (2015,
January). Where's the Security in WiFi? An Argument for Industry
Awareness. In System Sciences (HICSS), 2015 48th Hawaii International
Conference on (pp. 5453-5461). IEEE.
[21] https://default-password.info/
[22] National Institute of Standards and Technology (2015, mayo). Guide to
Industrial Control Systems (ICS) Security. Recuperado de
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf
[23] https://cpe.mitre.org/
REFERENCIAS
Ashton, Kevin. "That internet of things thing." RFiD Journal 22.7 (2009):
97-114.
[2] Daneels, Axel, and Wayne Salter. "What is SCADA." International
Conference on Accelerator and Large Experimental Physics Control Systems.
1999.
[3] Igure, Vinay M., Sean A. Laughter, and Ronald D. Williams. "Security issues
in SCADA networks." Computers & Security 25.7 (2006): 498-506.
[4] Krutz, Ronald L. Securing SCADA systems. John Wiley & Sons, 2005.
[5] Langner, Ralph. "Stuxnet: Dissecting a cyberwarfare weapon." Security &
Privacy, IEEE 9.3 (2011): 49-51.
[6] Wilson, Clay. "INDUSTRIAL AND SCADA SYSTEMS MAY BE
INCREASINGLY TARGETED FOR CYBERATTACK." (2012).
[7] Matherly, John C. "SHODAN the computer search engine." Available at
[Online]: http://www. shodan.io (2009).
[8] Patton, M., Gross, E., Chinn, R., Forbis, S., Walker, L., & Chen, H. (2014,
September). Uninvited Connections: A Study of Vulnerable Devices on the
Internet of Things (IoT). In Intelligence and Security Informatics Conference
(JISIC), 2014 IEEE Joint (pp. 232-235). IEEE.
[9] Ghena, B., Beyer, W., Hillaker, A., Pevarnek, J., & Halderman, J. A. (2014,
August). Green lights forever: analyzing the security of traffic infrastructure.
In Proceedings of the 8th USENIX conference on Offensive Technologies
(pp. 7-7). USENIX Association.
[10] Instituto Nacional de Tecnologas de la Comunicacin (2012, marzo).
Estudio sobre la seguridad de los sistemas de monitorizacin y control de
procesos
e
infraestructuras
(SCADA).
Recuperado
de
https://www.incibe.es/file/5ik7qnpsCJD6GNls9ZYKrA
[1]
147
JNIC2015
Reto en ciberseguridad: anlisis forense de discos

Andrs Caro
Dpto. Ingeniera de Sistemas Informticos y Telemticos - Universidad de Extremadura
andresc@unex.es
Resumen- El anlisis forense de discos puede considerarse

como uno de los retos con ms importancia e, incluso,
demanda social. Este reto es ideal para alguien que desee
iniciarse sin tener ningn conocimiento previo. Por ello, se
selecciona Windows como sistema operativo base. Pese a que
todo lo aqu expuesto puede realizarse tambin desde Linux (y
con mayor facilidad), se opta por utilizar el sistema operativo
ms habitual para no iniciados.
El reto se presenta totalmente resuelto, y se propone que se
repita sobre otra unidad que se proporciona mediante un enlace
web para descargar y practicar todo lo aprendido.
extensiones habituales de vdeos y fotografas. Esto es ms que

evidente.
Finalmente, todo anlisis forense acaba con un
documento/informe en el que el forense explica sus mtodos,
resultados y conclusiones. Este paso no est incluido en el
ejercicio propuesto, puesto que aqu se presenta la metodologa
tcnica de anlisis forense de discos. La elaboracin de
informes periciales quedara fuera de lo que es el reto en s, un
reto totalmente tcnico y no demasiado formal.
II.
I.
INTRODUCCIN
El reto en s consta de dos partes: una fase de clonado de un

disco duro y una segunda fase de recuperacin de informacin
y archivos del mismo. Ambas fases se explican paso a paso,
sobre una imagen clonada de una memoria USB. Con
posterioridad, se facilita un enlace web a una imagen clonada
para que los interesados puedan realizar su propio reto,
repitiendo el proceso. La imagen se corresponde con una
clonacin de una memoria USB, en vez de un disco duro, por
cuestiones de espacio y tiempo. Se entiende que cualquiera que
sea capaz de clonar bit a bit una memoria USB, tambin es
capaz de clonar un disco duro. Para las pruebas, trabajar con
una memoria USB es ms rpido y ocupa bastante menos
espacio que hacerlo con un disco duro de GB/TB.
El reto se presenta con instrucciones bsicas para realizar el
anlisis. Cualquier no iniciado ser capaz de saber qu hace
cada uno de los pasos y cmo se recupera la informacin, por
lo que una persona enfrentada en la vida real a un caso similar
pero no igual podra saber fcilmente cmo actuar.
Es cierto que existen herramientas que buscan archivos
borrados en la tabla del sistema de ficheros (tipo Testdisk) y
herramientas que buscan directamente en el espacio de
ficheros, identificando cualquier archivo que encuentre (tipo
Photorec). Para casos habituales, lo aprendido en este reto, en
cuanto a metodologa, supera con creces las limitaciones
impuestas por las herramientas utilizadas (presentes y futuras).
El ejercicio propone recuperar archivos, y realizar un anlisis
forense real, incluyendo el filtrado de esos archivos segn el
contenido relevante para el caso. Aunque este filtrado no
destaca en el reto, es evidente que si lo que se buscan son
archivos con contenido de pornografa infantil, por ejemplo,
los ficheros a filtrar se corresponderan con aquellos que tienen
RETO EN ANLISIS FORENSE DE DISCOS
Se sospecha que un equipo informtico puede contener

archivos con informacin muy valiosa para aclarar ciertas
circunstancias en un proceso judicial. Se requiere a un
especialista en ciberseguridad con el objetivo de que realice un
anlisis forense para obtener estos archivos. En principio,
parece que se dispone nicamente de un disco duro, extrado
del equipo confiscado, y que es sobre el que deben realizarse
las pruebas pertinentes. Junto con el mismo, se dispone de un
escrito judicial en el que el juez encargado de la investigacin
solicita recuperar los archivos sensibles a la investigacin.
III.
OBJETIVOS
Para la realizacin del anlisis forense, se identifican los

objetivos parciales que se resumen a continuacin:
FASE 1: Preservacin de pruebas
1. Clonado del disco duro, siguiendo las tcnicas clsicas de
anlisis forense, para evitar la alteracin de la prueba original.
De este modo, todas las pruebas que se realicen sern llevadas
a cabo en una copia clonada exacta a la original, manteniendo
inalterado el disco duro original.
FASE 2: Localizacin de archivos con contenido sensible
a la investigacin
2. Recuperacin de archivos borrados y bsqueda de todos
aquellos que tengan un formato de inters para la
investigacin.
3. Bsqueda exhaustiva de todos los archivos almacenados
que tengan un formato determinado concordante con la
informacin que se desea buscar. Habr que tener especial
148
JNIC2015
a) Obtencin de una imagen clonada del disco duro

original.
b) Recuperacin de archivos borrados y anlisis de los
mismos.
c) Preprocesado para asegurar que los formatos de
archivos son los adecuados.
atencin a que el propietario del equipo no haya renombrado

las extensiones de los archivos en cuestin, con el objetivo de
ocultar su existencia, disimularla o confundir a cualquier otro
usuario del equipo.
IV. HERRAMIENTAS SOFTWARE Y MATERIAL
Bsicamente, se dispone de un disco duro original que es

preciso clonar para preservarlo (en realidad, una memoria USB
de pequeo tamao). Adicionalmente, se presenta en este
apartado el software utilizado durante las tareas de anlisis
forense, indicando (en la seccin de referencias) de dnde
puede obtenerse. Se ha optado por trabajar con software libre o
versiones de evaluacin, accesibles sin problemas.
Clonado de discos
Como material, se dispone del disco duro original (memoria
USB), que es preciso preservar. Por ello, se debe obtener una
imagen clonada del disco original, sobre la que se realizarn
todas las pruebas. Existen muchas herramientas para realizar el
clonado de discos. Una de ellas podra ser la que se ofrece
desde OSForensics: OSFClone, en conjuncin con ImageUSB
y OSFMount [1].
Tal y como se comentar posteriormente, tambin se hace
uso de la herramienta Eraser para realizar borrados seguros de
archivos. Esta herramienta puede encontrarse en [2].
Comprobacin de extensiones de archivos
En la web pueden encontrarse multitud de aplicaciones para
determinar la extensin ms probable de un archivo, en el caso
de que sta se desconozca o se desconfe de la que muestra.
Dado que es posible que los archivos hayan sido renombrados
a otras extensiones por el propietario del disco duro, con el
nimo de evitar su identificacin, resulta muy adecuado el uso
de este tipo de herramientas. Esta opcin se encuentra en los
objetivos 2 y 3, anteriormente enumerados. De entre todas las
posibilidades existentes, se seleccionan dos herramientas libres
muy simples, para tratar de asegurar de este modo que los
formatos propuestos concuerden adecuadamente: TrID [3] y
P10XB [4].
VI. FASE DE PRESERVACIN DE PRUEBAS

En este reto se facilitan las explicaciones correspondientes al
apartado a), la clonacin del disco duro original (memoria
USB), as como a los apartados b) recuperacin de archivos, y
c) comprobacin de extensiones.
En anlisis forense de discos, lo habitual es realizar un
clonado de unidades arrancando desde un Live CD o desde una
unidad flash USB. En la simulacin, se realizan los siguientes
pasos, previos a la clonacin de esta memoria USB
Preparacin de memoria USB
Clonar un disco duro puede llevar bastante tiempo,
dependiendo del tamao del mismo, del equipo con el que se
trabaja, de las herramientas utilizadas Para ilustrar todo el
proceso de forma sencilla, se procedi a preparar una memoria
USB del menor tamao posible (256 Mb en este caso), con una
serie de ficheros.
Dado que esta memoria USB se haba usado bastante con
anterioridad, copiando y borrando innumerables archivos, fue
preciso prepararla adecuadamente, realizando un borrado
seguro que impidiese recuperar, con posterioridad, archivos no
deseados en la simulacin. Para ello, se hizo uso de Eraser [2].
As se impide recuperar archivos antiguos que se hubiesen
eliminado de la memoria USB con anterioridad a su utilizacin
para este reto.
Recuperacin de archivos borrados

Para la consecucin del objetivo 2, en lo relativo a la
recuperacin de archivos borrados, tambin existen varias
posibilidades. De entre todas ellas, en este estudio se propone
el uso de MiniTool [5] y Pandora Recovery [6].
Figura 1. Borrado seguro con Eraser.
V. METODOLOGA
Siguiendo los objetivos marcados en orden cronolgico, ser
necesario realizar las siguientes tareas:
149
JNIC2015
Debe ejecutarse Eraser, en modo Administrador (Ejecutar

como Administrador). Con el botn derecho del ratn, se
selecciona una nueva tarea (figura 1). Se elige Run
immediately y se pulsa sobre Add Data. Se deben borrar los
ficheros, as como el espacio libre que queda en la memoria
USB y que puede contener archivos borrados hace tiempo.
Preparacin de archivos
Para la simulacin, se descargaron de internet 10 archivos
con extensiones diferentes, y con tamaos pequeos. Las
extensiones seleccionadas fueron algunas de las ms
habituales: RTF, DOC, DOCX, XLS, XLSX, PPT, PPTX,
PDF, JPG, BMP, GIF, PNG, MID, MP3, AVI, WMV, INI,
TIF, EXE, TXT
La relacin de archivos que se usa en este ejemplo se
muestra en la figura 2.a). Se plantea la idea de cambiar la
extensin de estos ficheros con el objetivo de simular que el
usuario del equipo ha modificado la extensin para dificultar el
seguimiento de los archivos. Bsicamente, se ha eliminado
directamente su extensin, en lugar de cambiarla a otra distinta.
Adems, se seleccionaron 5 archivos para borrarlos de la
memoria USB, lo que ilustra la figura 2.b), que muestra los
archivos sin extensin y a punto de ser eliminados.
Creando el Live Flash USB

El siguiente paso consisti en realizar el clonado de la
memoria USB, que contena 5 archivos en el directorio raz, y
otros 5 archivos borrados, tambin en el directorio raz.
Generalmente, para evitar la alteracin / modificacin de las
pruebas (discos duros, por ejemplo), en informtica forense
suelen utilizarse Live CDs para arrancar el sistema y proceder
a la fase de adquisicin de pruebas. Existen varias
distribuciones de Live CDs de anlisis forense en la web, que
permiten multitud de opciones. En nuestro ejemplo,
bsicamente se precisa realizar un clonado de un disco duro
(memoria USB). Para ello, bastar con disponer de una
herramienta de clonado (OSFClone [1]), que ser montada en
una unidad de arranque USB, en lugar de tener que generar un
CD de arranque, algo ms tedioso que la solucin que se
propone a continuacin.
De este modo, para clonar esta memoria USB (con la
herramienta OSFClone) se us la aplicacin ImageUSB [1],
que permite realizar una unidad flash de arranque a partir del
fichero descargado.
Tras descomprimir el archivo OSFClone.zip, se dispone del
fichero OSFClone.bin. Se debe disponer de un Pendrive para el
arranque, de al menos 2 GB, dado que no solo se copiar el
fichero OSFClone.bin, sino tambin un Core Linux de
arranque. Como es de esperar, se borrarn todos los datos que
contenga esta memoria USB de 2 GB. Al ejecutar
ImageUSB.exe, se abre la pantalla mostrada en la figura 3.
a)
b)
Figura 2. Archivos copiados en la memoria USB (a), y archivos sin
extensin y a punto de ser borrados (b).
Sobre la memoria USB que se ha preparado con anterioridad

(realizando un borrado seguro con Eraser), se procedi a copiar
en el directorio raz de la misma los 10 archivos sin extensin
que se muestran en la figura 2.a). Tras ello, se borraron 5
archivos, arrastrndolos a la papelera de reciclaje o utilizando
la tecla SUPR (es decir, se hizo un borrado no seguro de los
mismos). En la figura 2.b) se observa cmo se eliminan los
archivos que ocupan un orden par.
Figura 3. Creando el Live Flash USB.
Step 1. Debe seleccionarse la unidad USB que quiere

convertirse en unidad de arranque (en este caso, la unidad I:).
Step 2. Se selecciona la opcin Write to UFD, que viene
marcada por defecto.
Step 3. Se selecciona el archivo OSFClone.bin.
Step 4. Finalmente se graba el USB pulsando Write to UFD.
150
JNIC2015
Clonado de la memoria USB

Tras haber creado el Live FLASH, se introduce esta
memoria en un puerto USB y se arranca el equipo desde l
(para ello, se selecciona la opcin necesaria de la BIOS en el
arranque). Se arrancar un Tiny Core Linux, en el que habr
que presionar <Enter> para empezar y, posteriormente,
<Space> para continuar con el modo de vdeo por defecto.
Tras este proceso de inicializacin, aparecen las siguientes
opciones:
destination. A continuacin se eligen las opciones de copia,

opcin 3. Change options:
***********************************************
TodaysDate:XXXX
Pleaseselectanoption:
1.Clonecompletedrive
2.Imagecompletedrive
3.Imagespecifiedpartition
4.Computechecksumofdrive/partition
7.Selectkeyboardlayout(CurrentlyUSLayout)
9.ShutdownPC
0.Exit
>2
Se selecciona la opcin 2. Image complete drive. Se

muestra una ventana para elegir el formato de copia a usar,
como se observa en la siguiente imagen:
Pleaseselectformatyouwishtouse:
1.dd(viadc3dd)
2.AFF(requiresatleast256MBofRAM)
3.EWF(requiresatleast256MBofRAM)
>1
###OPTIONS###
Pleaseselectanoptiontochange:
#
Option
[1]
ChecksumMethod
[2]
Postdddstverify
[3]
Splitimagefile
No
[4]
Splitfilesize
2G
[5]
Compressimage
none
[6]
Compresslevel
[7]
BlockSize
[0]
Returntopreviousmenu
>1
Default
md5
Yes
6
1M
Como puede verse, por defecto aparece md5 como mtodo

de Checksum. Por seguridad, dado que en los ltimos aos han
quedado patente las colisiones producidas por md5, se procede
a cambiar el algoritmo por SHA256. Se seleccionar, por
ejemplo, la opcin 3. Sha256.
####Checksummethod####
Checksum method is currently set to 2md5,
defaultismd5
Please select which method you would like to
use,optionsarebelow.
ChecksumOptions:
1.md5
2.sha1
3.sha256
4.sha512
>3
Se selecciona la opcin 1. dd (via dc3dd). Tras ello, se

muestra un men que debe completarse por partes:
Finalmente, se marca la opcin 9. Execute dd. Se pedir
confirmacin y comenzar la copia. Con esto se tendr,
despus de un cierto tiempo (que variar en funcin del
hardware y del tamao de la clonacin), una imagen llamada
image.img en la particin de destino indicada (el nombre del
fichero de salida puede ser modificado si se selecciona la
opcin 4. Change image filename en el men principal).
Cuando finalice el proceso de clonacin de la imagen, se
preguntar al usuario si desea salvar un fichero de informacin
en la misma ubicacin del fichero de imagen:
Menuchoices:
1.Selectsource
2.Selectdestination
3.Changeoptions
4.Changeimagefilename
9.Executedd
0.Returntomainmen
>1
Se elige la opcin 1. Select source, el disco duro fuente,

esto es, la unidad que se quiere clonar. Tras ello, se selecciona
el disco duro/particin de destino, con la opcin 2. Select
Would you like to save an accompanying info

fileinthesamelocationastheimagefile?
(y,n)>y
151
JNIC2015
En este caso, se pedir el nmero de caso (Case #), el

nmero de evidencia (Evidence #), el nombre del analista
(Examiner Name), una descripcin (Description) y
localizacin/lugar (Location/Place).
Lo mejor de generar este fichero *.info (image.info) con la
informacin adicional es que, adems de estos datos
introducidos por el usuario, el sistema generar la firma del
fichero imagen (destacada en fondo amarillo, ms abajo), en el
formado seleccionado (sha256 en este caso), lo que servir
para validar la integridad del fichero y certificar que no ha sido
modificado con posterioridad, asegurando as la cadena de
custodia de las evidencias obtenidas.
Una vez que se disponga de esta imagen clonada, por
precaucin, se proceder a almacenar una segunda copia de
esta imagen en otra ubicacin, para evitar tener que proceder a
realizar nuevas clonaciones en el caso de que, por causas del
anlisis forense a realizar, la copia clonada se volviese
inestable. Este proceso se repetir cuantas veces sea necesario,
en caso de que se destruya la copia clonada donde se est
realizando el anlisis forense antes de la finalizacin de todas
las tareas necesarias.
ImagecreatedusingOSFClonev1.0.1008b
ImagecreatedonJul29,201317:46:11
BASICINFO:
Imagesource:/dev/sdd
Drivemodel:Unknown
Driveserialnumber:Unknown
IMAGEFILE(S):
image
Imagefilesize:255344280bytes
CHECKSUM:
Montando la imagen
As, se habr creado una imagen clonada de la memoria
USB, usando el formato de clonacin dd. Para poder montar
una imagen de este formato en Windows, se precisa la
aplicacin OSFMount [1], mostrada en la figura 4.
Figura 4. OSFMount.
Tras hacer clic en el botn Mount new aparecer la

pantalla de la figura 5, donde habr que seleccionar el archivo
imagen.
dc3dd7.0.0startedatXXXX
compiledoptions:
command line: dc3dd if=/dev/sdd bufsz=1M
hlog=hash.log
log=dc3dd.log
hash=sha256
of=/mnt/temp/OSFClone0/image
inputresultsfordevice'/dev/sdd':
0613d6b3bd5bc28e131df4556406a5d12ef9f4c3ca3e9285fff
9feca9550be6e(sha256)
output
results
for
file
'/mnt/temp/OSFClone0/image':
dc3ddcompletedatXXXX
Case#:
Evidence#:
ExaminerName:
Description:
Location/Place:
152
Figura 5. Montando la unidad USB.
JNIC2015
VII. FASE DE LOCALIZACIN DE ARCHIVOS CON CONTENIDO

SENSIBLE A LA INVESTIGACIN
Una vez que se dispone de la imagen clonada del dispositivo

a investigar, sabiendo que esta clonacin se ha realizado bit a
bit, es decir, que dispone de los archivos actuales y tambin de
los archivos que se hayan podido borrar, es cuando toca
realizar el anlisis de la misma. El objetivo sera recuperar
todos los archivos y ver si las extensiones se corresponden con
las adecuadas.

Es posible que el propietario del equipo haya borrado, previa
a la intervencin policial, determinados archivos. Por este
motivo, resulta importante realizar una bsqueda exhaustiva.
Para la consecucin del objetivo 2, en lo relativo a la
recuperacin de archivos borrados, tambin existen varias
posibilidades. EaseUS Data Recovery Wizard Professional [7]
y Stellar Phoenix Windows Data Recovery [8] son dos
aplicaciones comerciales de lo mejor que se puede encontrar en
el mercado. Como alternativa al software de pago, en [9] se
muestra una relacin de 15 aplicaciones gratis para recuperar
archivos borrados. Para el anlisis forense propuesto, este tipo
de aplicaciones libres es ms que suficiente. De entre todas
ellas, en este estudio se propone el uso de MiniTool [5] y
Pandora Recovery [6].
Indicar que siempre se proponen dos herramientas porque a
veces sucede que una herramienta no proporciona todos los
resultados deseados, y siempre es importante tener un plan B.
Incluso es cierto que, tambin a veces, unas herramientas
recuperan unos archivos y otras herramientas terminan de
recuperar otros ficheros distintos.
Con MiniTool, una vez instalada la aplicacin, sobre la

pantalla principal, bastar con indicar que se desean recuperar
los archivos borrados (opcin Undelete Recovery). Tras ello,
debe indicarse sobre qu unidad se desea realizar la
recuperacin de archivos. Al hacer clic en el botn Recover
aparecern los archivos que han sido borrados (Figura 6).
Una vez que se seleccione el botn Save files, habr que
indicar dnde se desean salvar los archivos marcados para
recuperar. En la siguiente pantalla se indicar, en color rojo,
que es recomendable (y lgico!) salvar los archivos
recuperados en otra unidad, ya que, en caso contrario, al
restaurar los archivos borrados sobre la propia unidad en que
haban sido borrados, se altera el contenido de la misma, y es
posible que se destruya otra informacin sobre la unidad que
est siendo investigada. Al ser una versin gratuita, la cantidad
de datos recuperados se limita a 1 GB, suficiente, al menos,
para el ejemplo presentado en este documento.
Por su parte, Pandora Recovery propone el uso de un
asistente, para guiar en el proceso global de recuperacin de
archivos. En el caso particular que nos ocupa, lo ms sencillo
es cerrar el asistente y realizar el proceso directamente
pinchando sobre la unidad en la que deseamos recuperar la
informacin (G: en este caso, como se aprecia en la figura 7).
Seleccionando los archivos (de los que es posible realizar
una vista previa), y pinchando en el botn de recuperar (opcin
Archivo + Recuperar en), simplemente habr que indicar
la ubicacin en donde se desean recuperar los archivos.
Figura 7. Archivos a recuperar con la aplicacin Pandora Recovery

sobre la unidad J:
Figura 6. Archivos a recuperar con la herramienta MiniTool sobre

la unidad J:
Una vez recuperados los archivos, habr que realizar el

procesado para asegurar el formato de estos archivos
recuperados (por si no correspondiese el formato del archivo
con la extensin con que fue recuperado), pero esta vez, sobre
la carpeta local que se haya creado al recuperar los archivos en
la unidad D:
153
JNIC2015
Procesado para asegurar formatos de archivos

Tras realizar la bsqueda sistemtica de archivos se
proceder a comprobar la correccin de extensiones de los
mismos, por si el propietario del equipo hubiera renombrado
las extensiones. Para asegurar el correcto formato de los
archivos (esto es, la extensin de los mismos) se dispone de
dos herramientas bsicas, que se presentan a continuacin.
La primera de estas herramientas es TrID [3]. Se trata de un
comando que permite identificar cualquier tipo de archivo.
Reconoce ms de 3700 tipos de ficheros. El programa extrae
patrones reconocibles y los compara con su propia base de
firmas. En caso de duda, mostrar todas las posibles
extensiones del archivo junto a un porcentaje de probabilidad.
La aplicacin consta de un archivo ejecutable (TrID.exe) y
de un archivo de firmas que tambin debe descargarse y
ubicarse en el mismo directorio que el ejecutable
(TrIDdefs.trd). Para su ejecucin, es preciso abrir la consola de
comandos (cmd). Al tratarse de un comando, puede analizar
directorios enteros. Adems, tambin permite corregir
automticamente las extensiones que detecte que son errneas
por las ms probables en cada caso (mediante el parmetro
ae). Posibilita al usuario conocer las primeras nn coincidencias
(parmetro r:nn), por si un archivo muestra probabilidades de
pertenecer a ms de una clase de ficheros. Finalmente, indicar
que se trata de una herramienta portable y que ocupa menos de
30 Kb.
A modo de ejemplo, se muestra la evaluacin de todos los
archivos de una ruta especificada (Figura 8):
La idea sera forzar la correccin de las extensiones,

parametrizando el comando trid con la opcin ae:
trid ae ..\..\ficheros2\*.*
En caso de que exista duda con algn archivo con respecto a
su extensin, se puede utilizar tambin la herramienta P10XB
[4]. Esta aplicacin lee el contenido de los 100 primeros bytes
de cada archivo, de modo que puede identificar el contenido
del mismo y, por tanto, la extensin ms adecuada. La
aplicacin consta de un archivo ejecutable (P10XB.exe) y un
archivo con la base de datos de marcas (marcas.ini), que
contiene la informacin necesaria para devolver la extensin
ms probable de cada archivo. La aplicacin slo permite abrir
archivos de uno en uno, por lo que puede resultar bastante
tedioso si se pretende chequear un gran nmero de archivos.
Sin embargo, como complemento a la aplicacin anterior,
puede resultar de utilidad, sobre todo con aquellos archivos en
los que pueda existir algn tipo de dudas sobre su formato, tras
haber sido analizado con TrID.
En la figura 9 se muestra un ejemplo de ejecucin.
trid ..\..\ficheros2\*.*
Figura 9. Comprobacin de la extensin de un archivo, mediante
P10XB.

De los trabajos presentados en el anlisis forense realizado,
se han recuperado los archivos que se mostraban en la figura
2.a).
Para cada uno de los archivos recuperados, tras un chequeo
de los mismos, se ha podido constatar que, efectivamente, la
extensin se corresponde con el tipo de archivo adecuado.
VIII.
Figura 8. Comprobacin de extensiones de archivos en la consola

de comandos, mediante TrID.
RECUPERACIN DE LA MEMORIA USB UTILIZADA TRAS

USAR OSFCLONE
Cuando se utiliza OSFClone con una memoria USB de ms

de 2 GB, sta quedar con un tamao de 2 GB. Para recuperar
el tamao original y recuperar as toda la capacidad de
almacenamiento hay que volver a formatearla. Si se realiza con
Windows, el espacio no se recupera totalmente con un simple
formateo, sino que habra que seguir los siguientes pasos:
154
JNIC2015
BIBLIOGRAFA Y REFERENCIAS
Abrir la consola de comandos y seguir los siguientes pasos:

[1]
1)DISKPART
2)LISTDISK(aparecerunalistadetodoslos
discosdelequipo)
3)selectdisk1(ojo!Hayqueseleccionarel
discoquesequieraformatear,enelcasodel
ejemplo,elDISCO1.Muchocuidadoconlas
equivocaciones).
4)clean
5)createpartitionprimary
6)formatfs=NTFS
7)exit
IX. RETO PROPUESTO

Para practicar todos los conocimientos adquiridos en este
trabajo, en [10] se presenta una imagen de una memoria USB
de tamao pequeo, que ha sido borrada de forma segura para
eliminar todos los archivos previos. Sobre ella, se han copiado
10 archivos de extensiones diferentes, y se han renombrados
con nombres F00, F01 F10. A estos archivos se les ha
eliminado tambin su extensin, para dificultar su
identificacin, y simular que el propietario de los mismos ha
camuflado sus archivos importantes. Tras copiar en la memoria
estos 10 archivos (con nombres genricos y sin extensin), se
han eliminado 5 de ellos para tratar de recuperarlos con
posterioridad. Es decir, todas las tareas del apartado VI de este
trabajo se han realizado ya sobre la memoria almacenada en
[10].
Sobre esta imagen, el reto propuesto consiste en realizar un
estudio forense para estudiar los ficheros existentes,
asegurando sus extensiones y buscando los posibles archivos
borrados que en ella existan. Es decir, se propone que se
repitan todas las tareas descritas en el apartado VII de este
trabajo.
X.
OSFClone / ImageUSB / OSFMount

http://www.osforensics.com/products.html
[2] Eraser
http://eraser.heidi.ie
[3] TrID
http://mark0.net/soft-trid-e.html
[4] P10XB
http://www.svcommunity.org/forum/salvadoreno/p10xb-no-te-preocupespor-la-extension-de-tus-archivos-nunca-mas!
[5] MiniTool
http://www.minitool.com
[6] Pandora Recovery
http://www.pandorarecovery.com
[7] EaseUS Data Recovery Wizard Professional:
http://www.easeus.com/datarecoverywizardpro
[8] Stellar Phoenix Windows Data Recovery:
http://www.stellarinfo.com/es/recuperaciondeinformacion.htm
[9] 15 aplicaciones gratis para recuperar archivos borrados
http://www.emezeta.com/articulos/15-aplicaciones-gratis-para-recuperararchivos-borrados
[10] La imagen USB clonada bit a bit para realizar el reto:
https://mega.nz/#!uwNBGaAS!b0oan1JRr9emCG_8p21OKMVE8P1RMnjH25MsnmbaaM
CONCLUSIONES
El presente reto ilustra cmo realizar un clonado de un disco

duro sospechoso de contener informacin sensible en una
investigacin, para preservar inalterada esta prueba.
Tambin se expone el procedimiento para recuperar archivos
borrados en la copia clonada del disco duro confiscado, y la
forma en que se verifica que la extensin de los archivos
existentes en el disco duro es correcta.
Por ltimo, se propone un enlace a un archivo imagen de una
clonacin de otra memoria USB para que el usuario practique
la recuperacin de archivos y la comprobacin de extensiones
de los mismos.
Siguiendo estos pasos, puede decirse que cualquiera que
supere este reto estara en condiciones de realizar un anlisis
forense de cualquier disco duro.
155
JNIC2015
Research-to-market transition in European

cybersecurity projects
Aljosa Pasic
Atos Spain
Aljosa.Pasic@atos.net
Abstract - One of the main goals of SecCord project is to

analyze the portfolio of European cybersecurity research results
and map it to the ongoing ICT security market trends in order to
find the gaps and potential strategies for the future directions in
research-to-market transition. The methodology combines
analysis of industry priorities (e.g. derived or linked to trends,
strategic agenda, demand etc) with a bottom up information
gathering from EU projects (e.g. survey, face to face interviews,
etc.). We present several findings from this analysis, together with
the identified constraints, best practices and recommendations.
I.
results transition. The methodology combines use of market

or industry mapping issues (e.g., market trends, tech watch,
strategic agenda, demand mapping etc) with a bottom up
approach of experience gathering from EU projects (e.g.,
stakeholder survey, face to face interviews, etc.).
The remaining part of this paper is structured as follows:
the essence of industry requirements and setting priorities for
research projects is analyzed in the chapter 2, while research
outcomes translation and technology transfer is described in
the chapter 3. Analysis of drivers and barriers, in the specific
context of FP7 programme and the transition towards the
recently started H2020, is described in the chapter 3. We end
with the description of success stories and the conclusions.
We should mention that readers wishing to have more
details should check public deliverables of SecCord project1
or CSP forum2 website (this forum is set up by SecCord but
is expected to live beyond the project lifetime).
INTRODUCCIN
Research projects often view cybersecurity challenges in

isolation and it can happen that fragmented and marketdisconnected approach leads to weaknesses in the
exploitation and research-to-market impact. From a financial
perspective, it is possible to optimize expenditure on security
research in line with the industry priorities. From an
operational perspective, however, security research efforts
may not achieve the intended impact due to the time
mismatch: market is often looking for the right solution in
the right moment. Research results are at risk to arrive too
late or too soon.
Superior research results or technology is not a guarantee
for the market success. Research efforts might fail to
consider how humans react to and use technology. They also
have to understand market specifics for security and privacy,
for example, how the overall value chain depends on
different IT services, from consulting to operations. Any
security market model must recognize and accommodate
dynamic relationships, as well as the fast evolving trends.
SecCord is EU co-funded coordination and support action
that provides services for the Trust and Security (T&S)
research part of FP7 and H2020 programmes. Among its
objectives, SecCord aims at analyzing the potential and
market impact of T&S project results by maintaining a
catalogue and showcase of results, highlighting best
practices, and by interpreting and matching them against usecases of current and foreseen market trends.
This paper provides a selection of the main findings
regarding research-to-market transition, as well as the
selection of best practices from various EU cybersecurity
projects. Over three years, the portfolio of FP7 research
results was analyzed, in order to find the gaps and potential
strategies for the future directions in research to market
II. CURIOSITY VERSUS MARKET DRIVEN

RESEARCH
The majority of industry-driven strategic research agendas
(SRA) produced in the recent years for security and privacy
research, as well as more focused CYBERSECURITY
AREA roadmaps (e.g. from two networks of excellence,
namely crypto and secure software engineering), are
produced with some kind of bias. This is natural, since the
positions reflect particular organizations or researcher
interests. One of the main shortcomings of SRA-driven
approach for setting future research priorities is the lack of
involvement of cybersecurity demand side that is end users,
which, in the general terms, is also poorly represented in
initiatives such as the NIS platform. Another problem that we
analysed in SecCord is discussing future priorities at the
1
2
156
http://www.seccord.eu/
http://www.cspforum.eu/
JNIC2015
different level of abstraction. Challenges, incl. societal

challenges that are more integrated to security research in
H2020, are often used to describe priorities, while
evergreen topics such as identity or privacy usually get
repeated year by year without clear description or reasoning
why the particular research topic has priority right now.
Impact assessment [1] reports are commonly used by the
European Commission (EC) to analyze research-to-market
constraints, barriers or challenges, but cybersecurity (or Trust
and Security, as it was called in the start of SecCord project)
area represent also a set of specific issues.
During the past three years many ICT security vendors, as
well as traditional defense market players, are restructuring
their offering and are becoming increasingly labeled as
cybersecurity companies. However, the questions that are
most frequently raised on the demand side, remain the same:
What exactly do I need? What applies to my business? How
should I compare different (cyber) security solutions? This
is why demand side segmentation, as well as alignment of
priorities from both supply and demand side, when it comes
to future research directions, becomes a priority in strategic
agenda. This can be exemplified by the case of SME: while
SME supply chains are often critical in certain market
segments, their cybersecurity profiles and needs have been
notable absent from research agendas. This is also why
Network and Information Security (NIS) platform working
group 3 (WG3) structures its strategic research agenda [2]
around three areas of interest (AoI) which represent
perspective of Individuals Digital Rights and Capabilities,
Resilient Digital Civilisation and Trustworthy (Hyperconnected) Infrastructure. Along these AoIs, three subgroups
were formed aiming at further elaborating the areas. After the
initial elaboration of each Area of Interest, a cross analysis
phase was performed in order to verify the presence of
commonalities among enablers/inhibitors for different AoIs
as well as possible conflicts, e.g. an enabler for an AoI
becomes an inhibitor for another one.
In contrast to demand driven research or innovation driven
research, which is not necessarily delivering superior
technology, but rather fit-for-market solutions, curiosity
driven research often relies on assumptions, such as no
legacy. Security for ICT professionals, on the other hand,
such as basic crypto or secure software engineering, is
stressing importance of awareness by the vast majority of
developers, as well as organizations. Good news is that
services, testbed and toolkits, for example, are increasingly
available for providing support for the modelling of highlevel requirements that are expressed in terms of abstract
concepts such as compliance, privacy or trust. In this way the
gap between ICT professionals, digital natives or
experienced developers and the rest of mortals could be
bridged or at least reduced.
When we look at dynamics of cybersecurity research
priority settings, there is often a gap between demand-side
and supply-side industry. Managing demand-side
expectations (and customer itself) are becoming one of the

key to success on the market. When it comes to research
projects, however, demand side if often unable to predict the
future requirements or trends, which clashes with the EU
research project format and style.
Effective and efficient security, terms used often in
security metrics, are often differently understood by demand
and supply sides. In a matter of fact, cybersecurity research
results often do not fit well operational context of the final
user, so the actual use case is never transferred to a business
case.
Two other two topics where we noticed gaps in research
topic selection and priority setting are the importance of
socio-technical issues and cybersecurity risk appetite.
Demand side, the final user, starts from the particular
operational context, with their procedures and people who
are finally responsible for research results technology
acceptance. Ability, capacity, bias, attitude, cultural
differencesare some of the factors that have been
considered by research-to-market transition but are often
neglected in actual research projects and their exploitation
plans. Risk appetite, on the other hand, has more impact on
preparedness of an organization as a whole. While personal
attitude (I click on that file, I have nothing to lose, I have
nothing to hide) is normally addressed through enforcement
of organizational security policies or awareness campaigns,
the overall organizational risk attitude and risk management
is something that strongly varies across sectors, countries or
sizes of company, and this is where further segmentation and
priority setting exercise come into the picture for demandsupply matching and driving of research priorities.
III.
FP7 CYBERSECURITY RESEARCH-TOMARKET SUCCESS STORIES
The problem of translation of results is not exclusively

problem between academics and industry. Even within large
organizations that participated in FP7 cybersecurity projects,
translation and transition problems start already with the
project proposal where there is no clear business unit or
organization branch actually in charge of commercialization.
The problem is less present within SME participants that do
not have separated research lab department or even separated
legal entity in charge of research projects. The actual analysis
of stakeholder roles, characteristics (e.g. innovation model in
different organizations) etc., was done in SecCord
deliverables and it was reused by NIS platform, in order to
reveal importance of business motivation behind
participation in FP7 research projects. Academic research
driven projects, on the other hand, tend to emphasize
importance of a product, and only recently there was a
change in this trend by including more service companies,
consultants or auditors, as well as ecosystem organizations
such as market analysis or even pure marketing companies.
157
JNIC2015
Once that value proposition is identified and described, not

in terms of technological superiority, but rather in business
and market terms, exploitation risk assessment is taking
place, addressing issues such as:
Fragmentation of ownership
User requirements that do not fit project lifecycle
and needs
Assumptions and simplifications done in the
research project
Lab versus operational environment
Maintenance issues (know-how, costs etc.)
In the previous SecCord year catalogues have already
identified few positive examples and have compiled success
stories brochure [3]. The selection of success stories was
based on assessment done through iterative research-toindustry mapping (see table in the annex to this paper) with
feedback collection and face to face interviews.
Some of the most successful project have been already
reused by another project e.g. SEMIRAMIS project result
became attribute collection service ACS used by many EU
member states in Stork2.0 [5] innovation project, as well as
listed as a building block (BB) in European eSense [7]
reference architecture and Strategic [4], another two
innovation projects. The research result is now in operational
environment of infrastructure that supports mutual
recognition of eID several EU member states. In a similar
way, FIWARE [6] security enablers were reusing results of
PrimeLife (privacy), Consequence (data handling), Posecco
(security monitoring) and Serenity (context aware
reconfiguration) projects. However, after integration and
performance problems were reported by FIWARE users, the
new set of generic enablers, developed from the scratch, are
now used by FIWARE applications.
If we look at other related FP7 research projects, we could
classify research topics into several categories:
Crypto: Research on cryptographic algorithms and
protocols. This research is often targeting laws of
the existing protocols and is trying to improve
them. One of the best examples is Direct
Anonymous Attestation (DAA) which detected
flaws in remote attestation, one of the basic
concepts of Trusted computing. Hybrid approach
is combining DAA and privacy CA (certification
authority), while another extension of DAA is
called enhanced privacy ID (EPID). Companies
such as IBM, HP or Intel have been involved in
these research efforts and are offering some of
research results as a part of their offerings.
Architectures: Research on runtime security,
spanning various infrastructure elements such as
event monitoring, assessment and automated
reaction. The approach is used for enforcement of
different policies e.g. privacy, SecLA (security
level agreement) etc., but also for the evolution of
management and detection tools. Among projects
that target evidence gathering for continuous

monitoring based audit and certification, there is
CUMULUS, while monitoring SecLA is
developed in ABC4Trust and used in SPECS.
PLA monitoring is topic in A4cloud project,
while MASTER was monitoring security policy
in general. Similar to A4Cloud, the project
SECCRIT also aims to develop technologies to
lawfully monitor and record service data together
with on-the-fly anonymization of data to meet EU
privacy directives. This recorded data can later be
used to assist a root-cause analysis in case of a
service failure. Research results from this area are
still waiting to be adopted by the market, partially
because of their intrusiveness and partially due to
the assumptions about infrastructure readiness
(e.g. availability of continuous monitoring of
events at different layers).
Policies and languages: Research on information or
data-centric approaches is focusing on policies,
languages, machine readable representations etc.
Some of this research assumes the use of
semantic technologies for data representation and
exchange, and expressing requirements as formal
policies. Another approach, sometimes referred as
sticky policy, attaches policies that restrict
isolated uses of data to the data directly, so that
systems exchange data, but also exchange the
policies pertaining to the exchanged data.
ASSERT4SOA is one example of projects in this
category, the other ones being Consequence or
Coco-cloud. The role of machine readable
agreements in digital single market (privacy level,
security, data sharing etc), their monitoring and
enforcement has been analyzed in [8] or [9].
Machine learning: research on e.g. analytics,
prediction of future vulnerabilities, a process
mining tool (prosecco), dealing with untrusted or
incomplete evidences, risk reasoning etc.
MASSIF and PDA tool from Fraunhofer is one
example.
Others: Tools, models and schemes can be found in
many research projects, from visualization of
large data sets (VIS-SENSE) to certification
scheme in CUMULUS. Model based refinements
(security/risk/testing) and
other assurance
techniques can be found in NESSoS Network of
excellence, SpaciOS or Avantssar projects.
For a more detailed analysis and mapping of research
results, into the global trends such as big data, internet of
things or cloud computing, we refer reader to SecCord
deliverables.
IV.
158
CONCLUSIONS
JNIC2015
[8] Enabling Trusted European Cloud: Atos white paperavailable at

http://atos.net/content/dam/global/documents/we-do/atos-white-papertrusted-european-cloud.pdf, last access 29/07/2015
[9] Atos blog entry on digital single market: https://ascent.atos.net/digitalsingle-market-building-trust/, last access 29/07/2015
For many years, analysis of research projects impact on

market was focusing on constraints, such as an excessive
time from proposal preparation to the end of the project. In
H2020 this time has been reduced, with instruments like
innovation actions or introduction of TRL (technology
readiness level) requirements. It has also been stated that
research fails to provide basis of innovation, that the
opportunity is not recognized on time, or that a potentially
successful product failed to catch on due poor marketing or
just unfortunate market dynamics.
Besides the analysis of constraints, SecCord has also been
looking at best practices from FP7 cybersecurity research
projects such as having results launched even after the first
year of the project (this is for example now expected in
innovation action instrument in H2020). Result oriented
structure of projects and result oriented partners should be
dominant in cybersecurity, as opposed to the tick the box
attitude, and project oriented mind (the majority of web sites
is still informing about e.g. project meetings and not about
concrete results). In this paper we have analyzed researchto-market impact from complementary perspectives. On one
side there is industry led research priority setting, that has
been changing since FP6 European technology Platform
(ETP) towards the more weighted, balanced and all-inclusive
approach. On the other side are actual results from FP7
research projects among which are also results that will
never cross the chasm to the market, even if they achieved
technological goals set in the project proposal. Somewhere in
the middle are vaguely described value propositions such as
stronger security, fine-grained policy or higher
assurance that sometimes do not find echo on the market,
especially on the demand side. The future, we envisage, will
shift focus towards key research-to-market transfer
indicators, with demand driven and defined parameters such
as effectiveness, efficiency and transformation, as well as
quick win approaches (e.g. iterative prototyping) during the
project lifecycle. Flexible instruments (e.g. open calls for
pilots or validations with customers, innovation awards) are
already being used in the other ICT innovation area, and it is
expected they could help in crossing the cybersecurity
research-to-market chasm.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
European Commission (2011) Impact Assessment, Communication

from the Commission 'Horizon 2020 - The Framework Programme for
Research and Innovation, EC Brussels, 30.11.2011
Strategic Research Agenda, WG3 Network and Information Security
(NIS) Platform, to be published in September 2015
FP7 ICT Trust & Security Success Stories & Projects Handbook,
available at: http://ec.europa.eu/digital-agenda/en/news/trust-andsecurity-fp7-success-stories-and-handbook, last checked 29/07/2015
Strategic web site: http://www.strategic-project.eu/
Stork2.0 web site: https://www.eid-stork2.eu/
FIWARE web site: https://www.fiware.org/
eSENS web site: http://www.esens.eu/
159
JNIC2015
Cyber Ranges for Cybersecurity Training: Challenges

and Novel Approaches
Jorge Lpez Hernndez-Ardieta, Pascual Parra Lpez, David Santos Esteban, Javier Martinez-Torres
Cybersecurity Research Group, Indra Digital, Indra
{jlhardieta, pparra, dsesteban, jamtorres}@indra.es
Keywords: cybersecurity training; cyber range; computer-based training

Work published in:
Jorge L. Hernndez-Ardieta. Training in Cybersecurity: Challenges and Novel Approaches. NATO
Communications & Information Agency Industry Conference and AFCEA TechnNet International
(NITEC15), 7th May 2015. Madrid, Spain.
Jorge L. Hernndez-Ardieta, David Santos, Pascual Parra, Juan E. Tapiador, Pedro Peris-Lpez, Javier
Lpez, Gerardo Fernndez Navarrete. An Intelligent and Adaptive Live Simulator: A new Concept for
Cybersecurity Training. 9th Future Security Conference. Berlin, Germany. 2014.
ABSTRACT
The consolidation of cyber threats as a primary concern of
governments, the industry and society in general along with the
ever increasing diversity and complexity of technology lie
behind the recent explosion in the demand for highly skilled
and trained cybersecurity professionals. In regard to this, much
effort has been expended and many initiatives have been
pursued in recent years, both from academia (e.g. graduate and
postgraduate specialisations), industry (e.g. professional
certifications, training programmes, technological training
platforms) and governments (e.g. standardisation of training
curricula, joint education and training programmes at
international level). In spite of this, the reality shows that the
number of proficient cybersecurity professionals produced is
still lagging behind the actual needs and, contrary to what may
be expected, the situation is getting worse.
In this talk we will introduce and analyse the key challenges
that we observe in cybersecurity training, that require an urgent
response if we want to redress the imbalance between the offer
and demand for cybersecurity professionals. Amongst these
challenges we find issues such as cost-effective hands-on
training, specialisation diversity, entry knowledge barriers,
flexibility to deal with organisations with high rates of staff
rotation, continuous training, and rapid adaptation to new
threats and the evolution of technology.
Traditional cybersecurity training platforms, such as those
supporting individual computer-based training or e-learning,
have long been the only way to implement training
programmes in cybersecurity. More recently, the introduction
of cyber ranges has redefined how cybersecurity training is to
be approached. A cyber range is a virtual environment
typically built on top of standard hardware that is used for
hands-on training, experimentation, test and research in
cybersecurity, and that is intended to support multitenant

activities. Cyber range solutions are gaining attention as a key
ally to support cost-effective training programmes in different
civil and military contexts. Actually, during the last few years a
number of cyber ranges for cybersecurity training have been
developed, both from the academy and the industry, as a
response to meet the market demand.
However, the results of a market analysis performed by the
authors show that current cyber ranges still present limitations
that leave most of the aforementioned challenges unanswered.
Consequently, there is still an urgent need for innovating new
approaches that solve the open problems. In particular, we will
explore advanced technical capabilities that could be
incorporated into cyber ranges, and that eventually may help to
turn around the current offer-and-demand problematic
situation.
To conclude, we will introduce iPhalanx, the solution that
Indra has recently released, and which represents a nextgeneration cyber range that, in our opinion, provides a
comprehensive and innovative answer to the challenges
identified.
ACKNOWLEDGEMENTS
The first prototype of iPhalanx was produced in the SACO
project. SACO was partially funded by the Spanish Ministry of
Economy and Competitiveness under the INNPACTO 2011
programme, Plan Nacional de Investigacin Cientfica,
Desarrollo e Innovacin Tecnolgica 2008-2011, ref. PT-20111593-390000.
160
JNIC2015
Metodologa para el Anlisis, Auditora de Seguridad

y Evaluacin del Riesgo Operativo de Redes
Industriales y Sistemas SCADA (MAASERISv2.1)
Dr. Fernando Sevillano
Industrial Cybersecurity by Logitek
fernando.sevillano@logitek.es
Dra. MartaBeltrn
Universidad Rey Juan Carlos
marta.beltran@urjc.es
Resumen-. Dentro del proceso de mejora continua de la

ciberseguridad industrial aparece siempre como primer paso o
etapa la necesidad de analizar e identificar los principales activos
y vulnerabilidades asociados a los entornos OT (Operation
Technology) y llevar a cabo una gestin y evaluacin integral del
riesgo operativo. Para realizar este anlisis y evaluacin, es
necesario contar con metodologas especficas que tengan en
cuenta la idiosincrasia particular de estos entornos de operacin.
En este artculo se propone MAASERISv2.1 como Metodologa
para el Anlisis, Auditora de seguridad y Evaluacin de Riesgo
operativo de redes Industriales y sistemas SCADA.
I.INTRODUCCIN
La ciberseguridad es una preocupacin cada vez ms
importante en los entornos de operaciones industriales y de
infraestructuras (tambin llamados Operation Technology-OT).
Como parte del proceso de mejora continua de la
ciberseguridad o de incremento del nivel de madurez de estos
entornos (hoy en da todava bastante bajo en comparacin con
los entornos IT transaccionales), suele aparecer la necesidad de
analizar e identificar los principales activos y vulnerabilidades
asociados a los entornos OT y llevar a cabo una gestin y
evaluacin integral del riesgo operativo. Con esto queremos
distinguir este anlisis de otros tradicionales y ms asociados al
riesgo estratgico, como se discutir posteriormente en este
documento.
Esta necesidad no slo surge en empresas y en
organizaciones privadas que estn preocupadas por
incrementar la seguridad de sus activos, procesos e
instalaciones (asociada directamente a su productividad, algo
que estn comenzando a comprender ahora), sino que a nivel
gubernamental, tambin es considerada. La publicacin a nivel
mundial de leyes y normativas que obligan a operadores
crticos que suministran servicios esenciales a realizar este
ejercicio, es prueba de ello. Por ejemplo en Espaa, la Ley
8/2011 de Proteccin de Infraestructuras Crticas (ley PIC),
obliga a los operadores catalogados como crticos a llevar a
cabo, dentro de los Planes de Seguridad del Operador (PSO),
un anlisis de riesgos en los que se incluya un inventario de
activos que soportan servicios esenciales, una identificacin y
evaluacin de amenazas y una valoracin y gestin del riesgo.
Para realizar este anlisis, existen diferentes metodologas de

evaluacin y anlisis de riesgo a alto nivel (asociadas riesgo
estratgico) y por otro lado existen mejores prcticas
propuestas por diferentes instituciones para analizar de forma
exhaustiva vulnerabilidades especficas asociadas a los
sistemas que se encuentran en los entornos de operacin.
Teniendo en cuenta este contexto, la principal aportacin de
este artculo es proponer una metodologa que se denomina
MAASERISv2.1, acrnimo de Metodologa para el Anlisis,
Auditora de seguridad y Evaluacin de Riesgo operativo de
redes Industriales y sistemas SCADA, que permite cubrir este
hueco conceptual y funcional entre dichas metodologas de alto
nivel y mejores prcticas a un nivel mucho ms concreto y
asociado a los sistemas.
Para eliminar las barreras que auditores y consultores se
encuentran a la hora de adaptar y/o utilizar metodologas de
anlisis y auditora de IT clsicas, se propone MAASERISv2.1,
como una metodologa que considera la idiosincrasia particular
de los entornos de operacin, en los que existen dispositivos,
sistemas y protocolos especficos y en los que el aspecto de la
disponibilidad, suele primar sobre otros como la integridad o la
confidencialidad.
MAASERISv2.1 permite realizar un gestin del riesgo
operativo y sus entregables pueden complementar a otras
metodologas de evaluacin de riesgos como MAGERIT,
CRAMM o MIGRA por poner tan slo unos ejemplos.
Este trabajo ha sido posible gracias a la estrecha
colaboracin existente entre Industrial Cybersecurity by
Logitek,
consultora
tecnolgica
especializada
en
ciberseguridad industrial y la Universidad Rey Juan Carlos. La
colaboracin pblico-privada y un correcto procedimiento para
la transferencia tecnolgica son factores clave que han
permitido desarrollar esta metodologa y comenzar a aplicarla
durante el ao 2015 en diferentes proyectos reales en sectores
como el alimentario, el farmacutico o el del ciclo integral del
agua.
Este artculo se estructura de la siguiente manera. En la
seccin II se presentan las diferencias existentes entre los
entornos IT y OT y cmo es necesario abordar programas de
161
JNIC2015
ciberseguridad distintos en ambos entornos, pero siempre

alineados y convenientemente integrados. En las secciones III
y IV se hace un recorrido por los conceptos de amenaza,
vulnerabilidad y riesgo, y por las metodologas y herramientas
ms habituales para el anlisis y la gestin del riesgo. Por
ltimo en la seccin V se presenta el alcance funcional de
MAASERISv2.1 y se presentan las principales conclusiones y
lneas de investigacin futuras en la seccin VI.
II.SEGURIDAD IT VS OT
El concepto Ciberseguridad Industrial est incluido en el
mbito de la seguridad industrial, entendiendo que la
informacin, sistemas e instalaciones deben ser protegidos de
ataques y amenazas originados principalmente a travs de
medios tecnolgicos.
El diseo de programas especficos dirigidos a reducir o
mitigar dichas amenazas debe hacerse teniendo en cuenta que
deben velar por asegurar: la disponibilidad de las instalaciones,
de los procesos de fabricacin y de los sistemas de control
(PLC, DCS, RTU, SCADA, HMI, MES); la integridad de los
desarrollos y de las configuraciones de los dispositivos de
campo y redes industriales, as como la comunicacin entre
ellos a travs de protocolos especficos (Modbus, Profibus,
OPC, Ethernet/IP, DNP3, etc.) y la confidencialidad de la
informacin que estos sistemas manejan. Tambin es esencial
garantizar un correcto control de acceso a los sistemas, datos y
procesos asociados a estos entornos mediante los esquemas
IAAA adecuados y con una eleccin del grano de control de
este acceso coherente.
El entorno o la red en la que convergen los sistemas, equipos
y protocolos antes nombrados, recibe el nombre de red
industrial. La literatura relacionada con la ciberseguridad
industrial la denomina Operation Network u Operation
Technology con el objetivo de diferenciarla de la red que
agrupa sistemas transaccionales (IT Network o IT
Technology).
Mientras que en el mbito IT la incorporacin de polticas,
procedimientos y estndares que eliminen o mitiguen las
amenazas, vulnerabilidades y riesgos asociados a estos
entornos es una prctica habitual, en los entornos OT, su
introduccin est siendo ms costosa debido principalmente a:
la falta de concienciacin de las organizaciones sobre el hecho
de que, es en estos entornos en los que se produce, suministra o
fabrica el ncleo de su actividad y su no disponibilidad y/o
alteracin puede causar prdidas y daos considerables que
afectan directamente a la cuenta de resultados; la falta de
procedimientos y estndares claros que ayuden a desplegar
programas especficos de ciberseguridad industrial y por
ltimo, la idiosincrasia particular de los equipos, sistemas,
redes y protocolos de comunicacin utilizados en estas redes de
operacin. En cualquier caso, en los ltimos aos ha crecido el
inters por este tipo de programas entre las organizaciones
industriales por diferentes motivos. En primer lugar, la
seguridad de las plantas industriales e infraestructuras crticas
se ha visto cada vez ms amenazada en los ltimos aos con el

surgimiento de diferentes formas de APTs especficas como
Stuxnet, Duqu, Flame, Shamoon, Dragonfly, Sandworm o
Laziok y la realizacin de acciones relacionadas con el
ciberterrorismo y el cibercrimen (ataques orientados a
perjudicar a la competencia, a la extorsin, al robo de
propiedad intelectual, etc.). Otros puntos importantes que han
ayudado a acelerar el diseo de programas especficos de
ciberseguridad industrial, son la proliferacin del acceso web a
los sistemas SCADA, la adopcin de los paradigmas Cloud,
mvil y BYOD (Bring Your Own Device) y la estandarizacin
de tecnologas IT en el mbito industrial. Esta estandarizacin,
que facilita la integracin de informacin y de aplicaciones
entre redes IT y OT, tiene un aspecto negativo, que es que el
entorno industrial pueda verse afectado por las mismas
vulnerabilidades y amenazas asociadas al entorno IT heredando
as sus debilidades. Lo peor, es que en muchas ocasiones, la
criticidad y especificidad del entorno industrial no permite
implementar las mismas contramedidas que en un entorno IT
tradicional.
Existen claras diferencias entre los mbitos IT y OT, que
justifican la necesidad de abordar del desarrollo e implantacin
de programas de ciberseguridad industrial especficos que estn
alineados con las polticas de seguridad IT de la organizacin.
En la tabla 1 se resumen los aspectos que hacen que ambos
entornos requieran de aproximaciones distintas cuando se
abordan programas de ciberseguridad.
162
IT
Confidencialidad,
Integridad y
Disponibilidad
2/3 aos con la
existencia de gran
nmero de
proveedores
Prctica habitual que
conduce a inversin
en ciberseguridad
Habitual e integrado
en la operacin
Comn , fcil de
actualizar y con
polticas bien
definidas y
automatizadas
Normativas genricas
Utilizacin de las
metodologas
estndares ms
actuales
Fcil despliegue y en
ocasiones carcter
obligatorio
Aspecto
Objetivo
OT
Disponibilidad,
integridad y
confidencialidad
Ciclo de vida
10/20 aos con

reducido nmero de
proveedores especficos
Evaluacin
cuantitativa del riesgo
Prctica realizada si es
obligatoria
Desarrollo de sistemas
de gestin de la
seguridad
No habitual y no
integrado
Antivirus y parches
Cumplimiento
normativas
Testeo y auditoras
Respuesta a
incidencias y anlisis
forense
Poco habitual por la

criticidad de los
sistemas, complejo de
desplegar y actualizar
Normativas especficas
y/o sectoriales
Test especficos e
inexistencia de
metodologas
estndares
Poco
habitual,
no
realizndose
anlisis
forense
Tabla 1. Diferencias entre ciberseguridad IT y OT
JNIC2015
III. TIPOS DE AMENAZAS, RIESGOS Y

VULNERABILIDADES EN ENTORNOS OT
Aunque en esencia las definiciones tradicionales de estos
tres conceptos son aplicables cuando se trasladan al entorno
industrial y/o de infraestructuras crticas, a continuacin se
procede a incorporar una serie de matices en dichas
definiciones.
A. Amenaza
En los entornos OT se define una amenaza como la causa
potencial de un incidente no deseado, el cual puede resultar en
un dao sobre un sistema vinculado a la red de operacin o a
los procesos industriales que se llevan a cabo o al entorno
fabril en el que dichos sistemas y procesos convergen.
La European Union Agency for Network and Information
Security (ENISA) ha publicado recientemente el informe
ENISA Threat Landscape 2014 en el que se detallan las
principales ciberamenazas emergentes que afectan actualmente
a las organizaciones y en el que se analizan los principales
vectores de ataques utilizados [1]. Dentro de este informe, en
su pgina 60, se hace mencin especfica a lo que ENISA
denomina como Cyber Physical Systems (CPS, lo que en este
artculo se ha definido como red o entorno OT) y su relacin
con la proteccin de infraestructuras crticas. Es decir, el
informe analiza la importancia que tiene este tipo de sistemas
para realizar eficientemente los procesos asociados a
organizaciones industriales o vinculadas al sector energtico y
cmo el ataque y/o alteracin de estos, est estrechamente
relacionado con la proteccin de infraestructuras crticas.
Adems, el informe identifica las diez ciberamenazas
emergentes que afectan directamente a los CPS: la aparicin de
malware especfico o malware que utiliza vulnerabilidades
asociadas a los sistemas CPS para alcanzar sus objetivos,
aparece en el primer lugar de las amenazas emergentes. Le
siguen las amenazas producidas utilizando como vectores de
ataque los entornos web (en los que se incluyen el spam o el
phising), el dao fsico o robo causado en entornos industriales,
la existencia del usuario interno malicioso y el ciberespionaje,
el robo de identidad, inyecciones sobre sistemas de
historizacin y directorios activos y el robo de informacin
confidencial. Cabe mencionar con los ataques de DDoS no se
incluyen en esta clasificacin por no tratarse tanto de una
amenaza, sin ms bien del efecto que se puede causar sobre un
entorno industrial utilizando para ellos distintos patrones de
ataque.
B. Vulnerabilidad
Por otro lado, se define vulnerabilidad como una debilidad
de un activo o control que puede ser explotada por una o ms
amenazas. Aunque existen numerosas formas de clasificar las
vulnerabilidades, fundamentalmente existen tres grandes
familias: de cdigo, de arquitectura y de procedimiento.
Las vulnerabilidades de cdigo son las que presentan las
tecnologas, productos y/o dispositivos que comercializan los
diferentes fabricantes, los desarrolladores o las comunidades de

cdigo libre. Es decir, como mnimo, todas aquellas que se
recogen en el Common Vulnerabilities and Exposures (CVE)
estaran incluidas aqu. Adicionalmente, existen bases de datos
de vulnerabilidades especficas para entornos industriales.
Entre ellas destaca la que proporciona el Industrial Control
System Cyber Emergency Response Team (ICS-CERT), en la
que pueden observarse todas las vulnerabilidades de los
principales fabricantes de dispositivos y sistemas industriales.
Adems, cabe mencionar, que estos a su vez, disponen de
espacios web y de boletines especficos en los que se detallan y
amplan dichas vulnerabilidades.
Las vulnerabilidades de arquitectura son las que se producen
al desplegar estas soluciones en el entorno de produccin,
pudiendo ser de software, hardware o comunicaciones. En este
caso, tambin se habla de debilidades ms que de
vulnerabilidades. De hecho, en paralelo al CVE, se ha
desarrollado el Common Weakness Enumeration (CWE) con el
propsito de realizar esta diferenciacin entre vulnerabilidad
(de cdigo) y debilidad (de arquitectura, relacionada ms bien
con el despliegue que con el diseo).
Por ltimo las vulnerabilidades de procedimiento son las
que se producen por negligencias o malas prcticas de los
usuarios o de los administradores.
C. Riesgo
Se define el riesgo como la probabilidad de que una amenaza
determinada explote una vulnerabilidad de un activo o grupo
de activos y por lo tanto cause un perjuicio sobre la
organizacin. Como se ver ms adelante, la mayora de
metodologas consideran el concepto de riesgo desde un punto
de vista estratgico. Asociado el mbito OT, se emplea en este
trabajo el concepto de riesgo operativo, definindose como la
probabilidad de sufrir un incidente de seguridad a nivel
operativo. Es decir, vinculado a un entorno de produccin o
una infraestructura crtica, la existencia de un determinado
riesgo afectara a la normal operacin de sus sistemas, procesos
y personas.
IV.METODOLOGAS Y ESTNDARES PARA EL
ANLISIS DE RIESGOS EN ENTORNOS INDUSTRIALES
E INFRAESTRUCTURAS CRTICAS
El anlisis de riesgos se basa en la utilizacin sistemtica de
la informacin disponible para identificar peligros y estimar los
riesgos. ENISA detalla en [2] hasta un total de 17 metodologas
para la evaluacin cuantitativa del riesgo (aunque existen ms,
estas son quizs las ms empleadas en Espaa y Europa). Entre
ellas se encuentran las siguientes: Austrian IT Security
Handbook, Cramm, Dutch A&K Analysis, Ebios, ISAMM, ISF
Methods, ISO/IEC 13335-2, ISO/IEC 17799, ISO/IEC 27001,
IT-Grundschutz, Magerit, Marion, Mehari, MIGRA. Octave,
RiskSafe Assessment y NIST SP800-30. Aunque existen otras
metodologas [3], las 17 seleccionadas por ENISA, representan
aquellas que estn ms extendidas en el mbito de las
163
JNIC2015
tecnologas de la informacin (IT). Por otro lado, en [4] y bajo

el paraguas del European Programme for Critical Infrastructure
Protection (EPCIP), se detallan 21 metodologas para la
evaluacin de riesgos en infraestructuras crticas. Entre ellas
destacan BIRR, BMI, CARVER2, CIMS, CIPDSS, CIPMA,
CommAspen o COUNTERACT.
Las primeras desarrollan la evaluacin de riesgos desde un
punto de vista puramente IT. Es decir, este tipo de
metodologas, no tienen en consideracin la idiosincrasia
especfica de los entornos OT ya explicada en la seccin II de
este artculo. Por otro lado, las metodologas explicadas en [4],
gestionan normalmente el riesgo a alto nivel, es decir, se
centran en evaluar los riesgos estratgicos. Por poner tan slo
un ejemplo, en el caso de la metodologa BMI (Baseline
Protection Concept), utilizada por el ministerio de interior
alemn, se presenta un marco para el desarrollo de planes que
aseguren que organizaciones y sectores categorizados como
crticos, aseguren el suministro de sus servicios esenciales.
Todas ellas llevan a cabo una aproximacin al riesgo de alto
nivel, es decir evaluando riesgos corporativos o estratgicos,
ms que riesgos operativos. Esto es, identificando activos
fsicos y lgicos (relacionados normalmente con entornos IT),
las dependencias entre ellos, y analizando las amenazas y/o
vulnerabilidades que pueden tener diferentes orgenes
(desastres naturales, errores y fallos no intencionados, ataques
deliberados, etc.).
Por otro lado, estrechamente relacionadas con los entornos
industriales y de infraestructuras, se han desarrollado una serie
de mejores prcticas que persiguen ayudar a los operadores
crticos y a las personas vinculadas a equipos de mejora de la
ciberseguridad industrial a realizar un anlisis exhaustivo de
vulnerabilidades asociadas a los entornos OT. El ICS-CERT,
recoge en [5] algunas de estas mejores prcticas. De entre ellas
se destacan la realizada por el Centre for the Protection of
National Infraestructure (CPNI) acerca de cmo realizar
evaluaciones de ciberseguridad en entornos industriales [6], la
elaborada por el National Institute of Standard Technologies
(NIST) para la creacin de programas para la gestin de
parcheos [7] o la publicada por el Sandia National Laboratories
sobre pen-testing en sistemas de control industrial [8].
Por ltimo, es preciso mencionar la metodologa
desarrollada por el DHS Control Systems Security Program
(CSSP) dentro del ICS-CERT [9], para conocer el grado de
adecuacin de un entorno industrial a una serie
estndares/mejores prcticas predefinidas, entre los que se
encuentran varias publicaciones especiales del NIST (SP80053 R3, SP800-53 R4, SP800-82) o las propuestas por el North
American Electric Reliability Corporation (NERC). Adems de
proponer la metodologa, se ha desarrollado una aplicacin que
facilita su uso. Esta aplicacin es el Cyber Security Evaluation
Tool (CSET).
Como puede observarse, existe un espacio muy amplio entre
las metodologas de evaluacin de riesgo estratgico y este tipo
de mejores prcticas que se quedan en la mera identificacin de
vulnerabilidades asociadas los sistemas ms frecuentes en los
entornos OT. Aunque estas ltimas ayudan a realizar un

anlisis exhaustivo, no existe ninguna metodologa o gua que
permita evaluar el riesgo operativo asociado al funcionamiento
no seguro de los dispositivos de campo, sistemas de tiempo
real, redes, protocolos especficos y procesos vinculados a los
entornos industriales y de infraestructuras de manera global e
integrada. Para cubrir este hueco conceptual y funcional, en
este artculo se propone una metodologa de anlisis que,
adems de identificar activos especficos vinculados a los
entornos de operacin, permite conocer de forma
multidimensional, las principales vulnerabilidades asociadas a
dichos activos y permite llevar a cabo una gestin del riesgo
operativo. Esta informacin acerca del riesgo operativo, podr
ser integrada como parte de otras metodologas especficas de
mbitos IT o como complemento de metodologas especficas
de evaluacin de riesgos estratgicos en infraestructuras
crticas.
V. MAASERISV2.1
MAASERISv2.1 (Metodologa para el Anlisis, Auditora de
seguridad y Evaluacin de Riesgo operativo de redes
Industriales y sistemas SCADA) es un conjunto de procesos,
herramientas y entregables que permiten:
1.
2.
3.
4.
Analizar el estado actual de una red industrial desde el

punto de vista de la seguridad, haciendo especial
hincapi en la evaluacin de la disponibilidad.
Facilitar un profundo anlisis de las principales
vulnerabilidades asociadas al entorno OT.
Proporcionar una evaluacin cuantitativa del riesgo
operativo.
Servir como documentacin complementaria y til para
el desarrollo de los PSO (Plan de Seguridad del
Operador) y los PPE (Plan de Proteccin Especfico)
que la ley PIC (Proteccin de Infraestructuras Crticas)
exige en Espaa.
La versin 2.1 que se presenta en este trabajo es la que se

est utilizando actualmente, tras una evolucin de 18 meses
desde la primera versin 1.0.
Para alcanzar estos objetivos, MAASERIS define tres reas
de anlisis; establece un ciclo de desarrollo de anlisis y
auditora e incluye una serie de entregables y dossieres.
Y los retos ms importantes que se han tenido que afrontar
para desarrollar esta metodologa especfica para entornos OT
se pueden resumir en:
164
1.
2.
Realizar el anlisis sin afectar a la disponibilidad de la

red industrial evaluada ni al correcto funcionamiento de
los
procesos
industriales
(normalmente
en
funcionamiento mientras se realizan las pruebas y tests
necesarios).
Incorporar al anlisis todos los activos y agrupaciones
de activos existentes en el entorno OT evaluado
JNIC2015
3.
4.
5.
independientemente del fabricante, versin o grado de

obsolescencia.
Obtener informacin suficiente acerca de los
dispositivos OT involucrados en el anlisis con las
configuraciones actuales de la red industrial y con
herramientas comnmente utilizadas. En muchos casos
ha sido necesario desarrollar herramientas especficas
para tecnologas y protocolos tpicos en entornos OT y
que adems no sean intrusivas.
Centrar el anlisis en el riesgo operativo, es decir, en
aquel vinculado al funcionamiento del entorno OT,
dejando para otras auditoras y anlisis el entorno IT y el
riesgo estratgico.
Conseguir la colaboracin de los equipos de produccin
y sistemas durante el proceso de auditora, normalmente
muy alejados de este tipo de anlisis.
A. reas de anlisis
Las reas de anlisis que establece MAASERIS son tres. En
primer lugar se procede al anlisis de inventario de activos
vinculados al entorno OT. Para ello se ha desarrollado una base
de datos que facilita la introduccin y categorizacin de los
diferentes activos, as como las dependencias entre ellos. Entre
los tipos de activos se encuentran los siguientes: concentrador,
conversor, controlador DCS, datos, electrnica de potencia,
firewall/UTM, HMI / Touch Panel, maquinaria, PC, PLC,
pantalla, periferia, protocolos, puntos de acceso inalmbricos,
repetidores, robot, router, sistema de marcaje, servidor,
software de gestin en tiempo real y switch. Adems se
procede a realizar una agrupacin fsica de activos (planta,
edificio, sala, rack, lnea, sistema, red) y una agrupacin lgica
(red, sistema).
El segundo rea de anlisis es la identificacin de
vulnerabilidades. A travs de diferentes tcnicas y
herramientas, en muchos casos desarrolladas a medida para
entornos OT aunque en otros casos se ha podido trabajar con
herramientas tpicas en IT (como las que incorpora la
distribucin Kali Linux), se descubren las distintas
vulnerabilidades que se asocian a los activos y a las
agrupaciones de activos. Para facilitar el trabajo inicial, se ha
creado una lista de vulnerabilidades tipo vinculadas a las
siguientes dimensiones: seguridad fsica, polticas y
procedimientos, tolerancia a fallos y disponibilidad, visibilidad
y acceso entre redes, software, IAAA y criptogrfica.
Por ltimo la tercera rea de anlisis es la gestin del riesgo
operativo. Como se ha explicado en la seccin III, el riesgo
operativo se define como la probabilidad de sufrir un incidente
de seguridad a nivel operativo. Es decir, vinculado a un
entorno de produccin o una infraestructura crtica, la
existencia de un determinado riesgo afectara a la normal
operacin de sus sistemas, procesos y personas.
Para medir el riesgo operativo se ha definido una mtrica
denominada ndice de Riesgo Operativo (IRO) que se mide en
Unidades de Riesgo Operativo (URO). El ndice de Riesgo
Operativo se calcula de la manera tradicional multiplicando los

siguientes tres factores, la Ocurrencia (O), la Severidad (S) y la
Deteccin (D).
IRO=OSD
La ocurrencia (O), se define como la probabilidad de que el
riesgo aparezca. Se valora del 1 al 10, siguiendo los criterios de
asignacin que se muestran en la tabla 2.
1
El riesgo es prcticamente imposible que aparezca.
El riesgo es muy difcil que aparezca.
El riesgo es difcil que aparezca.
El riesgo ha aparecido alguna vez.
El riesgo ha aparecido varias veces.
El riesgo aparece ocasionalmente.
El riesgo aparece con frecuencia.
El riesgo aparece con mucha frecuencia.
El riesgo aparece siempre ya que no se mitiga.
10
El riesgo aparece siempre porque no existe mitigacin posible.
Tabla 2. Criterios de valoracin para asignar la Ocurrencia de

riesgos operativos
La severidad (S), indica la gravedad de los efectos que puede

producir la aparicin de un cierto riesgo. Es decir, si afecta a la
disponibilidad, integridad y confidencialidad de los activos
objeto del anlisis. Se valora del 1 al 10, siguiendo los criterios
de asignacin que se muestran en la tabla 3, para el caso de la
disponibilidad en el ejemplo de un activo cuya desviacin del
estado normal de operacin no implique peligro para las
personas.
165
El riesgo no afecta a la normal operacin.
El riesgo afecta a la normal operacin, pudindose recuperar el

estado normal en menos de 5 minutos.



estado normal en menos de 1 hora.

estado normal en menos de 4 horas

estado normal en menos de 8 horas.


10
El riesgo afecta a la normal operacin, no pudindose recuperar

el estado normal.
Tabla 3. Criterios de valoracin para asignar la Severidad de

riesgos operativos
JNIC2015
El riesgo siempre es detectable.
El riesgo es extremadamente fcil de detectar.
El riesgo es muy fcilmente detectable.
El riesgo es fcilmente detectable.
El riesgo se detecta normalmente
El riesgo se detecta frecuentemente
El riesgo es difcil de detectar.
El riesgo es muy difcil de detectar.
El riesgo es extremadamente difcil de detectar.
10
Cdigo
R08
R09
R10
R11
R12
R13
R14
R15
R16
R17
R18
El riesgo es imposible de detectar.
Tabla 6. Familia de riesgos tcnicos no especficos OT
Tabla 4. Criterios de valoracin para asignar la Deteccin de

riesgos operativos
La deteccin (D), indica la probabilidad de no detectar el

riesgo antes de que se produzca un incidente. Se valora del 1
al 10, siendo 1 si el riesgo que se detecta siempre o casi
siempre y 10 si no hay ninguna probabilidad de detectar el
riesgo. En la tabla 4, se muestran los criterios de asignacin.
Como su nombre indica, el IRO es un ndice que permite
determinar qu riesgo es ms frecuente, ms grave y ms difcil
de detectar. Adems permite comparar y ordenar un conjunto
de riesgos de mayor a menor (o viceversa) y establecer
prioridades. El valor mximo de IRO es 1000 y el menor es 1,
y como adelantbamos, se mide en Unidades de Riesgo
Operativo (URO). Cuanto ms alto sea este valor, mayor es el
riesgo operativo al que el entorno OT se encuentra expuesto.
Por otro lado, con el objetivo de acotar mbitos de
responsabilidad, se han definido tres tipos de familias de
riesgos operativos: la familia 1 recoge los riesgos tcnicos
especficos OT. Como su propio nombre indica son riesgos
vinculados a la idiosincrasia de los entornos de operacin
(Operation Technology). La familia 2 recoge riesgos tcnicos
no especficos OT, hay que tener en cuenta que en todos los
entornos OT actuales se incorporan cada vez ms tecnologas y
soluciones tpicas o estndares en IT. En este caso, son riesgos
que pueden afectar al entorno de operacin, pero que podran
encontrarse tambin en los entornos transaccionales o IT
(Information Technology). Y por ltimo la familia 3 recoge
riesgos polticos, legales y de organizacin, es decir aquellos
riesgos asociados a cuestiones organizativas, polticas y
legales.
Teniendo en cuenta estas tres familias, se proponen como
punto de partida los riesgos operativos que se detallan en las
tablas 5, 6 y 7. Estos riesgos no son los nicos que pueden
aparecer, aunque cabe aclarar que estos son los ms habituales.
Cdigo
R01
R02
R03
R04
R05
R06
R07
Familia 2 Riesgos tcnicos no especficos OT

Intercepcin de comunicaciones
Brecha de datos
Dos y DDoS
Insider malicioso
Gestin ineficiente de la red
Escalado de privilegios
Dao fsico (desastre natural, prdida o robo)
Ingeniera social
Prdida o compromiso de logs
Acceso fsico no autorizado a activos IT
Acceso remoto no autorizado a activos IT
Cdigo
R19
R20
R21
Familia 3 Riesgos polticos, legales y de organizacin

Cautividad
Incumplimiento de regulacin alimentaria
Incumplimiento de polticas de licenciamiento
Tabla 7. Familia de riesgos polticos, legales y de organizacin
B. Ciclo de desarrollo de anlisis y auditora

MAASERIS v2.1 establece la ejecucin del anlisis y
auditora de seguridad en tres fases (preparacin, ejecucin y
anlisis) que se llevan a cabo realizando las siguientes seis
etapas:
1.
2.
3.
4.
5.
6.
Firma de compromiso y confidencialidad.

Recoleccin de informacin.
Planificacin, diseo y seleccin/desarrollo/adaptacin
de herramientas de anlisis y auditora.
Recogida de informacin y anlisis de vulnerabilidades
(se emplean tcnicas de caja negra, gris y blanca,
depende del entorno OT y del activo o grupo de activos
analizado).
Anlisis de informacin y determinacin/priorizacin de
riesgos.
Presentacin de resultados.
Para cada una de estas etapas, se han desarrollado una serie

de definiciones, actividades y puntos crticos a tener en cuenta.
C. Entregables y dossieres
Por ltimo, en la tabla 8, se muestran los entregables
estndares que se presentan al finalizar el proceso de anlisis y
auditora.
Familia 1 Riesgos tcnicos especficos OT

Intercepcin de comunicaciones industriales
Brecha de datos industriales
Prdida de cdigos y desarrollos sistemas y dispositivos
Compromiso del proceso
Prdida o compromiso de histricos de proceso
Acceso fsico no autorizado a activos OT
Acceso remoto no autorizado a activos OT
Cdigo
RE01
MA01
MA01_BBDD
MA01_anexo
MA02
MA02_anexo
MA03
RO1
RO2
Entregable
Resumen ejecutivo
Inventario de dispositivos Ethernet
BBDD de inventario de actives y dependencias
Procedimiento actualizacin BBDD inventario
Arquitectura de red actual
Mapa de arquitectura de red actual
Informe multidimensional de vulnerabilidades
Informe de riesgos operatives
Mapa de riesgos
Tabla 8. Entregables estndares MAASERISv2.1
Tabla 5. Familia de riesgos tcnicos especficos OT
166
JNIC2015
VI. CONCLUSIONES Y TRABAJO FUTURO

En este artculo se ha puesto de manifiesto las diferencias
existentes entre los mbitos IT (Information Technology) y OT
(Operation Technology) de las organizaciones que pertenecen a
sectores industriales y/o manejan infraestructuras crticas. Estas
diferencias hacen imprescindible que la aproximacin al diseo
y despliegue de programas de ciberseguridad IT y OT sea
diferente, aunque siempre deban desarrollarse de manera
consensuada.
Tras definir los conceptos de amenaza, vulnerabilidad y
riesgo operativo, se ha realizado un recorrido por las
principales metodologas de evaluacin y anlisis de riesgos y
por las mejores prcticas propuestas por diferentes
instituciones
para
analizar
de
forma
exhaustiva
vulnerabilidades especficas asociadas a los entornos de
operacin.
Una vez finalizado este recorrido, se ha detectado la
necesidad de proponer una metodologa que cubra el espacio
existente entre las metodologas de anlisis y gestin del riesgo
estratgico y las mejores prcticas especficas de un tipo de
activo o grupo de activos. Esta metodologa se ha denominado
MAASERISv2.1, acrnimo de Metodologa para el Anlisis,
Auditora de seguridad y Evaluacin de Riesgo operativo de
redes Industriales y sistemas SCADA. MAASERISv2.1 define
tres reas de anlisis (anlisis de inventario de activos,
identificacin de vulnerabilidades y gestin del riesgo
operativo); establece un ciclo de desarrollo de anlisis y
auditora e incluye una serie de entregables y dossieres.
El desarrollo de este trabajo ha sido posible gracias a la
colaboracin pblico-privada entre un grupo de investigacin
de una universidad pblica y una consultora especializada del
sector. Y su utilidad se est validando ya en numerosos
proyectos en clientes de diferentes sectores en todo el territorio
nacional. En la actualidad se sigue trabajando en mejorar y
completar la metodologa presentada en este artculo, en
concreto, automatizando en todo lo posible el trabajo de los
ingenieros durante la fase de recogida de informacin y anlisis
de vulnerabilidades y adecuando los entregables y resultados a
las exigencias de la ley PIC para los diferentes tipos de
operadores crticos.
[2]
ENISA. Inventory of Risk Management / Risk Assessment Methods.

Julio
2015.
http://www.enisa.europa.eu/activities/riskmanagement/current-risk/risk-management-inventory/rm-ra-methods
[3]
G. Correa. Identificacin y evaluacin de amenazas a la seguridad de

infraestructuras de transporte y distribucin de electricidad. CIRCE,
UNIZAR, Junio 2012.
[4]
G. Giannopoulos, R. Filippini, M. Schimmer. Risk assessment

methodologies for Critical Infrastructure Protection. Part I: A state of the
art. European Commission. Joint Research Centre. Institute for the
Protection and Security of the Citizen. Noviembre 2012.
[5]
ICS-CERT. Establishing and Conducting Asset, Vulnerability, and Risk

Assessments. Julio 2015. https://ics-cert.us-cert.gov/Standards-andReferences#conduct
[6]
CPNI-Homeland of Security. Cyber Security Assessments of Industrial

Control Systems. Good Practice Guide. Noviembre 2010. https://icscert.uscert.gov/sites/default/files/documents/Cyber_Security_Assessments_of_I
ndustrial_Control_Systems.pdf
[7]
M. Souppaya, K, Scarfone. Guide to Enterprise Patch Management

Technologies, NIST Special Publication 800-40 Revision 3. Julio 2013.
[8]
D. Duggan, et al, Penetration Testing of Industrial Control Systems,

Sandia National Laboratories, Report No SAND2005-2846P, 2005.
[9]
ICS-CERT.
Assessments.
cert.gov/Assessments
AGRADECIMIENTOS
A David Soler y Santiago Ramrez por el trabajo realizado
en la implantacin y evolucin de la metodologa. A Josep
Rodrigo, Patxi Arruabarrena, Asier Olea y Fernando Campos
por su participacin en el equipo de trabajo multidisciplinar
que hizo posible la creacin de la metodologa. A Manuel
Meijueiro y a Jordi Rey por su apoyo a esta iniciativa desde la
direccin de Logitek.
REFERENCIAS
[1]
L. Marinos. ENISA Threat Landscape 2014. ENISA, Diciembre 2014.
167
Julio
2015.
https://ics-cert.us-
JNIC2015
Repositorio de actividades autonomas para la

docencia de seguridad en sistemas informaticos
Francisco J. Ribadas-Pena, Ruben Anido-Bande, Vctor M. Darriba-Bilbao
Departamento de Informatica, Universidade de Vigo
Edificio Politecnico, Campus As Lagoas, S/N. 32004 Ourense
ribadas@uvigo.es, rabande@esei.uvigo.es, darriba@uvigo.es
ResumenEn este trabajo se describe nuestra experiencia con

el uso extensivo de software de virtualizacion en la docencia
practica de seguridad informatica. Se presenta un repositorio
de actividades autonomas que hacen uso de redes de maquinas
virtuales para ejercitar aspectos relativos a la seguridad en
redes y a la administracion segura de sistemas operativos y
aplicaciones. Las actividades recopiladas han sido puestas en
practica durante los ultimos

anos,
tanto en cursos convencionales
de una titulacion de Ingeniera Informatica como en ensenanzas

no regladas. Se presenta asimismo una herramienta grafica
y posterior simulacion
multiplataforma que facilita el diseno
de las redes de computadores sobre las que se desarrollan las
actividades incluidas en nuestro repositorio u otras nuevas que
se deseen proponer.
I.
I NTRODUCCI ON
Buena parte de las competencias academicas relacionadas

con la seguridad informatica aconsejan seguir una orientacion
eminentemente practica. Se pretende que los estudiantes conozcan las amenazas tpicas a la seguridad de los datos y de
los sistemas de informacion y que adquieran una experiencia
que les permita ser capaces de enfrentarse a estas amenazas
e implantar las medidas necesarias para evitarlas, detectarlas
y contrarrestarlas. Asegurar el e xito en la adquisicion de este
tipo de habilidades es particularmente difcil, ya que requiere
la practica directa sobre entornos similares a los que se puedan
encontrar en el mundo real. Por ello, la situacion ideal [4],
[5] sera aquella en la cual cada alumno dispusiese de un
entorno de red real sobre el que experimentar y poder manejar
libremente distintas herramientas de seguridad, enfrentandose
a casos de estudio cercanos a la realidad.
Plantear estas actividades practicas sobre sistemas reales
conlleva dificultades tanto tecnicas como de disponibilidad de
recursos que en muchos casos imposibilitan su realizacion.
Buena parte de los ejercicios relacionados con la seguridad,
como simulacion de intrusiones y ataques o la instalacion de
cortafuegos y medidas de proteccion, causaran numerosos
problemas en un laboratorio compartido, ademas del riesgo
implcito que conllevan estas actividades. En [10] se senalan
algunos de los problemas del uso de laboratorios compartidos
en la docencia de materias relacionadas con la seguridad
informatica:
Muchos ejercicios precisan acceso privilegiado al sistema, lo que posibilitara usos maliciosos de los equipos.
Muchos equipos pueden quedar en una situacion inestable tras haber realizados ciertos ejercicios, lo que forzara
a reinstalarlos despues de cada sesion.

El desarrollo de algunos ejercicios puede superar la duracion de las sesiones practicas, con la consiguiente perdida
de tiempo para dejar el entorno como se encontraba al
inicio de la sesion y la recuperacion del trabajo realizado
al inicio de la siguiente.
Se requiere personal de apoyo experimentado para instalar y configurar los equipos necesarios y las herramientas
de seguridad a emplear y para mantener en perfecto
estado los recursos de un laboratorio compartido.
Tomando en consideracion estos condicionantes previos, en
este trabajo describimos nuestra experiencia en la utilizacion
de una aproximacion similar a las descritas en [1], [2], [3]
y [8], basadas en el uso de herramientas de virtualizacion.
El uso de maquinas virtuales (MVs) para la construccion de
laboratorios y entornos de experimentacion es una practica
habitual en el campo de la seguridad informatica, tanto a
nivel profesional como en el a mbito docente [9], [13]. La
flexibilidad y las ventajas que aportan estas tecnologas en este
contexto son bien conocidas y eliminan o atenuan muchos de
los problemas mencionados anteriormente. Trabajar con MVs
permite experimentar en entornos muy similares a los reales,
con la ventaja del aislamiento, la facilidad de recuperacion ante
errores o problemas y la posibilidad de replicar, comunicar y
compartir los experimentos realizados simplemente mediante
el intercambio de las imagenes utilizadas.
El esquema propuesto se describe en la seccion II y supone
la evolucion y actualizacion del planteamiento previo presentado por los autores en [6], simplificando al maximo las tareas
de preparacion por parte del alumno y agilizando la puesta
en marcha de las actividades practicas propuestas. Como
resultado del empleo de este esquema se consigue ofrecer al
alumno, dentro de una u nica maquina (bien sea un equipo de
un laboratorio compartido o bien su propio equipo personal),
un entorno virtual con multiples computadores conectados
formando pequenas redes, listos para ser usados y que contaran
con una coleccion de herramientas de seguridad de codigo
abierto, preinstaladas y configuradas.
En la seccion III se presenta un repositorio de actividades
practicas que hacen uso de este entorno virtualizado. Esta
coleccion recopila y estructura las actividades que hemos
empleado en los u ltimos anos de docencia en el a mbito de la
seguridad en sistemas de informacion. Se trata de una serie de
actividades de laboratorio que permiten introducir al alumnadoen el uso de herramientas de seguridad y promover el trabajo
168
JNIC2015
Imagen base (base.vdi)
autonomo en la resolucion de problemas relacionados con la

seguridad y la proteccion de sistemas, con el objetivo final de
facilitar un aprendizaje fundamentado en la experimentacion
sobre situaciones reales. Como complemento a esta coleccion
de recursos, en la seccion IV se presenta una herramienta
grafica multiplataforma que permite disenar y configurar de
forma sencilla las redes virtualizadas donde se realizan las
actividades propuestas. Finalmente, la seccion V presenta la
evaluacion por parte del alumnado de las actividades realizadas
y las principales conclusiones del trabajo realizado.
II. E NTORNO P ROPUESTO
Nuestro objetivo principal es ofrecer un primer contacto,
lo mas realista posible, con la administracion segura de redes
y equipos, de modo que los estudiantes pongan en practica
sus conocimientos de seguridad informatica en sistemas reales,
empleando herramientas de seguridad de uso habitual y resolviendo problemas practicos del mundo real. Como objetivos
secundarios, pretendemos minimizar el coste y la carga de
trabajo que requerira el mantenimiento de un laboratorio
de seguridad dedicado, limitando la exigencia de requisitos
especiales en los laboratorios docentes compartidos. Tambien buscamos maximizar el aprovechamiento del tiempo de
practicas del alumno, ofreciendole un entorno preconfigurado
y adaptado especficamente a cada una de las actividades
practicas que se le propongan, reduciendo el tiempo y el
trabajo extra necesario para su puesta en marcha.
Para conseguir estos objetivos proponemos hacer uso de
tecnicas de virtualizacion. En la virtualizacion de sistemas nos
encontramos con un equipo anfitrion sobre el cual un software
especfico permite ejecutar uno o mas sistemas huesped de
forma simultanea. Desde el punto de vista de la docencia, estos
entornos virtualizados proporcionan numerosas ventajas [11] y
existe una variada bibliografa sobre su empleo en la docencia
de Sistemas Operativos, Redes de Computadoras o Seguridad
Informatica. Las maquinas virtuales (MVs) son faciles de crear
y son muy seguras, ya que es posible aislarlas totalmente de
la red de docencia y del exterior. La mayor parte de las herramientas de virtualizacion actuales contemplan la posibilidad de
definir redes virtualizadas de complejidad arbitraria, sobre las
que podran trabajar los alumnos. Permiten configurar una vez
y distribuir a los alumnos imagenes listas para ser usadas, ahorrando tiempo de configuracion. Son razonablemente fiables y
la recuperacion ante catastrofes es sencilla, basta con retomar
las imagenes iniciales para reconstruir el entorno de practicas,
lo que favorece la experimentacion, estimula la curiosidad y
posibilita el aprendizaje autonomo.
II-A. Uso de la virtualizacion de equipos y redes
Como senalamos, el uso de herramientas de virtualizacion
en el entorno docente es una aproximacion ampliamente
utilizada. El tipo de uso que se hace de estas tecnicas va
desde el empleo directo de herramientas convencionales como
QEMU 1 , Kernel Virtual Machine 2 , Xen 3 , VMware 4 o V IR -
Debian 7.0 (Wheezy)
Entorno grafico
ligero LXDE (deshabilitado por defecto)
VirtualBox Guest Additions 4.3.x
Servicios (desactivados por defecto):
servidor web (Apache 2)
servidores inetd: telnetd, ftpd, fingerd
servidor BD mysql
servidor smtp (postfix)
servidor pop3, imap (dovecot)
servidor ssh (openSSH)
servidor ldap (openLDAP)
Herramientas de seguridad:
analizador de protocolos WIRESHARK
escaner de vulnerabilidades: NESSUS y OPEN VAS
escaner de puertos NMAP (interfaz ZENMAP)
matasploit framework
de intrusiones en red SNORT
sistema de deteccion
de intrusiones en host SAGAN
sistema de deteccion
cortafuegos: netfilter/iptables
interfaces iptables: Firestarter, Shorewall
consola eventos IDS SNORBY
openVPN, openssl, easy-rsa, tinyca
otras: netcat (nc), hping3, iptraf, netstat-nat, tcptraceroute
Aplicaciones web vulnerables:
OWASP WebGOAT (http://webgoat.github.io/)
Mutillidae (http://sourceforge.net/projects/mutillidae/)
Damn Vulnerable Web App (http://www.dvwa.co.uk/)
foro PHP vulnerable (desarrollo propio)
Wordpress 1.5.1.1
Software general:
clientes telnet, ftp y ssh
navegador web modo texto Lynx
navegador web Mozilla Firefox
editores: vi, nano, jed, leafpad
Otras herramientas:
balanceo de carga basado en proxies (HAProxy)
LinuxHA (heartbeat, pacemaker)
de la imagen: aprox. 4,2 GB (1,9 GB comprimida)
Tamano
Fig. 1. Descripcion de la imagen base comun empleada las actividades.
TUAL BOX 5 ,
o soluciones basadas en e stas como Vagrant 6 o

incluso el gestor de contenedores ligeros Docker 7 , al empleo
de entornos especficos para el diseno de redes de MVs.
El primer caso es el mas habitual a la hora de realizar pruebas o experimentos ocasionales o como una forma comoda de
distribuir entornos preconfigurados y/o gestionar entregables
por parte de los alumnos. En el segundo caso, nos encontramos
con herramientas que se abstraen del software de virtualizacion
subyancente, ofreciendo mecanismos simplificados para la
configuracion del entorno virtualizado mediante documentos
XML o incluso interfaces graficas propias. En este caso
tenemos ejemplos como Netkit [7], basado en la plataforma
de virtualizacion a nivel de sistema operativo User Mode
Linux(UML), Virtual Networks over LinuX (VNX) [12], que
a su vez es una evolucion de VNUML(Virtual Networks over
User Mode Linux), tambien basada en UML, y que en VNX
se ha abstrado de la plataforma de virtualizacion concreta
empleando el API de libvirt 8 e integrado el soporte para
virtualizacion ligera mediante Linux Containers (LXC). En
1 http://wiki.qemu.org/
5 https://www.virtualbox.org/
3 http://www.xenproject.org/
7 https://www.docker.com/
6 https://www.vagrantup.com/
2 http://www.linux-kvm.org/
8 http://libvirt.org/
4 http://www.vmware.com/
169
JNIC2015
TABLA I
L ISTADO DE ACTIVIDADES D ISPONIBLES Y H ERRAMIENTAS DE S EGURIDAD E MPLEADAS .
(a) S EGURIDAD EN REDES : SEGURIDAD PERIMETRAL
ACTIVIDAD
DIFICULTAD
Uso de Shorewall: DMZ con doble firewall

Uso de Shorewall: DMZ con firewall de 3 interfaces
Tuneles
con openVPN
DMZ con firewall de 3 interfaces empleando NETFILTER/iptables

de intrusiones en red
SNORT: sistema de deteccion
de intrusiones en host
SAGAN: sistema de deteccion
media
alta
media
media
media
media
HERRAMIENTAS / TECNOLOGI AS
shorewall, nmap
shorewall, nmap
openvpn, openssl, tinyca, shorewall
iptables, nmap
snort, barnyard2, snorby, scapy
snort, barnyard2, snorby, syslog
(b) S EGURIDAD EN REDES : PROTOCOLOS SEGUROS

ACTIVIDAD
DIFICULTAD
Analisis
de protocolos y escaneo de puertos
Man in the middle sobre SSL en redes locales
baja
media
wireshark, nmap
ettercap, sslsniff, sslstrip
(c) D ESARROLLO SEGURO

ACTIVIDAD
DIFICULTAD
Aplicaciones web inseguras: SQLi y XSS

de aplicaciones web con mod-security
Securizacion
baja
media
wordpress, webgoat, mutillidae, dvwa

mod-security, wordpress, mutillidae, dvwa
DE SISTEMAS
(d) A DMINISTRACI ON
ACTIVIDAD
DIFICULTAD
centralizada en GNU/Linux: OpenLDAP y PAM

Autenticacion
Despliegue de controlador de dominio AD sobre MS Windows Server 2008
Balanceo de carga con HAproxy
Alta disponiblidad con LinuxHA (heartbeat y pacemaker)
alta
baja
baja
media
openldap, pam, phpldapadmin, gosa

windows server, active directory, ldap
haproxy
linuxHA, heartbeat, pacemaker
(e) T ESTS DE INTRUSI ON

ACTIVIDAD
DIFICULTAD
Analisis
de vulnerabilidades: openVAS y Nessus
de vulnerabilidades: Metasploit+Armitage sobre Metasploitable2
Explotacion
ambos casos, Netkit y VNX, se trata de herramientas con

una clara orientacion docente y los respectivos equipos de
desarrollo mantienen un repositorio de laboratorios 9 10
con diversos escenarios. Otras herramientas similares seran
el proyecto Marionnet 11 , originado como una interfaz grafica
para Netkit y sin actividad reciente, y el simulador Graphical Network Simulator (GNS3) 12 con un enfoque mas
generalista, que permite experimentar con dispositivos CISCO
emulados mediante la herramienta Dynamips y que soporta la
inclusion de MVs basadas en V IRTUAL BOX dentro de las
redes emuladas. Para mas detalles, en [8] se presenta una
pequena comparativa de algunas de estas herramientas y de
otras similares respecto a su uso docente en la ensenanza de
redes de computadoras.
Nuestra propuesta esta a medio camino entre ambas aproximaciones, dado que hace uso de una herramienta de virtualizacion convencional, V IRTUAL BOX, y la definicion de los
escenarios a emplear en las actividades esta solo parcialmente
automatizada. No obstante, la incorporacion de la herramienta
DS BOX, descrita en la secci
on IV, simplifica enormemente el
diseno de los escenarios, as como su difusion y reutilizacion.
V IRTUAL BOX es una plataforma de virtualizacion completa para arquitecturas x86 y AMD64, distribuida en su
version basica bajo licencia GNU General Public License v2 y
disponible para GNU/Linux, MS Windows, Mac OS y Solaris.
9 Laboratorios
Netkit: http://wiki.netkit.org/index.php/Labs Official

VNX: http://web.dit.upm.es/vnxwiki/index.php/Allexamples
11 http://www.marionnet.org/
12 http://www.gns3.com/
10 Laboratorios
baja
alta
nmap, nessus, openvas

nmap, metasploit, armitage, metasploitable
Permite la ejecucion de una amplia variedad de huespedes 13

sin requerir privilegios de administrador y permitiendo, si as
se requiere, aislamiento total respecto al equipo anfitrion y
la red de docencia. Cuenta con una extensa documentacion y
una amplia comunidad de usuarios. Desde el punto de vista
del diseno de nuestras actividades practicas, las principales
ventajas que aporta esta herramienta y que han llevado a su
empleo, son, por orden de importancia, las siguientes:
1. Soporte multiplataforma. Se trata de una herramienta
disponible para los sistemas operativos y las arquitecturas mas usuales y que no impone restricciones especiales
respecto al tipo de equipo anfitrion a utilizar. Siendo
la principal limitacion practica la cantidad de memoria
RAM disponible en el equipo anfitrion.
2. Soporta la emulacion de multiples interfaces de red
en cada MV, que se pueden interconectar con las de
otros huespedes o con el anfitrion, formando redes
virtualizadas. En concreto, existen cuatro modos basicos:
NAT: Permite conexiones salientes desde los
huespedes a traves del anfitrion empleando traduccion de direcciones (NAT, Network Address Translation) gestionada por el motor de V IRTUAL BOX.
Bridged: Permite el acceso directo del huesped a
las redes donde resida el anfitrion, configurando la
correspondiente interfaz de red de este equipo en
modo puente.
Host Only: Ofrece al huesped una interfaz de red
desde el que acceder al equipo anfitrion.
170
13 Ver
https://www.virtualbox.org/wiki/Guest OSes
JNIC2015
(a) Portada de la seccion Seguridad en redes
(b) Enunciado de la actividad Uso de Shorewall: DMZ con doble firewall
Fig. 2. Captura del repositorio de actividades creado, disponible en la direccion http://alqueidon.ei.uvigo.es/repossi/.
Internal Network: Ofrece un mecanismo para que

distintas maquinas huesped compartan una red virtualizada comun, aislada del exterior y del propio
anfitrion. Cada una de estas redes virtualizadas conforma un dominio de colision, a modo de concentrador o hub virtual, donde se conectan las diferentes
instancias de los equipos huesped.
En nuestro caso, salvo en casos concretos, se utilizan exclusivamente conexiones Internal Network que permiten
definir redes locales arbitrarias segun las necesidades del
escenario trabajado en cada actividad concreta.
3. Soporta la comparticion de las imagenes de discos
171
virtuales entre diferentes MVs huesped y permite la

creacion, gestion y comparticion de imagenes diferenciales. De este modo, es posible definir una u nica
imagen base que sera reutilizada por todas las MVs
que conforman un escenario dado, ahorrando espacio
de disco y minimizando los tiempos de descarga de
las imagenes utilizadas. Asimismo, es posible distribuir
imagenes diferenciales que anadan modificaciones sobre
las imagenes base iniciales, permitiendo una actualizacion sencilla de los huespedes utilizados.
4. Ofrece mecanismos de control de las maquinas virtuales
muy potentes y flexibles, mas alla de su interfaz grafi-
JNIC2015
ca. En concreto, la herramienta de lnea de comandos

VBoxManage permite configurar la totalidad de los
parametros relativos a las MVs, as como controlar su
ejecucion, haciendo posible la definicion y control de
estas MVs desde shell scripts faciles de distribuir y
ampliar. Del mismo modo, V IRTUAL BOX tambien expone todas sus funcionalidades a traves de diversas APIs
disponibles para distintos lenguajes de programacion.
5. Permite, entre otras alternativas, la comunicacion entre
anfitrion y huespedes mediante el intercambio de Guest
Properties. Se trata de pares atributo-valor que son
establecidos por la maquina anfitrion, bien desde la
herramienta de lnea de comandos VBoxManage o
desde alguna de las APIs ofrecidas por V IRTUAL BOX.
Los valores vinculados a estosa tributos que pueden
ser recuperados desde las MVs huesped que tengan
instalado el software denominado V IRTUAL BOX Guest
Additions, que proporciona una coleccion de drivers
nativos, servicios, libreras y ejecutables, entre ellos
el comando VBoxControl que permite consultar los
valores de estas Guest Properties.
En nuestro caso, este mecanismo se utilizara para inyectar determinados parametros de configuracion en el
equipo huesped, que permitiran configurar, desde el exterior del mismo, aspectos como las conexiones de red,
rutas por defecto, nombres y direcciones de maquinas
conocidas, etc.
II-B.
Estructura de los equipos y las redes virtualizadas
En lo que respecta al uso que se hace de las tecnologas de

virtualizacion a la hora de plantear un laboratorio personal
sobre el que realizar las actividades practicas propuestas, el
esquema empleado es una evolucion del descrito por los
autores en [6]. Se ha pretendido optimizar el uso de espacio en
disco mediante el empleo de imagenes de disco diferenciales
creadas a partir de una imagen base comun. Tambien se ha
perseguido simplificar el proceso de puesta en marcha de las
simulaciones, consiguiendo reducir al mnimo el trabajo del
alumnado previo a la realizacion de las actividades en s,
automatizando tareas como la configuracion de conexiones de
red, direcciones y rutas.
En nuestra propuesta hemos empleado una u nica imagen
base de un sistema GNU/Linux que hace uso de la distribucion
Debian 7.0, y que cuenta una serie de herramientas de seguridad preinstaladas, junto con un conjunto de servidores tpicos
(gestor de base de datos, servidor HTTP, etc) inicialmente
deshabilitados. Los detalles de dicha imagen base se presentan
en la Fig. 1. Esta imagen es la que se utilizara para lanzar
la mayora de los huespedes que formaran parte de las redes
virtuales a utilizar en las actividades practicas desarrolladas. Se
consigue de este modo sacar provecho del soporte de imagenes
diferenciales de V IRTUAL BOX para minimizar el uso de
espacio en disco. Solo en casos puntuales, y para finalidades
concretas, se hace uso de imagenes disponibles en lnea, como
en la actividad de explotacion de vulnerabilidades donde se
emplea Metasploitable2 14 , una imagen de un sistema Ubuntu
14 Disponible
8.04 con software vulnerable y deficiencias de configuracion.

Para cada actividad propuesta se aporta un shell script
de puesta en marcha, tanto para GNU/Linux como para
MS Windows, encargado de automatizar su puesta en
funcionamiento. Estos scritps hacen uso de las funcionalidades
de la herramienta VBoxManage y se encargan de crear
y definir los parametros de las respectivas MVs huesped,
configurandolas para utilizar replicas diferenciales de
la imagen base descrita anteriormente. La otra gran
responsabilidad de estos scripts es definir las conexiones
de red de los huespedes en modo Internal Network
de modo que se pueda realizar la interconexion entre
huespedes para conformar las redes virtualizadas empleadas
en cada ejercicio concreto. Adicionalmente, estos scripts
tambien pueden configurar los parametros de red propios
de cada huesped, como direcciones IP, mascaras de red,
rutas, fichero /etc/hosts inicial, etc. Para permitir
esta configuracion automatica de la red en los equipos
huesped se hace uso de las Guest Properties ofrecidas
por V IRTUAL BOX y de un script de arranque especfico
(/etc/init.d/dsBOX_network_autconfigure.pl)
presente en la imagen base, que cuenta a su vez con una
instalacion funcional de la version 4.3.x de las Guest Additions
de V IRTUAL BOX. Este script se ejecuta durante el arranque
de las MVs y consulta los valores de las Guest Properties
descritas en la tabla II mediante el comando VBoxControl
para, en el caso de que e stas estuvieran establecidas, invocar
los correspondientes comandos de configuracion de redes de
la maquina huesped.
III.
R EPOSITORIO DE ACTIVIDADES
Para hacer disponible la coleccion de actividades y ejercicios basados en MVs desarrollados a lo largo de estos anos de
actividad docente se ha publicado un repositorio web donde
se recogen los enunciados, guas y demas recursos utilizados,
junto con las imagenes base de las MVs utilizadas y los respectivos shell scripts de instalacion y puesta en marcha. Este
repositorio esta actualmente publicado en la direccion http:
//alqueidon.ei.uvigo.es/repossi/ y se estructura
en 4 secciones, que se corresponden aproximadamente con la
estructura seguida en las actividades practicas de las asignaturas de seguridad en sistemas de informacion impartidas.
en http://sourceforge.net/projects/metasploitable/.
172
Seguridad en redes. Incluye ejemplos de tecnicas y

herramientas de seguridad en redes, organizados en dos
subsecciones:
Protocolos seguros. Revisando los problemas derivados del uso de protocolos no cifrados y presentado
en detalle el funcionamiento interno de protocolos
como TLS/SSL.
Proteccion perimetral. Revisando herramientas para la construccion de cortafuegos y las distintas topologas disponibles a la hora de hacer uso de zonas
desmilitarizadas. Se presentan tambien ejemplos de
uso de herramientas de deteccion de intrusos, tanto
de red como de host, as como soluciones para la
construccion de redes privadas virtuales.
JNIC2015
TABLA II
PAR AMETROS
C ONFIGURABLES EN LAS MV S MEDIANTE Guest Properties.
CLAVE ATRIBUTO
TIPO VALOR
DESCRIPCI ON
/DSBOX/num_interfaces
/DSBOX/{interface}/tipo
num.
entero
cadena: dhcp o static
/DSBOX/{interface}/address
/DSBOX/{interface}/netmask
IP
direccion
mascara
de red (formato
nnn.nnn.nnn.nnn)
IP
direccion
dir. IP o nombre completo
Numero
de dispositivos de red conectados a la MV huesped
de direcciones IP del interfaz no {interface}: modo automatico
Asignacion
estatica)
mediante DHCP o modo manual (configuracion

o
IP a asignar al interfaz n {interface} en el modo estatico
Direccion
Mascara
de red del interfaz no {interface} en el modo de configuracion
estatico
IP de broadcast del interfaz no {interface} en el modo estatico
Direccion
IP o nombre de la maquina
Direccion
que hace el papel de puerta de enlace
(ruta por defecto de la MV)
Lista de direcciones IP de los servidores de nombres a utilizar por la MV
Nombre completo de la maquina

virtual en su respectiva red
Lista de pares (nombre maquina,

dir. IP) a incluir en el fichero /etc/hosts
de la maquina
virtual (permite que las MVs sean accesibles por nombre sin
necesidad de instalar un servidor DNS propio en la red virtualizada)
/DSBOX/{interface}/broadcast
/DSBOX/default_gateway
/DSBOX/default_nameserver
/DSBOX/host_name
/DSBOX/etc_hosts_dump
dirs. IP separadas por ,

cadena de texto
pares nombre:direcci
on separados por ,
Desarrollo seguro. Centrado en la revision de las vulnerabilidades tpicas en aplicaciones web. Se hace uso de
aplicaciones educativas que cuentan intencionadamente
con vulnerabilidades conocidas, como problemas de inyeccion SQL o Cross Site Scripting (XSS).
Tambien se presentan alternativas para mitigar estos
problemas mediante el uso de cortafuegos de nivel de
aplicacion como mod-security.
Administracion de sistemas. Se revisan cuestiones relativas a la administracion segura de sistemas, fundamentalmente cuestiones relacionadas con la autenticacion en
entornos centralizados.
Se incluyen tambien ejercicios complementarios relacionados con balanceo de carga de aplicaciones y con
soluciones de alta disponibilidad, que si bien van mas alla
de lo que abarca tpicamente un curso sobre seguridad,
sirven para mostrar la versatilidad de nuestra propuesta
al aplicarla en otros campos relacionados.
Tests de intrusion. Se presentan ejemplos de uso de
herramientas empleadas tpicamente para dar soporte a
tareas habituales en los tests de intrusion, como detectores/analizadores de vulnerabilidades o frameworks de
explotacion de vulnerabilidades como Metasploit.
En la Tabla I se detallan las actividades actualmente disponibles dentro de cada una de estas secciones, junto con una
indicacion de las herramientas concretas trabajadas en cada
actividad. En la Fig. 2 se muestra una captura de la seccion
Seguridad en red del repositorio de actividades, con una
descripcion de parte de las actividades incluidas en la misma.
De un modo general se ha intentado seguir un esquema
uniforme a la hora de describir cada actividad. As, la documentacion de las actividades que actualmente forman parte del
repositorio sigue el siguiente esquema:
1. Descripcion general de la actividad
Objetivos (y vinculacion con contenidos teoricos)
Escenario: redes, maquinas, herramientas a emplear
Recursos: informacion de las herramientas, manuales, tutoriales externos, etc
2. Desarrollo guiado
Scripts de puesta en marcha para entornos
GNU/Linux y MS Windows 15
Pasos a seguir comentados
3. Actividades autonomas
Pruebas/experimentos a realizar
Cuestionarios
4. Descripcion de los entregables requeridos (opcional)
En la Fig. 2 se muestra el enunciado de la actividad Uso de
Shorewall: DMZ con doble firewall que sigue este esquema.
Se trata de una actividad que emplea una de las topologas de
red mas complejas presentes en el repositorio.
Como hemos senalado, por razones de comodidad y eficiencia, todas las actividades del repositorio hacen uso de una
imagen base comun. De este modo, una vez descargada esta
imagen durante el primer uso de una actividad del repositorio,
la puesta en marcha de las sucesivas actividades se simplifica.
El script de puesta en marcha que acompana a cada actividad
se encarga de la descarga de la imagen base (si esta no existe),
para, una vez esta este disponible, proceder a la creacion de
las imagenes incrementales usadas por cada MV concreta y
a la configuracion de sus parametros. En caso de que todas
estas tareas ya hubieran sido realizadas, el script simplemente
arrancara las maquinas que correspondan al ejercicio.
IV.
DE S IMULACIONES :
H ERRAMIENTA DE D ISE NO
DS BOX
Con el fin de simplificar al maximo la creacion de escenarios

por parte de los usuarios finales se ha desarrollado una
herramienta grafica multiplataforma denominada DS BOX, que
busca aprovechar las caractersticas mas u tiles del entorno
docente basado en tecnicas de virtualizacion descrito en las
secciones anteriores. Esta herramienta permite disenar las
pequenas redes de equipos virtualizados que conforman los
escenarios utilizados en las actividades descritas en la seccion
anterior u otros escenarios similares que precise crear un determinado usuario. Tambien permite configurar los parametros
de red de cada una de las conexiones presentes en los equipos
de la red, junto con caractersticas relativas al modo en que
V IRTUAL BOX asignara recursos a las MVs huesped, como
puede ser la cantidad de memoria RAM o el porcentaje de
15 Se pretende incluir tambi
en el fichero XML con la especificacion de la
red para DS BOX (ver seccion IV).
173
JNIC2015
Fig. 3. Vision general de DS BOX: escenario Uso de Shorewall: DMZ con doble firewall y configuracion de conexiones en cortafuegos contencion.
tiempo de CPU dedicado a cada maquina. Por u ltimo, desde

la propia interfaz de DS BOX se puede lanzar y controlar la
ejecucion de las MVs que constituyen el escenario simulado.
En la Fig. 3 se muestra un ejemplo del tipo de escenarios
que es posible disenar con DS BOX, en este caso se corresponde con la red utilizada en la actividad Uso de Shorewall: DMZ
con doble firewall de nuestro repositorio. Se muestra tambien
uno de los dialogos de configuracion de las conexiones de red
del cortafuegos contencion.
Esencialmente se trata de un editor grafico de redes donde
se pueden vincular equipos, seleccionados a partir de una
paleta con los tipos de equipo disponibles, con dispositivos de
red, seleccionados de entre la paleta de tipos de dispositivos
soportados. En tiempo de simulacion, a cada uno de los
equipos le correspondera una MV y los distintos dispositivos
de red seran simulados configurando, de forma apropiada,
las conexiones de red de estas maquinas, de acuerdo a las
funcionalidades que ofrezca la plataforma de virtualizacion
externa empleada.
En cuanto a la arquitectura de esta herramienta, se trata
de una aplicacion de escritorio Java, desarrollada sobre el
toolkit grafico JavaFX 8. Se ha disenado buscando la maxima
modularidad, de modo que la interfaz grafica para el diseno de
redes es independiente de los componentes encargados de interactuar con la plataforma de virtualizacion empleada para la
creacion, configuracion y control de las MVs que implementan
la simulacion. En la version actual se emplea V IRTUAL BOX
como plataforma de virtualizacion externa, aplicando todas las
optimizaciones descritas en las secciones precedentes: comparticion de imagenes base mediante imagenes diferenciales,
uso de Guest Properties para la configuracion interna de los
huespedes, etc. La interaccion con V IRTUAL BOX se lleva a
cabo empleando la API de servicios web disponible para esta
herramienta, en concreto la version Java basada en JAX-WS
(Java API for XML Web Services). De este modo, realizando
invocaciones SOAP (Simple Object Access Protocol) a los

metodos publicados mediante esta API es posible crear y
configurar las MVs utilizadas y controlar su ejecucion.
Por defecto, el tipo de equipos soportados por la version
actual de DS BOX emplea la misma imagen base descrita
en secciones precedentes. No obstante, es posible utilizar
cualquier tipo de imagen soportada por V IRTUAL BOX. En
estos casos no es posible la configuracion automatica de las
conexiones de red, salvo que en dicha imagen se cuente
con scripts especficos que procesen adecuadamente las Guest
Properties descritas en la tabla II. En lo que respecta al tipo de
dispositivos de red soportados, se corresponden con switches
o hubs Ethernet simulados configurando convenientemente los
equipos huesped para que empleen conexiones de tipo Internal
Network. Tambien se soporta la simulaciones de dos tipos de
conexiones con el exterior, utilizando los modos de conexion
bridged y NAT ofrecidos por V IRTUAL BOX.
Por u ltimo, toda la informacion relativa a las redes disenadas
y los datos necesarios para configurar y poner en marcha las
MVs que posteriormente las simularan se almacena en documentos XML (eXtensible Markup Language). Esta funcionalidad hace posible la distribucion, intercambio y modificacion
de los entornos de red disenados y evita utilizar el tipo de shell
scripts descritos en la seccion previa, construidos ad hoc para
automatizar la puesta en marcha de los entornos simulados.
V.
Y C ONCLUSIONES
E VALUACI ON
En la Fig. 4 se presentan los resultados de las encuestas

realizadas a los alumnos que durante los cursos 2013/14 y
2014/15 han utilizado la aproximacion basada en maquinas
virtuales descrita en la seccion II para llevar a cabo parte de
las actividades practicas de la materia obligatoria de 6 creditos
ECTS Seguridad en Sistemas Informaticos. Esta materia se
ubica en el u ltimo curso del Grado en Ingeniera Informatica
174
JNIC2015
Fig. 4. Evaluacion global por parte del alumnado y principales problemas o dificultades.
impartido en la Escuela Superior de Ingeniera Informatica

del Campus de Ourense de la Universidad de Vigo. En ambas
ediciones del curso solo fueron utilizadas parte de las actividades incluidas en el repositorio descrito en la seccion III,
sin llegar a emplearse la herramienta grafica DS BOX, que no
estaba disponible.
Los resultados en cuanto a la valoracion global del uso de
entornos virtualizados son positivos, as como la percepcion
de los alumnos respeto a su facilidad de uso, a la adecuacion
de las actividades propuestas con respecto a los contenidos
de la materia y al nivel de dificultad en el desarrollo de los
ejercicios concretos que les fueron asignados.
Un aspecto clave en una aproximacion tan guiada como la
que presentamos en este trabajo esta en relacion con la capacidad real de este metodo de conseguir un aprendizaje realmente
significativo. Buena parte de los ejercicios propuestos pueden
completarse simplemente siguiendo los pasos detallados que
se ofrecen sin que el alumno llegue realmente a entender
totalmente que hace y por que lo hace. En nuestra encuesta
final se pregunta explcitamente por ese punto en el apartado
de problemas y dificultades, cuyos resultados tambien se
muestran en la Fig. 4. S hemos constatado un numero
relativamente alto de alumnos que declaran encontrar los
ejercicios propuestos como demasiado guiados o senalan que
no llegaron a poder interpretar completamente los resultados
obtenidos. Si bien para algunas de las actividades propuestas,
que simplemente pretenden presentar el uso de determinadas
herramientas de seguridad, ese es el comportamiento previsto,
s somos conscientes de que se debe realizar mas trabajo en la
propuesta de experimentos o comprobaciones adicionales que
reten a los alumnos a profundizar en los conceptos tratados
en las actividades realizadas.
En lo que respecta a las contribuciones de este trabajo
mas alla de su vertiente docente, hemos de senalar que se
ha puesto a disposicion de la comunidad una coleccion de
ejemplos de uso de un conjunto relativamente representativo
de herramientas de seguridad que sirven como punto de
partida para el autoaprendizaje y la experimentacion. Tambien
se ha desarrollado una herramienta grafica, DS BOX, que
permite disenar de forma sencilla entornos virtualizados como
los empleados en nuestro repositorio, cuya utilidad puede ir
claramente mas alla de su uso en una materia de seguridad.
Por u ltimo, en cuanto a las futuras lneas de trabajo, el
paso inmediato es integrar el uso de DS BOX en la docencia
practica de nuestra materia y explorar mejores formas de usar

este tipo de actividades guiadas para fomentar el interes de los
alumnos, proponiendo tareas mas autonomas que les permitan
profundizar en el aprendizaje y asimilacion de los conceptos
y herramientas estudiados en las actividades realizadas. En
cuanto al desarrollo futuro de DS BOX, la lnea a seguir se
orienta a mejorar las funcionalidades relativas al control de la
ejecucion de las simulaciones, la inclusion de asistentes que
simplifiquen incorporacion de nuevas imagenes base y nuevos
tipos de equipos a la paleta de componentes del editor de
redes o incorporar el uso de otros motores de virtualizacion,
bien de forma nativa o mediante APIs independientes como
libvirt.
R EFERENCIAS
[1] H. Bulbrook, Using virtual machines to privide a secure teaching lab
environment, whitepaper, Durham Technical Community College.
[2] J.A. Gil, F.J. Mora, F. Macia, A. Albadalejo, S. Ferrairo, Entorno de
red virtual para la realizacion de practicas realistas de administracion
de sistemas operativos y redes de computadores, XI Jornadas de la
Ensenanza Universitaria de la Informatica, JENUI2005, 2005.
[3] P. Gomez, Maquinas virtuales en las clases de informatica, XII Jornadas
de la Ensenanza Universitaria de la Informatica, JENUI2006, 2006.
[4] J. Hu, D. Cordel, C. Meinel, A virtual laboratory form IT security
education, Proc. EMISA 2004,pp.60-71, Luxemburgo, 2004.
[5] P.Y. Logan, Crafting an undergraduate information security emphasis
within information technology, Journal of Information System Education,
Vol. 13(3), pp. 227-247, 2002
[6] F.J. Ribadas-Pena, F.M Barcala-Rodrguez, V.M Darriba-Bilbao, J.OteroPombo, Diseno de un entorno virtualizado para la docencia practica de
Seguridad en Sistemas de Informacion, XIV Jornadas de la Ensenanza
Universitaria de la Informatica, JENUI2008, 2008
[7] Netkit, The poor mans system to experiment computer networking,
recurso en lnea http://wiki.netkit.org/ (ultimo acceso 9/8/2015)
[8] A. Ruiz-Martnez, F. Perenguez-Garca, R. Marn-Lopez,P.M. RuizMartnez, A.F. Skarmeta-Gomez, Teaching Advanced Concepts in Computer Networks: VNUML-UM Virtualization Tool, IEEE Transactions on
Learning Technologies, Vol. 6(1), pp. 85-96, 2013
[9] J. Son, C. Irrechukwu, P. Fitzgibbons, A Comparison of Virtual Lab
Solutions for Online Cyber Security Education, Communications of the
IIMA: Vol. 12(4), 2012
[10] R. Tikekar, Thomas Bacon, The challenges of designing lab exercises
for a curriculum in computer security, Journal of Computing on Small
Colleges (JCSC), Vol. 18(5), pp. 175-183, 2003.
[11] Adan Vollrath, Steven Jenkins, Using virtual machines for teaching
system administration, Journal of Computing on Small Colleges (JCSC),
Vol. 20(2), pp. 287-292, 2004.
[12] Virtual Networks over linuX (VNX), recurso en lnea http://web.dit.upm.
es/vnxwiki/ (ultimo acceso 9/8/2015).
[13] C. Willems, C. Meinel, Practical Network Security Teaching in an
Online Virtual Laboratory, Proc. 2011 Intl. Conference on Security &
Management (SAM 2011), pp. 65-71, 2011.
175
JNIC2015

1
Experiencias actualizando la asignatura de

Seguridad Informatica para los grados de
Ingeniera Informatica
Marta Beltran e Isaac Martn de Diego
Universidad Rey Juan Carlos, Madrid (Espa
na)
marta.beltran@urjc.es e isaac.martin@urjc.es
Resumen En el curso 2014/2015 las asignaturas de
Seguridad Inform
atica de los grados de Inform
atica de
la Universidad Rey Juan Carlos se han replanteado,
respetando los planes de estudios originales pero innovando
con un enfoque mucho m
as pr
actico y que atienda a las
recomendaciones internacionales que se han realizado en el
area en los u
ltimos dos o tres a
nos. Este articulo recoge
el contexto en el que se ha trabajado para realizar este
cambio, las experiencias y resultados obtenidos y algunas
ideas para trabajar en el futuro.
n
I. Introduccio
Distintos organismos e instituciones como NERC,
NIST, ISACA, ENISA o el DHS han propuesto en
los u
ltimos a
nos mejores practicas para la formacion y
concienciacion en Seguridad Informatica. Si se analiza
toda esta documentaci
on, se suelen proponer niveles de
profundizacion, contenidos asociados a cada uno de ellos
y roles que deberan formarse y/o concienciarse a un
nivel o a otro. Desafortunadamente, si se asocia la
concienciacion con la comprension del Que (informacion,
sensibilizacion) y la formacion con la comprension del
Como (conocimiento), todas estas propuestas dejan sin
tratar la Educacion, que se asociara con el Por que. Y
este es justo el nivel en el que deberan encontrarse las
asignaturas de Seguridad Informatica en las titulaciones
universitarias.
Sin este tipo de recomendaciones y guas, ni
nacionales ni internacionales, la mayor parte de las
nuevas titulaciones en el Espacio Europeo de Educacion
Superior (EEES), es decir, los nuevos grados, han
planteado casi siempre modulos curriculares o asignaturas
completas de Seguridad Informatica con planteamientos
mayoritariamente teoricos y centrados en la criptografa.
Sin embargo cada vez esta mas claro que este enfoque se
aleja del tipo de educacion que se debera estar dando en
la universidad para este area de la informatica ([1]). Las
necesidades de los nuevos profesionales en una sociedad
tecnologica y en red como la actual, en la que la Seguridad
Informatica afecta practicamente a todas las facetas de la
vida cotidiana de personas y organizaciones, nos obligan a
realizar un esfuerzo desde las universidades para adaptar
nuestros contenidos y enfoques pedagogicos ([2], [3], [4],
[5]).
Este esfuerzo ha comenzado a realizarse en la
Universidad Rey Juan Carlos (Madrid) en el curso
2014/2015, probando un nuevo enfoque para ocho grupos
de Seguridad Informatica de las titulaciones de grado

que se imparten en esta universidad y en las que se
imparte esta asignatura (Grado en Ingeniera Informatica,
Grado en Ingeniera del Software y Grado en Ingeniera
de Computadores). Con este enfoque se persigue un
equilibrio entre la teora y la practica, y tambien entre
los contenidos basicos que se deben cubrir con este tipo de
asignaturas introductorias y los contenidos mas avanzados
y relativos a las nuevas tendencias en TIC que permitan
motivar a los alumnos con la asignatura.
El resto del artculo se estructura de la siguiente
manera. En la seccion II se presenta el contexto en el
que se ha desarrollado la experiencia. En la seccion III
se resumen los aspectos mas importantes de la Gua de
Asignatura que se han implantado en el curso 2014/2015
para la asignatura Seguridad Informatica (obligatoria, 6
creditos y en el tercer curso de todos los grados. En
la seccion IV se detallan todas las actividades practicas
realizadas con los alumnos y en la seccion V se comentan
detalles acerca de la implantacion de la nueva gua y de los
resultados obtenidos en este primer curso. Finalmente la
seccion VI resume las conclusiones obtenidas y las lneas
mas interesantes de trabajo futuro.
II. Contexto
Seg
un los acuerdos de la Conferencia de Decanos y
Directores de Informatica (CODDI) sobre titulaciones
en el EEES (del a
no 2004 y del a
no 2007, [6]) el
ttulo de Grado de Ingeniera Informatica dentro de
sus Contenidos Formativos Comunes, debe incluir una
categora de Contenidos Especficos de la Ingeniera
en Informatica. Dentro de esta categora se incluye
a su vez una subcategora de Sistemas Operativos,
Sistemas Distribuidos y Redes en la que se menciona
explcitamente la Seguridad.
Ademas en estos
acuerdos se establece una competencia para la titulacion
que implica que los alumnos aprendan a Dise
nar,
desarrollar, evaluar y asegurar la accesibilidad, ergonoma,
usabilidad y seguridad de los sistemas, aplicaciones y
servicios informaticos, as como de la informacion que
proporcionan, conforme a la legislacion y normativa
vigentes.
Atendiendo a estos acuerdos, la Universidad Rey Juan
Carlos incluyo en el dise
no de los tres grados impartidos
por la ETSII (Escuela Tecnica Superior de Ingeniera
Informatica), es decir, en los grados de Ingeniera
176
JNIC2015

2
Informatica, Ingeniera del Software e Ingeniera de

Computadores, una asignatura de 6 creditos en el
tercer curso denominada Seguridad Informatica. Los
descriptores de esta asignatura que aparecen en BOE (con
ciertos matices para cada una de las titulaciones, pero
esencialmente, estos) son Introduccion a la seguridad
en sistemas informaticos.
Polticas de seguridad.
Criptografa.
Protocolos.
Infraestructura de clave
p
ublica. Firma y certificados digitales. Seguridad en
Bases de Datos. Seguridad en Redes. Seguridad en
Sistemas Operativos. Tecnicas de hacking. Seguridad en
instalaciones p
ublicas y privadas. Proteccion de datos.
Normativas y legislacion en seguridad.
Estas asignaturas de Seguridad Informatica se
impartieron por primera vez en el curso 2011/2012, y
siguiendo la tradicion de las antiguas asignaturas de
las titulaciones de Informatica en extincion, el enfoque
que se siguio fue esencialmente teorico y centrado en la
criptografa.
Sin embargo ha sido justo en estos a
nos cuando ha
comenzado a surgir una preocupacion importante por
la falta de profesionales con competencias adecuadas
para trabajar en ciberseguridad y diferentes organismos,
instituciones y centros educativos han comenzado a
realizar analisis y recomendaciones especficas para guiar a
los profesores de las asignaturas de Seguridad Informatica,
tanto de grado como de post-grado, en el planteamiento
de sus contenidos teoricos y practicos.
Si observamos recomendaciones academicas en
contextos internacionales, el Computing Curricula
de IEEE y ACM en el 2013 ([7]) ha incluido dentro
del Body of Knowledge de Computer Science un area
especifica denominada Information Assurance and
Security (IAS). Dentro de este area se deben incluir los
siguientes aspectos de manera obligatoria Foundational
Concepts in Security.
Principles of Secure Design.
Defensive Programming. Threats and Attacks. Network
Security. Cryptography y los siguientes de manera
optativa Web Security. Platform Security. Security
Policy and Governance.
Digital Forensics.
Secure
Software Engineering.
Ademas, IBM, dentro del IBM Cybersecurity
Innovation Program ([8]) ha propuesto tambien unas
mejores practicas para la educacion universitaria en
ciberseguridad, identificando en este caso cinco areas
fundamentales: Security and information assurance
overview, Data protection and access management,
Infrastructure security, Intelligence, analytics, and
compliance and Secure software engineering.
A estos dos ejemplos hay que sumarles iniciativas
como National Iniciative for Cybersecurity Education
(NICE) del NIST ([9]), las del gobierno de Reino
Unido ([10]), el proyecto europeo ENGENSEC ([11]),
el Georgia Tech Information Security Center ([12]) o el
Purdue University Center for Education and Research in
Information Assurance and Safety ([13]).
Teniendo todo esto en cuenta, en el curso 2014/2015
hemos re-planteado la asignatura de Seguridad
Informatica de las titulaciones de grado de la ETSII
con lo siguiente objetivos:

1. Actualizar los contenidos de la asignatura para que se
ajusten a las u
ltimas recomendaciones internacionales y a
las necesidades del mercado laboral.
2. Realizar esta actualizacion de manera que se puedan
re-aprovechar los esfuerzos lo mas posible, es decir,
aprovechando el nuevo planteamiento en los tres grados
en los que se imparte la asignatura.
3. Incrementar significativamente el n
umero de horas que
en la asignatura se dedican a actividades practicas.
4. Mejorar la percepcion que los alumnos tienen de
la asignatura, consiguiendo as incrementar la tasa de
presentados a la primera convocatoria y aumentar el
n
umero de trabajos fin de grado defendidos en la escuela
relativos a Seguridad Informatica.
5. Permitir a los alumnos adquirir competencias que les
ayuden a auto-formarse en el futuro, ya que en un area
tan dinamica y con una evolucion tan rapida como es
la Seguridad Informatica, esto es imprescindible para su
futura vida profesional. Es importante que adquieran
unas competencias basicas en la materia pero tambien que
aprendan a aprender para el futuro.
En este proceso, se han tenido que considerar ciertas
barreras o restricciones, que esencialmente se pueden
resumir en:
Barreras de organizaci
on academica, ya que no se
planteaba una modificacion de los planes de estudio. Esto
supone, por ejemplo, que se debe respetar su grado de
experimentalidad, de manera que los alumnos pasen 40
horas en el aula de teora y 20 horas en los laboratorios.
Barreras de organizaci
on de laboratorios, ya que no es
posible realizar ciertas practicas dentro de la red de la
universidad ni contar con mas de un cierto n
umero de
horas en laboratorios para la asignatura (como ya se ha
avanzado, se dispone de 20 horas en total a lo largo del
cuatrimestre para cada uno de los grupos de la asignatura,
y en la mayor parte de ellos, no se dispone de puestos
suficientes para que todos los alumnos trabajen, por lo
que es necesario hacer desdobles).
Barreras presupuestarias, ya que no se cuenta con
presupuesto para la actualizacion de los laboratorios
dedicados a la asignatura.
Barreras de personal, ya que no se cuenta en la
actualidad con un n
umero suficiente de profesores en la
escuela expertos en la materia.
En las siguiente secciones se detalla como se intentaron
superar todas estas barreras para conseguir los objetivos
propuestos.
III. Gua de la asignatura
En esta seccion vamos a resumir los aspectos mas
importantes de la gua de la asignatura Seguridad
Informatica en el curso 2014/2015 para el Grado de
Ingeniera Informatica ([14]). Como ya se ha comentado,
se trata de una asignatura obligatoria de 6 creditos (cuatro
horas de clase a la semana durante 16 semanas) en el
tercer curso. Las guas para las otras dos titulaciones
(en los grados de Software y Computadores) han sido
muy similares pero se han modificado ciertos matices para
177
JNIC2015

3
que se adapten mejor al plan de estudios y al perfil de

alumnado en cada caso.
A. Pre-requisitos
Se recomienda haber cursado previamente (aunque no
se exige) las asignaturas Introduccion a la Programacion,
Estructuras de datos, Programacion Orientada a Objetos,
Bases de Datos y Redes de Computadores.
B. Contenidos
La tabla I resume los contenidos planteados en la gua
de la asignatura, como se pueden observar, divididos en
tres grandes bloques.
C. Actividades
La asignatura se ha dividido por semanas, de manera
que cada semana se trabaja con una gua de estudio
y, aproximadamente, con una de las unidades reflejadas
en la tabla I. En esta gua se especifican todas las
actividades que el alumno debe realizar de manera
obligatoria durante la semana y tambien se plantean
actividades optativas para aquellos alumnos que quieran
profundizar mas en alguna materia de su interes. En esta
guas se proporcionan todos los enlaces a la documentacion
necesaria as como unas cuestiones de auto-evaluacion
que permiten a los alumnos valorar si han cumplido
suficientemente los objetivos de la semana.
Seg
un la semana las actividades asociadas a la
asignatura han sido:
Clases magistrales.
Presentaciones de alumnos.
Seminarios.
Lecturas.
Pr
acticas en el aula (casos y talleres).
Pr
acticas en laboratorio.
Otras actividades (ciclos de conferencias, eventos fuera
del campus, etc.).
ctico o hands-on
IV. Enfoque pra
A. Pr
acticas en el aula
Como se ha comentado con anterioridad, uno de los
objetivos de la asignatura consista en conseguir un
equilibrio entre la teora y la practica. Para ello, en las
semanas de trabajo en el aula, se ha intentado siempre
que una de las clases de dos horas fueran de formato clase
magistral, presentaciones o seminarios, mientras que la
otra clase de dos horas se dedicara a trabajo practico
de los alumnos en el aula. En la tabla II se muestra la
planificacion de este tipo de actividades.
B. Pr
acticas en el laboratorio
Estas practicas se han realizado en las 20 horas de
laboratorio (las que en el plan de estudios se consideran
horas de practicas) y se han dividido en dos grandes
bloques, un primer bloque de practicas asociadas a
Ataques (tres semanas de laboratorio) y un segundo
bloque de practicas asociadas a Contramedidas (dos
semanas de laboratorio). La tabla III resume las practicas
realizadas por los alumnos, siempre trabajando por

parejas.
Para las practicas de ataques se han utilizado
herramientas tpicas como Maltego, Ettercap, Wireshark,
Nmap o Nessus, ademas de scripts de los propios
alumnos y aplicaciones vulnerables proporcionadas por
los profesores de la asignatura. Para las practicas de
contramedidas se han trabajado con codigos desarrollados
por los propios alumnos y por los profesores, tanto en C
como en Java.
C. Otras actividades pr
acticas
Este curso academico se han propuesto a los alumnos
tres actividades optativas para complementar, fuera del
horario de la asignatura, los contenidos estudiados.
La primera fue la asistencia al Ciclo de Seminarios sobre
Ciberseguridad de ISACA con la Universidad Rey Juan
Carlos. El programa de seminarios que se organizo en este
curso, todos ellos impartidos por miembros de ISACA, fue:
Lunes 9 de marzo de 2015: La importancia de la
auditora tecnologica en la empresa actual.
Jueves 12 de marzo de 2015:
Ciberseguridad en
entornos industriales.
Lunes 16 de marzo de 2015: C
omo se protegera
Espa
na ante una cibercrisis?.
Lunes 23 de marzo de 2015: Self Defending Mobile
Apps.
Jueves 26 de marzo de 2015:
Seguridad de la
informacion y auditora en entornos Cloud Computing.
La segunda fue la asistencia al URJC Techfest 4, que
en el a
no 2015 se organizo en forma de Jornadas de
Ciberseguridad durante 3 das. Durante estos tres das se
suspendieron las clases para facilitar la asistencia de los
alumnos a todas las actividades programadas y ademas
se ayudo a las asociaciones de alumnos organizadoras a
contactar con profesionales del sector que se involucraran
en charlas, seminarios y talleres.
Nosotros mismo
impartimos una conferencia el segundo da de las jornadas.
Y la tercera fue una quedada con los profesores de
la asignatura en el CyberCamp2014, aprovechando que
somos una universidad madrile
na y que este evento se
celebro relativamente cerca de nuestro campus.
n y resultados
V. Implantacio
En el curso 2014/2015 se ha impartido la asignatura
de Seguridad Informatica con este nuevo enfoque en
ocho grupos diferentes de las titulaciones de informatica,
con un total de 160 alumnos. Dos profesores se han
involucrado en el proyecto (los autores de este artculo),
ambos pertenecientes al Departamento de Ciencias
de la Computacion, Arquitectura de la Computacion,
Lenguajes y Sistemas Informaticos y Estadstica e
Investigacion Operativa.
La tabla IV muestra el sistema de evaluacion empleado
y las calificaciones medidas obtenidas por los alumnos
presentados de los ocho grupos. La teora de la asignatura
se ha evaluado con distintas pruebas escritas (examen final
tradicional, tests) mientras que las actividades practicas
en el aula y en el laboratorio se han evaluado con informes,
178
JNIC2015

4
TABLA I
tica
Nuevos contenidos de la asignatura de Seguridad Informa
Bloque I
Unidad 1
Introduccion
Informatica
Introduccion
Unidad 2
Conceptos basicos y definiciones
Bloque II
Unidad 3
Ataques y contramedidas
Anatoma de un ataque hacker
Unidad 4
Ataques a nivel de red y sistema
Unidad 5
Unidad 6
Ataques a nivel de aplicacion y

servicio
Malware
Unidad 7
Mecanismos criptograficos
Unidad 8
Contramedidas
protocolos
Unidad 9
Defensas a nivel de software
Bloque III
Nuevas tendencias en Seguridad

Informatica
Seguridad en entornos moviles
Seguridad en sistemas operativos moviles. Proteccion de
dispositivos. Proteccion de aplicaciones. BYOD.
Seguridad en entornos cloud
Riesgos y amenazas especficos.
Contramedidas para
entornos cloud. Esquemas IAAA.
Ciberseguridad industrial y Riesgos y amenazas especificos.
Contramedidas para
proteccion de infraestructuras entornos industriales. Seguridad en Internet of Things y
crticas
Smart Cities.
Unidad 10
Unidad 11
Unidad 12
la
en
Seguridad Semanas 1 y 2 del semestre
redes
Introduccion a la SI. Los tres pilares de la seguridad.

Polticas y procedimientos. El factor humano. Normativas
y legislacion.
Riesgo, amenaza y vulnerabilidad. Incidentes, ataques y
eventos. Auditoras y analisis forense.
Semanas 3 a la 14
Tipos de atacantes y de ataques. Fases para construir un
ataque. Recogida de informacion. Anonimato
Envenenamientos, suplantacion y MitM. Secuestros de
sesion. Denegaciones de servicio con ataques a protocolos
de red.
Desbordamientos. Inyecciones de comandos y de codigo.
Forgeries.
Tipos de malware. Vectores de infeccion. Mecanismos
de propagacion, replica y auto-proteccion del malware.
Malware especifico. APTs.
Sistemas de cifrado de clave p
ublica y de clave privada.
DES, AES y RSA. Firma digital y funciones hash.
Mecanismos de autenticacion. Kerberos. Sistemas de
certificados.
Mecanismos para la proteccion del permetro y nuevos
modelos. Firewalls y DMZs. IDS, IPS y NAC. Soluciones
anti-malware. Protocolos de comunicaciones seguros (IPSec
y TLS).
Sistemas operativos de confianza. Mejores practicas para
la codificacion segura. Metodologas de desarrollo seguro.
Semanas 15 y 16
memorias, tests y defensas orales/presentaciones. En el

caso de la evaluacion de estas actividades practicas se
ha tenido muy en cuenta el grado de auto-formacion
de los alumnos en la materia, haciendo hincapie en la
importancia de que aprendan a aprender. Aunque se
ha mantenido el examen final tradicional en el periodo
de examenes de la escuela, el resto de las pruebas
y evaluaciones se han ido realizando a lo largo del
cuatrimestre.
de los resultados obtenidos, el equipo docente de la

asignatura es optimista. Las valoraciones docentes de
la asignatura tambien han sido muy positivas, as como
los comentarios y opiniones vertidos por los alumnos a
lo largo del curso. Y por u
ltimo cabe destacar que mas
de 50 alumnos han solicitado tema de Trabajo Fin de
Grado o Practicas en Empresa relacionado con materias
de Seguridad Informatica para el curso 2015/2016, lo que
tambien es un indicador muy importante.
Ademas de esta informacion tambien hay que

destacar un 88% de alumnos presentados en la
primera convocatoria. Esta tasa de presentados y las
calificaciones medias mejoran sustancialmente lo que se
vena consiguiendo en los cursos anteriores (entre un
54% y un 78% en los tres cursos anteriores dependiendo
del grupo). Aunque con un u
nico curso academico
como muestra es pronto para sacar conclusiones acerca
Como posibles aspectos de mejora para el curso proximo

se plantean: la mejora de los materiales teoricos y
practicos asociados a la asignatura y de las guas de
estudio, la mejora de las practicas en el laboratorio para
solventar todos las limitaciones y problemas detectados
este primer curso, la involucracion de mas profesores en
la constante actualizacion de la asignatura, y una posible
modificacion del sistema de evaluacion para premiar de
179
JNIC2015

5
TABLA II
n de actividades pra
cticas en el aula
Programacio
Semana 1
Semana 2
Semana 3
Semana 4
Semana 5
Semana 6
Semana 10
Semana 11
Semana 12
Semana 15
Semana 16
Polticas y procedimientos
Incidentes, ataques y eventos
Caso practico de definicion de polticas.

Analisis de los incidentes mas graves en el a
no 2013 y caso
practico de definicion de plan de respuesta ante incidentes.
Recogida de informacion
Taller de herramientas para footprinting.
Denegaciones de servicio con Taller de DDoS.
ataques a protocolos de red
Forgeries
Taller de XSS.
Malware
Taller de analisis de malware.
DES, AES y RSA
Caso practico para evaluar la fortaleza de distintos
criptosistemas.
Mecanismos para la proteccion Taller de TLS.
del permetro y nuevos modelos
Metodologas
de
desarrollo Caso practico de SAMM de OWASP.
seguro
BYOD
Lectura acerca de mejores practicas en BYOD.
Contramedidas para entornos Lectura acerca de mejores practicas en entornos cloud y
cloud
taller de SAML.
TABLA III
n de actividades pra
cticas en el laboratorio
Programacio
Semanas 7 a 9
Ataques
Semanas 13 y 14
Contramedidas
Hacking con buscadores (Google y Shodan).

Metadatos.
Sniers.
Scanners de red y de
vulnerabilidades.
Ataques de envenenamiento,
suplantacion y MitM. Desbordamientos. Inyecciones
de comandos y de codigo.
Desarrollo de criptosistemas: cifrado por sustitucion
monoalfabetico (algoritmo tipo Cesar), cifrado por
sustitucion polialfabetico (metodo de Vigenère) y
cifrado por transposicion. Criptoanalisis. Firma
digital. Certificados X.509.
TABLA IV
n y calificaciones
Sistema de evaluacio
Actividad
Peso en la nota Calificacion media
Teora (clases, presentaciones, seminarios)
40%
7.2
Practicas en el aula
40%
8.1
Pr
acticas en el laboratorio
20%
8.3
alguna manera a los alumnos que se han involucrado en las
actividades optativas (las denominadas otras actividades
practicas) dentro del marco regulatorio de la universidad
respecto a sistemas de evaluaci
on.
VI. Conclusiones y trabajo futuro
Seg
un los u
ltimos estudios, mas de la mitad de las
empresas reconocen que les cuesta encontrar personal
convenientemente formado en Seguridad Informatica.
Esta limitacion esta siendo en muchos casos una de las
causas por las que se ralentiza la adopcion de nuevos
paradigmas como Mobile, Cloud o IoT. Gobiernos y
corporaciones comienzan a presionar para reducir el skill
gap detectado y las universidades deben asumir su parte
de responsabilidad, actualizando los programas y los
enfoques de las asignaturas de Seguridad Informatica en
las instituciones de educacion superior. La ense

nanza
de esta materia no debe limitarse a la criptografa
sino basarse en una vision integral, multi-disciplinar
y holstica, debe proporcionar a los estudiantes las
herramientas para aprender por su cuenta en el futuro,
debe equilibrar la teora con la practica y contar en todo
lo posible con los futuros empleadores de los egresados.
En la Universidad Rey Juan Carlos se ha comenzado
a afrontar estos retos en el curso 2014/2015, recogiendo
la experiencia de los cursos anteriores, las sugerencias
de muchos profesores y alumnos, y las recomendaciones
de distintos organismos e instituciones nacionales e
internacionales. Las experiencias vividas y los resultados
obtenidos este primer curso academico en ocho grupos
de alumnos diferentes nos permite ser optimistas y seguir
trabajando en esta direccion con mas fuerza si cabe.
180
JNIC2015

6
En la actualidad se esta trabajando en diferentes

lneas. La primera, mejorar las practicas en el aula y
en el laboratorio para el proximo curso. En el caso
de estas u
ltimas se esta trabajando para realizar varias
con las herramientas mas importantes que incorpora la
distribucion Kali Linux y explotando las vulnerabilidades
de sistemas y aplicaciones que ponen a disposicion de
todos los estudiantes y profesionales proyectos como los
de OWASP, Google o Metasploit.
La segunda, lanzar en Enero de 2016 un MOOC
(Massive Online Open Course) en la nueva plataforma
URJCx que desarrolle contenidos similares a los de la
asignatura, pero mucho mas acotados, ya que el curso
durara seis semanas. Se pretende que el enfoque sea
tambien similar, por lo que se esta trabajando en adaptar
las actividades para poder realizarlas en formato online.
Este MOOC puede ser de gran utilidad, entre otros
colectivos, para los profesores que necesiten formarse en la
materia, ya que hemos detectado que la falta de formacion
entre el profesorado es en la actualidad una importante
barrera para una adecuada ense
nanza de la Seguridad
Informatica en la universidad.
Y la tercera, acreditar nuevos planes de estudio de grado
y post-grado especficos del area de la ciberseguridad en
la Universidad Rey Juan Carlos.
[10] National
Audit
Oce.
The
UK
cyber
security
strategy:
Landscape
review.
http://www.nao.org.uk/wp-content/uploads/2013/03/
Cyber-security-Full-report.pdf.
[11] Educating the next generation experts in cyber security.
http://engensec.eu/.
[12] Georgia
tech
information
security
center.
https://www.gtisc.gatech.edu/.
[13] Center for education and research in information assurance and
security (CERIAS). https://www.cerias.purdue.edu/.
[14] Marta Beltr
an and Isaac Martn de Diego. Gua de asignatura:
Seguridad inform
atica, grado en ingeniera inform
atica URJC
(2014/2015). http://miportal.urjc.es/guiasdocentes/.
Agradecimientos
Nuestro agradecimiento a los profesores que impartieron
las asignaturas de Seguridad Informatica en los cursos
anteriores, a los alumnos por sus valiosas aportaciones,
a todos los ponentes de los seminarios organizados para
la asignatura y a los ponentes de ISACA que participaron
en el Ciclo de Seminarios sobre Ciberseguridad de ISACA
(todos ellos nos han ayudado desinteresadamente) y a
todos los involucrados en la organizacion del Techfest 4
y del CyberCamp2014.
Referencias
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Frost
and
Sullivan.
The
2013
(ISC)2
global
information
security
workforce
study.
https://www.isc2.org/uploadedfiles/(isc)2 public content/2013
J. Mirkovic and T. Benzel. Teaching cybersecurity with
DeterLab. IEEE Security & Privacy, 10(1):7376, 2012.
Richard Weiss, Michael Locasto, Jens Mache, and Vincent
Nestler. Teaching cybersecurity through games: a cloud-based
approach.
Journal of Computing Sciences in Colleges,
29(1):113115, 2013.
L. Ben Othmane, V. Bhuse, and L.T. Lilien. Incorporating
lab experience into computer security courses. In Proceedings
of the 2013 World Congress on Computer and Information
Technology, pages 14, 2013.
K. Salah, M. Hammoud, and S. Zeadally.
Teaching
cybersecurity using the cloud. IEEE Transactions on Learning
Technologies, 2015.
Conferencia de Decanos y Directores de Inform
atica (CODDI).
Acuerdos de la conferencia de decanos y directores
de
inform
atica
sobre
titulaciones
en
el
EEES.
https://www.fi.upm.es/docs/conocenos/resumen de prensa/
151 CODDI.pdf.
IEEE and ACM.
Computer science curricula 2013.
https://www.acm.org/education/CS2013-final-report.pdf.
IBMs
cyber
security
innovation
program.
https://www-304.ibm.com/ibm/university/academic/pub/page/
teaching topics.
National
initiative
for
cybersecurity
education.
http://csrc.nist.gov/nice/.
181
JNIC2015

1
Laboratorio Docente de Ciberseguridad basado en

live-USB
Rafael A. Rodrguez Gomez1 , Francisco Lopez Perez, Mara Guarnido Ayllon, Monica Leyva
Garca, Anabel Reyes Maldonado, Antonio Mu
noz Gijon, Jose Enrique Cano, Jose Camacho1
E.T.S. de Ingeniera Informatica y de Telecomunicacion, Universidad de Granada
C/Periodista Daniel Saucedo Aranda s/n, E-18071, Granada
1
Correspondencia a: rodgom@ugr.es, josecamacho@ugr.es
Resumen Este artculo introduce una propuesta de laboratorio virtual para la docencia pr
actica en ciberseguridad en redes de ordenadores. Dicha soluci
on contribuye
a aumentar la flexibilidad y versatilidad de los escenarios
de red utilizados en las pr
acticas docentes. La soluci
on se
basa en dispositivos USB de inicio, o live-USB, que permiten arrancar un sistema operativo con varias m
aquinas
virtuales conectadas en red. Este sistema permite que un
alumno pueda utilizar con sencillez una red virtualizada
sin necesidad de realizar instalaciones en su propio PC.
Por otro lado, utilizando esta soluci
on en los laboratorios
docentes, se permite el dise
no de contenidos pr
acticos con
mayor agilidad, considerando escenarios m
as flexibles y de
mayor tama
no. El artculo introduce un caso pr
actico basado en el laboratorio virtual para ilustrar su versatilidad
y posibilidades.
n
I. Introduccio
El Informe Anual de Seguridad de Cisco [1] en 2014
establece que uno de los retos fundamentales para la industria en el ambito de las Tecnologas de la Informaci
on
y la Comunicacion (TIC) es encontrar profesionales adecuadamente preparados para prevenir, detectar y mitigar
amenazas de seguridad. En dicho informe, se estima que la
demanda de estos profesionales supera a la oferta en m
as
de un millon. Adicionalmente, el aumento en n
umero y
sofisticacion de las amenazas de seguridad lleva a la necesidad de potenciar determinadas habilidades anteriormente poco comunes en los profesionales de seguridad, como
es la capacidad de analisis de grandes conjuntos de datos
(Big Data) o el dominio de la seguridad en tecnologas novedosas, como comunicaciones moviles, Bring Your Own
Device (BYOD) y la nube.
La conocida web de profesionales TIC TechRepublic [2],
en una consulta realizada a influyentes profesionales ejecutivos y de equipos de recursos humanos, identifica que
las principales tendencias de contratacion de profesionales
TIC en 2014 incluiyen conocimientos de analisis Big Data,
comunicaciones moviles, la nube y seguridad en red. Otras
listas similares coinciden en la priorizacion de la seguridad
como uno de los principales retos del futuro inmediato.
La demanda actual de profesionales de seguridad requiere la definicion de unas instalaciones docentes de gran
flexibilidad, donde poder incorporar herramientas actuales y reproducir condiciones realistas en casos de estudio.
Por desgracia, el dise
no actual tpico de los laboratorios
de docencia pr
actica no permite dicha flexibilidad. La incorporacion de nuevas herramientas a los laboratorios requiere de la dedicacion exclusiva de personal de labora-
torio, que instala el nuevo software en un conjunto reducido de sistemas operativos con los que el alumno puede
iniciar la sesi
on. Dicha incorporaci
on debe ser planificada con suficiente antelaci
on, ya que se debe comprobar
que las nuevas herramientas funcionan adecuadamente y
no interfieren en el funcionamiento de otras herramientas
instaladas con anterioridad. Unido esto a la necesidad de
realizar las pr
acticas de seguridad en un entorno controlado, por lo general sin acceso a Internet y con funcionalidad
muy restringida, hace que el entorno de trabajo diste de
ser realista y que la generaci
on de material pr
actico para
la docencia de seguridad resulte limitada y poco eficiente.
Por otro lado, el n
umero limitado de sistemas operativos para el uso del laboratorio, as como de puestos en los
laboratorios, limita la reproducci
on de condiciones realistas en las sesiones pr
acticas. Tradicionalmente, para paliar este problema, se ha hecho uso de herramientas de
simulaci
on. No obstante, en el dominio de la seguridad en
red la simulaci
on impone serias limitaciones. Por ejemplo,
si bien es posible simular el tr
afico de una red con cierta fidelidad, no existen herramientas especializadas para
simular vulnerabilidades en sistemas, ataques concretos,
herramientas fundamentales en el an
alisis de la seguridad
en red, etc.
En este artculo se propone un dise
no de laboratorio virtual de seguridad en red que se adapta a las necesidades
docentes actuales. La soluci
on propuesta combina los conceptos de virtualizaci
on y USB de inicio (live-USB), que
permite arrancar un sistema operativo anfitri
on o host con
una red virtualizada de m
aquinas virtuales guest a traves
de VirtualBox. Dichas m
aquinas guest, as como el sistema host que las alberga, pueden ser personalizadas previamente por el docente, de acuerdo al trabajo de laboratorio
que se quiera ofrecer al alumno. Integrando la red virtualizada en dispositivos live-USB con suficiente capacidad,
es posible cambiar el comportamiento de cada PC en el
laboratorio de acuerdo a la pr
actica concreta a realizar.
La inclusi
on de nuevas herramientas en el laboratorio es
tan sencilla como la instalaci
on de dicha herramienta en
un nuevo USB de inicio. Esto aporta una flexibilidad y capacidad de generaci
on de nuevos materiales muy superior
a la actual. Adicionalmente, la virtualizaci
on permite escalar las pr
acticas a mayor cantidad de m
aquinas, ya que
cada PC real puede simular varias m
aquinas virtuales. La
combinaci
on de la virtualizaci
on con los dispositivos de
interconexi
on disponibles en los laboratorios (conmutado-
182
JNIC2015

2
res, encaminadores, tarjetas de red cableadas e inal

ambricas, etc.) ofrecen gran flexibilidad y gran realismo. Finalmente, los live-USB pueden ser utilizados por los alumnos
en sus equipos de casa para finalizar una practica inacabada o para preparar las practicas adecuadamente y con
antelacion.
El resto del artculo se estructura de la siguiente forma.
La propuesta se contextualiza en el laboratorio de redes
en la Escuela Superior de Ingenieras de Informatica y de
Telecomunicacion de la Universidad de Granada, introducido en la Seccion II. El dise
no del laboratorio virtual se
justifica en la Seccion III. La Seccion IV explica la configuracion del laboratorio por parte del docente. Un breve
caso de uso de este laboratorio aplicado al despliegue y
deteccion de una botnet es presentado en la Secci
on V.
Finalmente, en la Seccion VI se indican las conclusiones
del presente trabajo y lnea de trabajo futuro.
II. Laboratorio de Redes en la Escuela
tica y de
Superior de Ingenieras de Informa
n de la Universidad de
Telecomunicacio
Granada
Las practicas en materia de seguridad requieren escenarios realistas y cambiantes, donde haya dispositivos de
distintas caractersticas (firewalls, IDSs, servidores de todo tipo, etc) combinados con maquinas de usuario. Tambien es deseable poder disponer de una alta variedad de
sistemas operativos, con y sin parches de seguridad ante determinadas vulnerabilidades. Sin embargo, la flexibilidad necesaria para permitir la configuracion de dichos
escenarios est
a lejos de los laboratorios de red actuales.
En primer lugar, generalmente un laboratorio de red dispone de un conexionado fsico concreto y un n
umero de
m
aquinas fijo que no puede ser alterado a menos que se
invierta tiempo y dinero en el. Esta nueva configuraci
on
sera compleja y no puede ser modificada de una pr
actica
a otra. Otro inconveniente es que los alumnos requieren de
un acceso fsico al laboratorio para realizar las pr
acticas
docentes lo que les impide finalizarlas desde sus equipos
personales o prepararlas convenientemente con anterioridad a la asistencia al laboratorio.
En el resto del artculo, nos centraremos en el laboratorio de redes de la Escuela Superior de Ingenieras de
Informatica y de Telecomunicacion de la Universidad de
Granada (ETSIIT-UGR), donde se realizan entre otras las
practicas de asignaturas de seguridad en red. En todos los
laboratorios de la escuela se utiliza el sistema Rembo [3]
para descargar al inicio de cada practica una copia limpia
(alojada en un servidor centralizado) de un sistema operativo con el software necesario ya instalado en el. Esto permite que los alumnos dispongan de un equipo siempre en
perfectas condiciones. Sin embargo, tambien implica que
los docentes han de contactar, con tiempo suficiente, con
los tecnicos de la escuela para instalar el software necesario para sus practicas en la copia centralizada alojada en
el servidor Rembo. En concreto, en el laboratorio de redes
no se permite el acceso a Internet por motivos de seguridad, ya que los alumnos tienen permisos de super-usuario
en los equipos del mismo. Esto complica la instalaci
on de
Fig. 1. Estructura fsica y l

ogica de los puestos del laboratorio 3.7.
nuevo software necesario para la pr

actica a realizar.
El laboratorio de redes dispone de 26 puestos de usuario
y varios equipos de comunicaciones e interconexi
on de redes, como puede observarse en la Fig. 1. Estos sistemas se
articulan en base a unos bloques de equipos denominados
islas que pueden funcionar de forma independiente entre
s. Existen 4 islas en el laboratorio que contienen de 6 a 7
equipos y 6 routers en cada una de ellas.
Este laboratorio presenta dos conexionados fsicos fundamentales: la red de gesti
on y la red de datos. La red
de datos es la que interconecta los equipos de una misma
isla entre s y con las dem
as islas. La red de gesti
on interconecta en un mismo switch todos los dispositivos del
laboratorio.
En este laboratorio los alumnos pueden cargar, gracias
al uso de Rembo, distintos sistemas operativos en los equipos. Concretamente, para tener acceso de super-usuario y
poder utilizar el conexionado de red mencionado anteriormente es necesario arrancar en una opci
on concreta que
s
olo permite escoger los sistemas operativos Windows XP,
Ubuntu 8.10 y Ubuntu 12.04. Por motivos de seguridad la
elecci
on de la opci
on de redes inhabilita la interfaz de red
que da acceso a Internet a los equipos as que, entre otras
desventajas, la instalaci
on de nuevos paquetes software en
el curso de las pr
acticas se hace, desde esta opci
on, bastante compleja.
La carga del sistema operativo escogido a traves de
Rembo puede tardar, dependiendo de la carga de la red,
hasta 10 minutos en los que el alumno no dispone de equipo con el que comenzar la pr
actica. Por otro lado, cualquier modificaci
on de las im
agenes de los sistemas operativos almacenados en el servidor centralizado de Rembo
debe pasar por un tecnico de la escuela limitando de alguna forma la libertad y agilidad del docente encargado de
las pr
acticas.
n propuesta
III. Solucio
Con el objetivo de paliar estas deficiencias en el presente
artculo se busca una arquitectura para un laboratorio de
red que cumpla los requisitos de flexibilidad, simplicidad,
183
JNIC2015

3
seguridad y portabilidad. Siguiendo estos requisitos, se ha

escogido una estructura de laboratorio de red con m
aquinas fsicas conectadas entre s por medio de dispositivos
fsicos de interconexion. En estas maquinas fsicas cada
alumno conecta un live-USB con el que arranca el sistema
operativo preparado para la practica concreta a desarrollar. Cabe destacar que estos live-USB contienen una serie
de maquinas virtuales (dentro del software VirtualBox).
Por un lado, las maquinas virtuales aportan flexibilidad en cuanto al n
umero de maquinas de las que dispone
el laboratorio. Por otro lado, el uso de live-USB permite
flexibilidad con respecto a los S.O. utilizados y simplicidad para configurar los dispositivos USB. Adicionalmente,
estos USB siempre permanecen en el estado inicial para
poder volver a ser utilizados en la siguiente practica o reto
por distintos alumnos. Por u
ltimo, es posible utilizar este
sistema en un u
nico equipo como laboratorio en casa con
el objetivo de que el alumnado pueda avanzar, finalizar o
rehacer las practicas desde su equipo personal.
A continuaci
on se discuten algunas de las caractersticas
del sistema.
A. Software de virtualizaci
on
La virtualizacion permite utilizar mas de un sistema
operativo en un mismo ordenador, de forma simult
anea y
persistente. Utiliza las ventajas de emuladores y sistemas
con arranque m
ultiple, pero eliminando sus limitaciones,
ya que los emuladores no permiten ejecutar directamente
el c
odigo del sistema huesped y los sistemas con arranques
m
ultiples permiten mas de un sistema operativo pero no
simultaneo.
El proceso de virtualizacion se basa principalmente en
montar un sistema operativo, denominado maquina virtual o guest, mediante la instalacion de un software, el
hipervisor, por encima del SO que usamos normalmente,
llamado anfitrion o host.
Uno de los inconvenientes de las maquinas virtuales es
su coste computacional, que lleva a que la ejecuci
on de un
gran n
umero maquinas pueda saturar facilmente los recursos de la m
aquina anfitriona. Aun as, suele compensar
la perdida de eficiencia con la gran flexibilidad y realismo
que aportan.
Actualmente las plataformas de virtualizacion m
as importantes para el uso de maquinas virtuales son las siguientes:
VirtualBox (www.virtualbox.org) Solucion profesional
gratuita y disponible como software de codigo abierto
GNU (GPL). Tiene soporte multi-plataforma incluyendo
Solaris y una lista creciente de caractersticas como instalar el software con privilegios adicionales a la m
aquina
fsica, tareas como compartir, archivos, unidades, perifericos, etc.
KVM (www.linux-kvm.org) Solucion para implementar
virtualizacion completa con Linux. Utiliza una versi
on modificada de QEMU (emulador de procesadores), que permite obtener un rendimiento espectacular cuando no se
trata de Microsoft Windows como guest. No tiene un soporte completo para controladores.
VMWare (www.vmware.com) Es el est

andar del mercado ya que es el m
as r
apido, estable y seguro, principalmente en sus versiones de pago. Actualmente ofrece dos
versiones gratuitas, VMWare Player y VMWareESXi, pero con ciertas limitaciones. Es multi-plataforma.
De entre estas opciones, la m
as atractiva es VirtualBox,
ya que combina su car
acter de software libre con unas
prestaciones altamente competitivas.
Una herramienta muy interesante que mezcla simulaci
on, emulaci
on y virtualizaci
on es GNS3 (www.gns3.net).
Este software permite, mediante un entorno gr
afico, dibujar y configurar una topologa de red y posteriormente
simular su comportamiento. Soporta configuraci
on y emulaci
on de dispositivos de interconexi
on con sistema operativo IOS CISCO e incorpora m
aquinas virtuales a traves
de VirtualBox a la topologa de red dise
nada. Este software permite simular niveles de enlace diversos como Ethernet, FrameRelay, ATM, etc., as como dispositivos de
interconexi
on del nivel de enlace como switches. Adem
as,
el tr
afico que se genera en la red simulada puede ser capturado con el software de monitorizaci
on de paquetes Wireshark. Sin embargo, la emulaci
on de sistemas de interconexi
on en GNS3 ralentiza el procesamiento. As, considerando que los laboratorios de pr
acticas tienen disponibles
dispositivos fsicos de interconexi
on, no parece necesario,
sino contraproducente, su emulaci
on.
Teniendo en cuenta los objetivos especificados para el
laboratorio virtual, la disponibilidad de hardware real de
interconexi
on de red en los laboratorios de la ETSIIT, y
analizando todas las posibilidades disponibles, la opci
on
elegida en este trabajo pasa por combinar el uso de VirtualBox con dispositivos de interconexi
on reales. De esta
forma se obtiene un entorno flexible y realista que minimiza los recursos para la virtualizaci
on. Esto permite escalar
las pr
acticas docentes a mayor cantidad de m
aquinas, ya
que cada PC real puede simular varias m
aquinas virtuales
de dispositivos finales, que incluyan: m
aquinas vulnerables
a ataques, m
aquinas atacantes o de test de penetraci
on,
etc.
B. Sistema live USB
A la hora de dise
nar el sistema live-USB, es importante decidir cu
al va a ser el SO que actuar
a como host en
el mismo, as como las herramientas necesarias para su
conversi
on a live-USB.
Atendiendo al tipo de host a escoger, las distribuciones
GNU/Linux son quiz
as la opci
on m
as atractiva, ya que
cuentan con mayor experiencia trabajando con dispositivos Live. En comparaci
on con las distribuciones de otras
fabricantes, presentan las siguientes ventajas:
Alta velocidad de procesamiento.
Gran robustez gracias a su sistema de permisos.
Estabilidad frente a problemas, traducido en una gran
productividad.
Mayor flexibilidad y portabilidad.
Entre la extensa gama de sistemas operativos
GNU/Linux, Ubuntu puede ser una soluci
on acertada para tomar como host del USB. Adem
as de que permite
trabajar con software de virtualizaci
on como VirtualBox,
184
JNIC2015

4
Ubuntu cuenta con una interfaz grafica de trabajo bastante intuitiva. Por u
ltimo, Ubuntu cuenta con la herramienta
Systemback. Systemback realiza dos procesos de gran relevancia para el laboratorio virtual: genera una imagen donde vuelca una copia en vivo del sistema operativo Ubuntu
que la contiene y graba dicha imagen dentro de un dispositivo live-USB. En comparacion con otras opciones m
as
conocidas de generacion de live-USB, Systemback tiene
las siguientes ventajas:
Es capaz de generar copias en vivo de instant
aneas de
sistemas Ubuntu personalizados, no solo de distribuciones
oficiales como es el caso de UNetbootin y similares.
Puede generar live-USB a partir de las imagenes generadas.
Permite planificar, dentro del mismo sistema operativo
Ubuntu, la configuracion y personalizacion requerida de
maquinas virtuales, de modo que para realizar cambios en
el live-USB, basta con generar un nueva imagen a partir
de Systemback para que esta sea volcada en el dispositivo.
No produce errores en el etiquetado de las particiones
que se generan en el live-USB.
Se puede acceder a su codigo fuente, ademas de aceptar
mejoras propuestas por los usuarios gracias a su car
acter
de software libre.
Fig. 2. Esquema de red virtual de un live-USB.
IV. Montaje del laboratorio

Los escenarios de practica docente que se derivan de la
implementacion de esta herramienta pueden evolucionar
desde el trabajo local en un mismo equipo fsico, hasta
varios equipos de un mismo laboratorio de red conectados
entre s, tanto fsica como virtualmente. El mecanismo de
configuracion de los live-USB es el mismo para ambos escenarios, si bien la conectividad de red para interconectar
distintos dispositivos fsicos iniciados con live-USB es m
as
compleja.
De forma resumida, el docente debe realizar una serie
de pasos para crear el live-USB:
Instalar Oracle VM VirtualBox en su PC.
Crear una maquina virtual Ubuntu. Esta m
aquina
hara las veces de sistema host en el live-USB.
En dicha m
aquina host, debe instalarse la herramienta
VirtualBox.
Con VirtualBox, se generan (o a
naden si ya estaba creadas) las maquinas guest de acuerdo a los requerimientos
de la practica docente que se quiera realizar.
Con VirtualBox, se configura la red entre dichas m
aquinas.
En la maquina host, debe instalarse la herramienta Systemback, con la que se genera el live-USB.
Una vez acabada dicha configuracion, se obtiene una
red virtual en un u
nico dispositivo fsico, como ilustra con
un ejemplo la Fig. 2. Esta red virtual puede ser usada de
forma individual por parte de los estudiantes para realizar
experimentos practicos por su cuenta, con las siguientes
ventajas:
El alumno no tiene que hacer la instalacion del hipervisor en su propio ordenador, ni de las posibles herramientas
necesarias en las distintas maquinas guest y host. S
olo tiene que realizar una copia del live-USB desarrollado por
Fig. 3. Esquema de red con varios live-USB interconectados.
el profesor. Esto reduce el esfuerzo y tiempo del docente

en la resoluci
on de problemas de instalaci
on sin suponer
un esfuerzo adicional ya que el desarrollo de copias del
live-USB es sencillo.
Todos los alumnos disponen de la misma, exacta, configuraci
on de red virtualizada incluso a nivel de sistema
host. Esto reduce problemas que, por ejemplo, puedan surgir por la instalaci
on de un hipervisor concreto en distintos
SO.
La portabilidad de la red virtualizada es total, de forma que el alumno puede trabajar con la misma red en
distintas m
aquinas fsicas o bien distintos alumnos pueden compartir un mismo live-USB.
La configuraci
on de red externa esquematizada en la
Fig. 3 muestra la incorporaci
on de la red fsica del laboratorio al entorno virtual. El objetivo es lograr que, mediante el arranque del live-USB en distintos equipos del
laboratorio, sea posible la comunicaci
on entre m
aquinas
virtuales de manera remota. Para la recepci
on de conexiones externas que tienen como destino m
aquinas virtuales
de la red propia interna, se establece una correspondencia entre los puertos de la m
aquina host y las m
aquinas
virtuales, de manera que el host contiene una tabla de encaminamiento complementaria a traves de Iptables que le
permite hacer llegar las conexiones por estos puertos a sus
m
aquinas virtuales asociadas.
185
JNIC2015

5
V. Caso de uso del laboratorio de seguridad:

n de la botnet Zeus
despliegue y deteccio
El objetivo fundamental de esta seccion es mostrar la
funcionalidad de la arquitectura de laboratorio de redes
propuesta por medio de un caso de uso. En este caso concreto se va a utilizar la botnet Zeus como codigo malicioso
por ser un malware muy extendido y presentar una serie
de caractersticas de red interesantes que pueden ser de
una gran utilidad para aprender a utilizar herramientas
de deteccion de intrusiones (Snort), de analisis gr
afico de
logs (Splunk) o de visualizacion (AfterGlow).
este ejemplo concreto se ha utilizado Windows XP. El software para el botmaster cuenta con una herramienta para
editar y compilar un archivo de configuraci
on y crear un
archivo .bin y un ejecutable que ha de ser enviado y ejecutado en la m
aquina vctima. Este ejecutable es lo que se
conoce com
unmente como el troyano Zeus o Trojan.Zbot.
Adem
as el botmaster puede acceder a un panel de control donde se muestran estadsticas acerca de los n
umero
de ordenadores infectados, n
umero actual de los robots en
la lnea, n
umero de nuevos bots, actividad diaria de estos, estadsticas de los pases en los que se encuentran las
m
aquinas infectadas y SO de las mismas.
A. Entorno experimental
El entorno propuesto esta dise
nado para la ejecuci
on de
una practica en grupos de 2 alumnos sobre el funcionamiento y deteccion de las botnets. Las botnets son redes
de equipos comprometidos denominados bots que siguen
las ordenes de un operador humano llamado botmaster.
En concreto la botnet utilizada es Zeus, tambien conocida como Zbot, Kneber, PRG, NTOS, Wsnpoem and Gorhax [4]. Esta botnet dispone de una herramienta DIY (Doit-yourself) por medio de la cual el desarrollador facilita
todas las herramientas necesarias para construir y administrar la botnet. En esencia Zeus es una red de bots que se
comunican a traves del protocolo HTTP. Todas las comunicaciones de comando y control (C&C) se realizan remotamente desde un sitio web gestionado por el botmaster.
Zeus se ha especializado en robar credenciales bancarias en
los equipos con el sistema operativo Microsoft Windows.
Zeus se compone de un elemento cliente y otro servidor. El servidor cuenta con un generador de malware que
ayuda al botmaster a crear el codigo cliente del malware
cuyo nombre tecnico es PWS-ZBot, para posteriormente
infectar los equipos y unirlos a la red de bots, conect
andolos a un sitio web remoto que aloja el servidor Zeus. Por
u
ltimo, una vez que el troyano Zeus infecta una m
aquina, cuando el usuario final visita una pagina web con un
formulario el troyano captura cada uno de los campos de
dicho formulario y enva su contenido al servidor que los
almacena en una base de datos.
En la practica dise
nada como caso de uso se pretende
montar un entorno en el que Zeus pueda funcionar y ser
detectada. En esta practica cada alumno es responsable
de configurar y operar un equipo fsico que contiene al
menos una m
aquina virtual. La configuracion inicial de
sistemas operativos, herramientas instaladas y m
aquinas
virtuales disponibles viene determinada por los live-USB
que el docente entrega a cada alumno al inicio de la pr
actica y que han sido completamente configurados previamente por este.
En la Fig. 4 se detalla el mapa de red de los dos equipos
fsicos incluyendo las maquinas virtuales que contienen.
Estos son:
Equipo Fsico del Alumno 1:
Botmaster : El codigo de control para el botmaster de
Zeus es soportado por los siguientes sistemas operativos
XP / Vista / 7, as como 2003/2003R2/2008/2008R2. En
Servidor Web: El servidor Web es una m

aquina virtual de Ubuntu 12.04.4 LTS que incluye el servidor web
XAMPP, distribuci
on de Apache muy extendida por su facilidad de instalaci
on al incluir directamente la instalaci
on
de Apache, MySQL, PHP y Perl. En este servidor se han
instalado dos p
aginas web: una desde la que las maquinas vctima descargar
an el ejecutable del Zbot y otra que
contiene un formulario a rellenar por los clientes, de forma
que la informaci
on introducida en este pueda ser robada
por las m
aquinas comprometidas que la visiten.
Equipo Fsico del Alumno 2:
Detecci
on: Esta m
aquina es la anfitriona y su sistema
operativo es Ubuntu 12.04.4. El objetivo fundamental de
esta m
aquina es intentar detectar los equipos infectados
por el troyano Zeus analizando el tr
afico de red que pasa
por ella. Para esto se utilizaran tres herramientas fundamentalmente: Snort, Splunk y AfterGlow. Snort [5], es un
sniffer de paquetes y detector de intrusos basado en red
que implementa un motor de detecci
on de ataques y realiza un barrido de puertos que permite registrar, alertar
y responder ante cualquier anomala previamente definida. Splunk [6] es una herramienta para monitorizar datos,
almacenar, analizar y generar gr
aficos para alertar e identificar patrones de ataque o diagnosticar problemas en un
infraestructura IT. Por u
ltimo, AfterGlow [7] es una herramienta de visualizaci
on que puede ser instalada como
un plug-in de Splunk.
Bots: Los sistemas operativos que pueden ser infectados por el troyano Zeus, convirtiendose en bots HTTP,
son Windows XP, Windows 2000, Windows 7, Windows
95, Windows 98, Windows Me, Windows NT, Windows
Server 2003, Windows Server 2008 y Windows Vista. En
concreto para este caso de uso se ha escogido como sistema operativo de las m
aquinas virtuales que hacen de bot
Windows XP por ser el m
as ligero e implicar una menor
carga de memoria RAM en el equipo 2. El funcionamiento
del bot se basa en la interceptaci
on de la API de Windows,
mediante la ejecuci
on de una copia de su c
odigo en cada
proceso de usuario. Gracias a esto es capaz de detectar
la informaci
on introducida en los formularios de las p
aginas web que ser
a enviada con posterioridad al servidor de
Zeus. En todos los casos, se usaron licencias de software
Microsoft para uso docente.
186
JNIC2015

6
Fig. 4. Mapa de red del caso de uso del laboratorio de red.
Ubuntu: Con el fin de dotar la red de caractersticas

fieles a la realidad, se incluye esta maquina virtual no comprometida con el sistema operativo Ubuntu 12.04.4 LTS.
Gracias a esta sera posible demostrar si la detecci
on es
capaz de diferenciar entre trafico legtimo o anomalo.
B. Experimentaci
on
Siguiendo las fases de una botnet definidas en [4] la experimentacion para desplegar y utilizar la botnet se divide
en: concepcion, reclutamiento, interaccion y ejecuci
on del
ataque. Finalmente, se expondran brevemente algunas posibilidades de deteccion propuestas en la practica.
B.1 Concepcion
En la etapa de concepcion de la botnet es necesario crear
los ejecutables que infectaran las maquinas vctima y la
herramienta que se utilizara para controlarlos envi
andoles
mensajes C&C. Con el codigo DIY de Zeus estas dos operaciones se consiguen configurando el archivo config.txt.
El archivo de configuracion se divide en dos secciones:
staticConfig y dynamicConfig [8]. StaticConfig contiene
los parametros que son codificados en el bot y a los que
obedece y dynamicConfig los parametros que pueden ser
cambiados tras la creacion del Zbot, ya que no son codificados por el builder, sino que son guardados como una
configuracion encriptada a la que el bot tiene acceso a ellos
en todo momento.
Los parametros fundamentales a configurar de este archivo (tanto de la seccion staticConfig como de la secci
on
dynamicConfig) son:
timer logs: Frecuencia con la que el bot manda datos al
botmaster.
url config: URL donde se encuentra el config.bin. Esta

sera usada en la creacion del bot determinando el nombre
con el que el builder creara el .bin
WebFilters: Lista de URLs que deben ser monitorizadas. Los datos enviados a estas URLs tales como credenciales de banca online son capturados antes de establecerse
SSL y posteriormente enviados al servidor C&C. Adem
as,
ofrece la posibilidad de tomar una captura de pantalla del
cliente cuando este pulse el bot
on izquierdo de su rat
on,
siendo esto realmente u
til para el robo de n
umeros PIN.
WebFakes: Con este par
ametro se puede redirigir la direcci
on URL especificada WebFakes a una URL diferente,
versi
on potencialmente falsa de la misma.
Una vez que el archivo de configuraci
on ha sido editado
en base al fin perseguido se procede a la creaci
on de los
ejecutables utilizando la herramienta Zeus Builder.
Finalmente, es de resaltar que el objetivo de este caso de uso no es comprobar la calidad de la operaci
on de
Zeus, sino determinar la capacidad de detecci
on que los
alumnos pueden desarrollar para evitar que amenazas como esta puedan perpetrar la seguridad de los sistemas
que gestionen en un futuro. Es por ello que no se pretende
realizar pruebas con todas y cada una de las posibilidades que ofrece la botnet, sino m
as bien determinar si es
detectado en el momento de ejecuci
on del bot.exe y/o en
el intercambio de mensajes con el servidor C&C mientras
se roban datos introducidos en el formulario.
B.2 Reclutamiento e Interacci
on
Terminada la fase de concepci
on es necesario distribuir
e instalar el c
odigo malicioso generado a fin de reclutar
miembros de la botnet. Para esto, en esta pr
actica se utiliza
una p
agina web del servidor web desde la que las m
aquinas
vctima se descargan e instalan el c
odigo malicioso.
Tras la ejecuci
on, el cliente se convierte en un robot de la
botnet y el ejecutable descargado y usado en la instalaci
on
se elimina de forma autom
atica. A partir de este momento,
el botmaster en su servidor registra al equipo infectado y
puede comenzar la etapa de interacci
on a traves de la que
las comunicaciones C&C por medio del protocolo HTTP
se realizan. Las comunicaciones son codificadas utilizando
187
JNIC2015

7
Fig. 5. Panel de control de la botnet Zeus
Fig. 6. Logs detectados por Snort
Fig. 7. Detecci
on por Splunk
RC4 con una clave especificada por el botmaster en el

archivo de configuracion.
Inicialmente, el bot enva una solicitud GET al servidor

de comando y control para recuperar el archivo de configuracion. Ademas, este proceso se repite en tantas ocasiones
como indique el campo timer config del config.txt. Cada
vez que el bot debe enviar informacion al servidor de comando y control, enva una solicitud POST al servidor
central de la botnet. Este servidor utiliza una base de datos MySQL llamada bssnet para almacenar informaci
on
acerca de la botnet y las tareas que deben realizar.
B.3 Ejecuci
on del ataque
El objetivo final de toda botnet es realizar un ataque exitoso. Esto se lleva a cabo por medio de la infraestructura
de C&C establecida y configurada en las fases de reclutamiento e interacci
on. Para controlar esta infraestructura
el botmaster dispone de un panel de control centralizado.
En este panel de control se muestra informaci
on sobre
cu
antos equipos hay infectados, cu
anto tiempo est
an activos, el n
umero de reportes de cada bot, la version del bot
que tienen instalada, etc.
En cuanto el bot.exe es ejecutado, este roba autom
aticamente la informaci
on almacenada en PSTORE (Protected
Storage), la cual usualmente contiene guardadas contra-
188
JNIC2015

8
se
nas de Internet Explorer. Ademas comienza a capturar
y almacenar en la base de datos automaticamente contrase
nas FTP y POP3 que son enviadas a traves de la red.
Para consultar las contrase
nas que los bots han conseguido recopilar hay que dirigirse dentro del panel de control
a Menu>Reports>Search in database. En este momento,
se puede hacer un filtrado para buscar resultados de bots
concretos con determinados parametros, ver Fig. 5, o simplemente mostrar todos los resultados de la base de datos.
Es posible adicionalmente capturar la pantalla del bot
con el objetivo de encontrar las contrase
nas introducidas
por medio de teclados virtuales en lugar de introducidas en
los formularios directamente. Ademas, no solo se obtiene
informacion sobre las credenciales y capturas de pantalla,
sino que se aportan datos como la version exacta del sistema operativo o el tiempo online del mismo entre otros.
B.4 Deteccion
Para la parte de deteccion de la practica propuesta se
comienza por configurar Snort con las reglas de detecci
on
por defecto. Los logs generados por Snort son enviados a
Splunk para su visualizacion. A modo de ejemplo, en la
Fig. 6 se muestran algunos de esos logs.
Splunk permite la visualizacion de logs as como la aplicacion de reglas de deteccion. Al igual que con Snort, se
utilizan las reglas de deteccion por defecto en Splunk. En
la Fig. 7 se puede ver la alerta Posible Troyano Zeus
creada para la deteccion de una infeccion por parte del
Troyano Zeus. Adicionalmente, se muestra una visualizaci
on de Afterglow.
para su impartici
on en titulaciones de la Universidad de
Granada.
Agradecimientos
Este trabajo ha sido parcialmente financiado por el Programa de Innovaci
on Docente de la Universidad de Granada, con la beca 14-54.
Referencias
[1] C. Systems, Annual Report 2014, Tech. Rep., 2014,
http://investor.cisco.com/files/doc downloads/annual meeting/CiscoSystems-Annual-Report.pdf.
[2] T. Hammond, Top IT job skills for 2014: Big data, mobile, cloud, security, TechRepublic, Tech. Rep.,
2014, http://www.techrepublic.com/article/top-it-job-skills-in2014-big-data-mobile-cloud/.
[3] E. Young, REMBO: A Complete Pre-OS Remote Management
Solution REMBO Toolkit 2.0 Manual, 2002.
[4] R. A. Rodrguez-G
omez, G. Maci
a-Fern
andez, and P. GarcaTeodoro, Survey and Taxonomy of Botnet Research Through
Life-cycle, ACM Comput. Surv., vol. 45, no. 4, pp. 45:145:33,
Aug. 2013.
[5] P
agina principal de Snort, https://www.snort.org/, [Ultimo
acceso: 15 julio 2015].
[6] P
agina principal de Splunk, http://www.splunk.com/, [Ultimo acceso: 15 julio 2015].
[7] P
agina de AfterGlow, http://afterglow.sourceforge.net/, [Ultimo acceso: 15 julio 2015].
[8] W.
Xiangyu,
ZeuS
The
Missing
Manual,
http://www.docstoc.com/docs/90755139/ZeuS-The-Missing
Manual, [Ultimo
acceso: 15 de julio 2015].
B.5 Discusion
Si bien la experiencia preparada para ilustrar el uso del
laboratorio virtual es de claro interes en el marco la docencia practica de seguridad, y muestra la ventaja de dotar
de flexibilidad en n
umero y tipo de dispositivos a dicho
laboratorio, la realidad es que este sistema de detecci
on
tiene altas limitaciones para la deteccion de botnets. En
la actualidad, se esta trabajando en una propuesta de deteccion distribuida con el objeto de mejorar el rendimiento
de deteccion.
VI. Conclusiones y trabajo futuro
En este trabajo se ha presentado el dise
no de un laboratorio virtual basado en dispositivos live-USB. Dicho
laboratorio permite una amplia flexibilidad de contenidos
en las experiencias practicas y de topologas de red consideradas. En combinacion con los dispositivos fsicos de
interconexion disponibles en la Escuela Superior de Ingenieras de Informatica y de Telecomunicacion de la Universidad de Granada, dichos live-USB permiten la configuracion de escenarios de seguridad realistas que pueden
ser configurados con gran agilidad por parte del profesor.
Adicionalmente, los live-USB permiten a los estudiantes
realizar experimentos practicos de escenarios en red sin
m
as ayuda que su propio PC.
El trabajo futuro estara destinado a validar esta idea
de laboratorio con la generacion de materiales concretos
189
JNIC2015

1
Bachillerato de Excelencia, Criptografa y

Seguridad de la Informacion: Una oportunidad
Angel
Martn del Rey, Ascension Hernandez Encinas, Jes
us Martn Vaquero,
Araceli Queiruga Dios, Gerardo Rodrguez Sanchez
Departamento de Matematica Aplicada, Universidad de Salamanca
Resumen Dentro de las distintas modalidades de Bachillerato, se ha puesto en marcha en los dos u
ltimos a
nos el
Bachillerato de Investigaci
on/Excelencia (BIE) que tiene
como principal diferencia una colaboraci
on, m
as o menos
estrecha, con diferentes departamentos universitarios. Los
autores, miembros del Departamento de Matem
atica Aplicada de la Universidad de Salamanca, est
an colaborando
con dos IES (uno de Salamanca y otro de Zamora) realizando distintas actividades relacionadas con la Criptografa
y la Seguridad en la Informaci
on que han tenido muy buena
acogida entre los estudiantes de los centros involucrados. A
lo largo de este artculo describimos la experiencia realizada y analizamos las propuestas de futuro.
n
I. Introduccio
El Bachillerato de Investigaci
on/Excelencia desarrollado en la Comunidad Autonoma de Castilla y Leon tiene
como finalidad estimular el aprendizaje autonomo, el trabajo en equipo y el interes por conocer diferentes metodos
y tecnicas de investigaci
on, en colaboracion directa con
personal docente e investigador universitario [2]. La Universidad de Salamanca firmo en 2013 un convenio especfico de colaboracion con la Junta de Castilla y Leon para
el desarrollo de actividades asociadas a la investigacion
propias del BIE.
El BIE es una modalidad de Bachillerato que incorpora dos asignaturas (una en cada curso de Bachillerato) de
Introduccion a la Investigaci
on: Iniciacion a la investigacion en el primer curso y un proyecto de investigacion
en el segundo. El contenido de las asignaturas tiene una
parte variable que depende de las actividades dise
nadas
por los distintos departamentos universitarios que colaboran en la rama del BIE correspondiente y que en nuestro
caso es la rama de Ciencias y Tecnologa. Las actividades desarrolladas por los departamentos son muy diversas: conferencias, talleres, practicas de laboratorio, visitas
a centros, etc. Ademas, la asignatura correspondiente al
segundo curso del BIE conlleva la realizacion de un peque
no proyecto de investigaci
on individual (solo en casos
concretos se autoriza la realizacion de proyectos compartidos) que es co-tutorizado por el profesor universitario
que propone el proyecto y por un profesor del Instituto de
Educacion Secundaria (IES) correspondiente. Ese proyecto tiene una estructura fijada en la normativa vigente y se
defiende en sesion p
ublica usualmente durante el segundo
trimestre del curso de segundo de Bachillerato.
Hay que hacer constar que la realizacion de esta colaboracion esta dentro de un proyecto de innovacion docente
que financian la Universidad de Salamanca y la Junta de
Castilla y Leon, y en el que participan todos los profesores
que colaboran en el citado BIE. En este marco normativo,

el Departamento de Matematica Aplicada de la Universidad de Salamanca ha colaborado con el BIE impartido en
el IES Vaguada de la Palma de Salamanca durante los
cursos 20132014 y 20142015 y con el BIE desarrollado
en el IES Claudio Moyano de Zamora durante el curso
academico 20142015. En ambos IES, el BIE impartido
se corresponde con la rama de Ciencia y Tecnologa y la
tematica de las actividades llevadas a cabo se ha centrado
en la Criptografa y la Seguridad de la Informacion.
El objetivo de este trabajo es mostrar de manera detallada dicha participacion, para lo cual se describiran las
actividades llevadas a cabo y la actitud y acogida que se
ha tenido por parte de los alumnos.
El resto del trabajo se organiza como sigue: en la seccion II se justifica la eleccion de la materia a impartir para
pasar, en en las secciones III y IV, a describir la experiencia real llevada a cabo en los dos centros anteriormente
citados. Finalizamos el trabajo con la presentacion de las
conclusiones y de las posibles propuestas a realizar durante los proximos cursos.
Criptografa y Seguridad de la
II. Por que
n?: Una justificacio
n
Informacio
A la hora de elegir una materia para nuestra tarea con
estos alumnos de Bachillerato hay que considerar muchos
factores. Por un lado, hay que tener en cuenta su bagaje
matematico y por otro se trata de centrarnos en un tema
que sea de actualidad, de manera que nos permita motivar
e interesar a los alumnos desde el primer minuto. Creemos
que, bajo esas premisas, la solucion casi natural es dar los
primeros pasos en el apasionante mundo de la Criptografa
y de la Seguridad en la Informacion [3], siempre desde el
punto de vista de las Matematicas.
En pleno siglo XXI, con una explosion tecnologica sin
precedentes en la historia, donde, para casi todas las generaciones, el estar conectado es una necesidad de nuestra sociedad, es conveniente adentrarse en un conocimiento mas profundo de todo lo que rodea a la consecuencia
directa de la necesidad de conexion: la seguridad en la
transmision y gestion de datos. Obviamente, sera ingenuo pensar que con estas actividades que vamos a llevar a
cabo dentro del BIE vamos a resolver uno de los problemas acuciantes en nuestros das: la proteccion individual
y el uso racional de todas las herramientas que las tecnologas de la informacion ponen a nuestra disposicion. Pero
pensamos que pocas oportunidades tenemos de divulgar
los principios basicos a los alumnos no universitarios, que,
190
JNIC2015

2
ademas, son uno de los sectores mas vulnerables en estos

temas.
En definitiva, la eleccion de charlas y proyectos que tienen que ver con la Criptografa y la Seguridad de la Informacion nos parece la mas adecuada para cumplir un viejo
objetivo didactico poco habitual en el mundo de las Matematicas: ense
nar divirtiendo. El resultado, al menos en
estas primeras comunicaciones con el mundo no universitario, es espectacular. Los estudiantes muestran un interes
poco frecuente en temas que tengan que ver con las Matematicas y el hecho de que se utilicen palabras clave que
ellos conocen a traves del uso de Internet nos hace la motivacion de nuestras charlas y talleres muy facil.
Hemos abierto un camino de comunicaci
on con un sector
muy importante de la poblacion. Quiza uno de los mas expuestos a los problemas de seguridad y pensamos que estas
actividades pueden dar pie a una extension a otros niveles
educativos de charlas divulgativas que ayuden a reducir
los problemas de seguridad que tenemos como sociedad.
Hemos iniciado un camino que debemos explorar mas profundamente, utilizando las herramientas que la normativa
vigente pone a nuestro alcance.
Fig. 1. Diapositiva explicativa sobre la Envoltura Digital.
Algoritmos criptogrficos: El DNI electrnico

En marzo de 2006 comienza la expedicin del DNIe.
III. IES Vaguada de la Palma: los inicios

A. Curso 20132014
En el curso 20132014 un grupo de 22 estudiantes de
primer curso de Bachillerato del IES Vaguada de la Palma comenzaron las actividades del BIE. Dentro de estas actividades, los autores de este trabajo propusieron
un taller basico sobre Criptografa y codificacion y la
conferencia Matematicas para Proteger la Informacion,
programados para el primer cuatrimestre del curso y con
una duracion total de 3 horas: 2 horas en horario de tarde
para el taller y una hora por la ma
nana para la conferencia.
El taller inicial se present
o de forma eminentemente
practica, de modo que con unas peque
nas nociones teoricas los estudiantes aprendieron a cifrar y descifrar mensajes utilizando los criptosistemas clasicos [1]. Conceptos
como texto en claro, distribuci
on de claves o criptograma
son facilmente entendidos por los alumnos, as como la
diferencia entre cifrados por transposicion y cifrados por
sustitucion [7]. As, se les coment
o que la Criptografa es
una tecnologa de proteccion de datos, igual que los guantes son una tecnologa de proteccion de las manos. En este
sentido la Criptografa protege los datos contra los piratas
informaticos, los espas de empresa y los timadores, mientras que los guantes protegen las manos contra los cortes,
los rasgu
nos, el calor, el fro y las infecciones.
Como actividad complementaria del taller inicial, asistieron a la conferencia titulada Matematicas para Proteger la Informacion, que les permitio reforzar las tecnicas
matematicas en las que se fundamentan los principales
protocolos criptograficos (vease la Fig. 1), as como diferentes aplicaciones de la Criptografa y su utilizacion en
el da a da, como es el caso del DNIe, del que se detallaron, ademas de su utilidad, los algortimos que tienen
implementados y que se detallan en la diapositiva de la
Fig. 2.
Los algoritmos que tiene implementados son los siguientes:

Esquema de firma digital RSA.
Funcin resumen SHA-1.
Cifrado en bloque: Triple DES.
9
D.2'&+E"(1.+,'&+F'G4+AB>C
Fig. 2. Diapositiva sobre el DNIe (curso 20142015).
En este sentido cabe citar que los conceptos, tecnicas y

procedimientos que se mostraron a los alumnos fueron los
siguientes:
Fundamentos de los criptosistemas de clave secreta (cifrado en flujo y cifrado en bloque).
Fundamentos de los criptosistemas de clave p
ublica.
La envoltura digital.
Las funciones resumen y los message authentication codes.
La firma digital.
Ademas, se introdujeron de manera muy breve (y mediante ejemplos muy sencillos) algunos protocolos criptograficos. En este sentido, y teniendo en cuenta el nuevo
paradigma de computaci
on en la nube, se trato de reforzar (de alguna manera) dicho concepto con el siguiente
acertijo que se les propuso: es posible calcular de manera exacta la edad media de la clase de Bachillerato de
Investigaci
on del IES Vaguada de la Palma sin conocer ninguna de las edades de los alumnos? Estos recursos
didacticos ayudaron a reforzar la motivacion de los alumnos y a intuir de alguna manera las tecnicas empleadas
en el desarrollo de protocolos criptograficos.
Finalmente, se cerro el ciclo de actividades con una se-
191
JNIC2015

3
gunda conferencia titulada Modelos Matematicos en Ciberseguridad en la que se mostraron algunas tecnicas matematicas empleadas en Seguridad de la Informacion, concretamente:
Modelizacion matematica de la propagacion de malware.
Modelos matematicos para detectar amenazas en las redes de comunicaciones.
La carga matematica de esta charla es menor que la de
la anterior y se focalizo la atencion en las aplicaciones
practicas (vease la Fig. 3).
como aritmetica de reloj, como son la obtencion de la letra

del DNI, los dgitos de control de una cuenta bancaria o las
representaciones geometricas de congruencias aritmeticas
denominadas Chryzodes.
La Criptografa por sustitucion es una aplicacion sencilla de la Aritmetica modular, que permite ocultar un texto
en claro sin mas que sustituir (como su propio nombre indica) unas letras por otras. En este trabajo, el alumno
realizo un recorrido por la historia de la criptografa, utilizando la Fig. 4 como esquema/resumen de los comienzos
de la Criptografa, hasta el cifrado de Cesar. En la parte final de su trabajo incluyo una aplicacion en Geogebra
(http://www.geogebra.org/) que permita diferentes cifrados seg
un la clave propuesta.
Fig. 3. Diapositiva de Modelos Matem

aticos en Ciberseguridad.
B. Curso 20142015
Fig. 4. Presentaci
on de la historia de la Criptografa.
En el curso 20142015 se adhirieron al primer curso del

BIE otros 14 estudiantes. Impartimos las conferencias y
el taller tambien para estos nuevos estudiantes y tambien
les entusiasm
o.
Este mismo curso, los estudiantes del segundo curso del
BIE, realizaron los proyectos de investigaci
on propuestos:
Aritmetica modular y cifrados por sustitucion y Estudio del criptoanalisis de la maquina ENIGMA. Estos proyectos se realizaron en estrecha colaboracion con el tutor
del IES (perteneciente al departamento de Matematicas),
puesto que el tiempo que el alumno dedica a esta tarea se
reparte en una proporcion de 1 a 3 entre el IES y la Universidad. Es sorprendente como la b
usqueda de informacion,
el encontrar y entender nuevos programas informaticos o
el plasmar toda esa informacion en un trabajo final, ayuda
a los estudiantes a desarrollar sus habilidades de investigacion.
En el proyecto de investigaci
on Aritmetica modular y
cifrados por sustitucion se trataba de estudiar alguna de
las aplicaciones que la Aritmetica modular tiene en Criptografa, en particular en los sistemas de cifrado por sustitucion. Ademas, se propuso la utilizacion de alg
un lenguaje de programacion o software matematico que permitiera
realizar cifrados basados en aritmetica modular. A la mayora de estudiantes (y p
ublico en general) les sorprende
ver en la naturaleza y en la vida diaria las aplicaciones
de las Matematicas. En este caso, el alumno detallo varias
aplicaciones de la Aritmetica modular, tambien conocida
En este tipo de trabajos se valora que el alumno organice y planifique adecuadamente la investigacion que
realiza, recopilando informacion procedente de internet o
de fuentes documentales. Ademas, debe familiarizarse con
las b
usquedas bibliograficas y citarlas correctamente. Para
este trabajo en particular el alumno busco referencias en
la biblioteca de su instituto y tambien en la Universidad.
En un trabajo de Aritmetica modular no poda faltar la
referencia al libro de Gauss de Disquisitiones arithmeticae
[4]. Como introduccion a la criptografa y los criptosistemas de sustitucion consulto los libros [1], [5] y [3], ademas
del libro de divulgacion [6].
Por su parte, en la realizacion del segundo proyecto de
investigacion que verso sobre los fundamentos tanto tecnicos como matematicos de la maquina Enigma, la alumna
tuvo que afianzar conceptos matematicos relacionados con
la Teora de la Combinatoria. Asimismo, realizo una importante labor de documentacion y b
usqueda bibliografica
que completo con una visita a las instalaciones de Bletchley Park. Ademas dio la casualidad de que durante
la realizacion del trabajo de investigacion se estreno la
pelcula The Imitation Game (en Espa
na, Descifrando
Enigma) sobre el papel que jugo Alan Turing en el criptoanalisis de la maquina Enigma. Este hecho acrecento el
interes y motivacion de la alumna y de sus compa
neros como se pudo ver reflejado en la exposicion final que hizo-.
Como parte final de estos trabajos de investigacion,
192
JNIC2015

4
los alumnos expusieron ante un tribunal formado por el

profesor-tutor del departamento universitario, el coordinador del BIE en el IES y otro profesor del departamento
correspondiente del IES (en nuestro caso, el departamento
de Matematicas). Los dos trabajos de investigacion fueron
calificados con la maxima nota posible (de manera que la
calificacion obtenida en la defensa del proyecto les supuso
el 30 % de la calificacion total que se le asigna al proyecto).
Con posterioridad a la defensa de los proyectos de investigacion, los alumnos tuvieron la oportunidad de asistir a
la XIX Reunion Cientfica Alcuescar 2015 que se celebro en
Alcuescar (Caceres) entre los das 5 y 6 de marzo de 2015.
Este congreso fue organizado por la Asociacion de Investigacion de Secundaria con el objetivo de fomentar la investigacion en los adolescentes y a la que asistieron casi 300
alumnos de veinticinco institutos de Caceres, Salamanca,
Barcelona, Badajoz y Canada.
En este congreso, los alumnos tuvieron la oportunidad
de presentar sus proyectos de investigaci
on en formato
poster (vease la Fig. 5) y debatirlos con el resto de participantes. Creemos que fue un magnfico colofon a todas
las actividades realizadas dentro del BIE y sin duda un
acicate para proximas ediciones.
Fig. 5. P
oster presentado en Alcuescar 2015.
IV. Curso 201415, IES Claudio Moyano:

Extendiendo la experiencia
Durante el curso 20142015 se une a la implantacion del
BIE el IES Claudio Moyano de Zamora tambien en la
rama de Ciencia y Tecnologa. En este caso, el centro universitario de referencia es la Escuela Politecnica Superior
de Zamora, cuyas instalaciones estan a escasos metros del
IES mencionado. Durante este curso, los profesores encargados de poner en marcha este Bachillerato nos solicitan
una relacion de actividades que se puedan llevar a cabo a
lo largo del curso academico. Contando con la experiencia del curso anterior en el IES Vaguada de la Palma,
proponemos una serie de charlas que tienen que ver con la
historia de la criptografa y con la descripcion de algunos
protocolos criptograficos. Todas las actividades se han llevado a cabo en las instalaciones de la Escuela Politecnica
de Zamora. Una vez elaborada la lista de actividades, con
la participacion de otros departamentos de la Escuela, los
alumnos y profesores del IES Claudio Moyano eligen las
actividades que les parecen mas apropiadas. Ademas, dado que hay alumnos de Ciencias y alumnos de Tecnologa,
las actividades pueden ser dirigidas a todo el grupo o bien
ser especficas para los alumnos de cada especialidad. Con
estas normas, las dos charlas propuestas fueron elegidas
para ser impartidas al curso completo de 20 alumnos. La
estructura de las actividades realizadas es siempre la misma. Los das anteriores a la actividad presencial prevista,
la plataforma MOODLE del IES Claudio Moyano cuelga las presentaciones power-point que se van a realizar.
Finalizada la actividad presencial, en la misma plataforma se cuelgan las hojas de ejercicios propuestos para que
los alumnos que lo deseen tengan trabajo adicional que
efectuar.
La primera de las charlas se titulaba Viaje a traves
de la Criptografa y en ella se resumieron los principales
metodos de cifrado a lo largo de la historia, que se ilustraron con numerosos ejemplos. Se hizo una especial mencion
a los metodos modernos (vease Fig. 6). En la charla tambien se abordaron las actuaciones necesarias para garantizar la autenticidad, confidencialidad e integridad de la
informacion transmitida por canales inseguros (vease Fig.
7).
La segunda de las charlas se titulaba Protocolos Criptograficos y en ella se expusieron algunos de los protocolos criptograficos que usan el criptosistema RSA como
base. Los alumnos conocieron algunas de las aplicaciones
del criptosistema RSA que haba sido introducido con detalle al inicio de la charla. Las preguntas del coloquio final
revelaron la creciente curiosidad de los estudiantes por todos los temas expuestos.
Los siguientes enunciados se corresponden con algunos
de los problemas proporcionados como materiales de trabajo adicionales:
1. Codifica mediante el cifrado de Playfair el mensaje:
These songs are wonderful,
utilizando como clave la palabra HAND.
2. Busca el texto claro del mensaje que aparece en la obra
de Allan Poe El escarabajo de oro.
3. Utilizando el alfabeto internacional de 26 letras y asignando su valor a cada una de ellas, de modo que
A 0,
B 1,
...,
193
JNIC2015

5
Fig. 6. Diapositiva de los comienzos de la Criptografa moderna.
Fig. 7. Caractersticas de los sistemas criptogr

aficos actuales.
Z 25,
se define un cifrado afn por la expresion
C(m) = 3m + 7(mod 26),
siendo m la letra a cifrar. Encriptar el mensaje
ESTE CRIPTOSISTEMA NO ES SEGURO
4. Programa el algoritmo de Euclides
Entrada: a b (con a>b>0)
Salida: mcd(a,b)
La respuesta de los alumnos ha sido entusiasta. Al finalizar cada una de las charlas hubo un animado coloquio
que continu
o a traves del correo electronico. Ademas, un
porcentaje significativo realizo casi correctamente todas
las cuestiones propuestas como trabajo adicional. Finalmente, en Mayo de 2015 presentamos dos proyectos para
ser realizados por los alumnos de forma individualizada
durante el primer cuatrimestre del curso 2015-2016. Ambos proyectos fueron elegidos por los alumnos: Estudio
grafico de los automatas de Wolfram e Implementacion
de algunos algoritmos matematicos que se usan en Criptografa. En la actualidad los alumnos han comenzado a
trabajar en ambos proyectos.
Bachillerato de Investigacion/Excelencia que se imparta

en el IES Vaguada de la Palma de la ciudad de Salamanca y esa colaboracion la ampliamos el curso siguiente
a Zamora, al IES Claudio Moyano. Con nuestra participacion en el BIE iniciamos a estudiantes de bachillerato
en actividades asociadas a la investigacion en Criptografa
y Seguridad de la Informacion, potenciando, tal como se
establece en la metodologa que define el BIE [2], la utilizacion de las tecnologas de la informacion y la comunicacion.
Las experiencias realizadas en ambos centros han sido
seguidas por parte de los alumnos con gran interes. Los
proyectos de investigacion han sido realizados con exito
en el IES Vaguada de la Palma y esperamos que suceda
lo mismo en el IES Claudio Moyano.
Hay que destacar que estas actividades no solo han permitido dar a conocer a los alumnos involucrados los fundamentos tanto de la Criptografa como de algunos aspectos
basicos de la Seguridad de la Informacion, sino que tambien les ha permitido conocer de primera mano algunas
aplicaciones de tecnicas matematicas conocidas por ellos.
Es interesante seguir con la lnea de colaboracion abierta con los centros que desarrollan este nuevo Bachillerato puesto que nos permite acercar estas ideas al ambito no universitario. Sera conveniente profundizar mas en
la lnea iniciada, quiza desarrollando actividades complementarias en otros centros no universitarios, siempre que
la normativa vigente lo permita.
Puesto que los profesores que participamos en estas actividades desarrollamos nuestra labor de investigacion en
diversos temas de Criptografa, Seguridad de la Informacion y aplicaciones de Matematicas, resulta muy gratificante poder compartirlos con estudiantes no universitarios, que forman parte de este Bachillerato de Investigacion/Excelencia de forma voluntaria.
Agradecimientos
Este trabajo ha sido subvencionado por el Ministerio
de Economa y Competitividad (Espa
na) y por los fondos
europeos FEDER con el proyecto TIN2014-55325-C2-2-R.
Referencias
[1] P. Caballero Gil. Introducci
on a la Criptografa. Ra-ma, 2002.
[2] C. de Educaci
on. ORDEN EDU/551/2012, de 9 de julio, por la
que se regula la implantaci
on y el desarrollo del Bachillerato de
Investigaci
on/Excelencia en la Comunidad de Castilla y Le
on.
Boletn oficial de Castilla y Le
on, (127), 2012.
[3] A. F
uster Sabater, L. Hern
andez Encinas, F. Montoya Vitini, J.
Mu
noz Masqu
e, A. Martn Mu
noz, Criptografa, protecci
on de
datos y aplicaciones, RA-MA, Madrid, 2012
[4] C.F. Gauss, Disquisitiones arithmeticae por Carl Friedrich Gauss
(traducci
on al espa
nol hecha por Hugo Barrantes Campos, Mi
chael Josephy, Angel
Z
un
iga). Academia Colombiana de Ciencias
Exactas, Fsicas y Naturales, 1995.
[5] M. Lucena L
opez, Criptografa y Seguridad en Computadoras.
Versi
on 0.6. 2) Universidad de Ja
en, 2005.
[6] M. Ma
neru, El Enigma de los C
odigos Secretos. Libsa, 2008.
[7] A.J. Menezes, P.C. Van Oorschot, and S.A. Vanstone, Handbook
of applied cryptography. CRC press, 1996.
V. Conclusiones y trabajo futuro

Durante el curso academico 20132014 varios profesores
del Departamento de Matematica Aplicada de la Universidad de Salamanca comenzamos la colaboracion con el
194
JNIC2015
Graduate Studies in Cyber-security

A proposal
Juan F. Garca, Javier Alonso, Miguel V. Carriegos
Research Institute of Applied Sciences in Cybersecurity
University of Len
Len, Spain
{jfgars, javier.alonso, miguel.carriegos}@unileon.es
AbstractThis paper summarizes an official Master program

studies in Cybersecurity. Some milestones as online formats are
pointed out as well as a concrete list of capabilities or skills is
provided and developed in a two-year syllabus.
KeywordsMaster studies, Cyber-Security, dual on line courses
I. INTRODUCTION
As the demand for skill on cyber-security professionals is
growing, computer, network professionals and in general active
professionals now can turn to online, in-demand Masters. This
Master's studies can (and should) be focused in training
interested engineers, scientists and even lawyers and another
professionals to acquire a solid foundation in key technologies
computer and network security, digital forensics,
cryptography, and biometrics as well as capability to perform
initial research studies in the field. The formula Operations +
Research should be mandatory.
With industry continuing to place top priority on
safeguarding its data and information systems,, it becomes
necessary well-prepared professionals for careers in developing
security products, as security-application programmers,
security analysts, penetration testers, vulnerability analysts and
security architects as well as researchers.
This paper describes a proposal which will be implemented
at the University of Len (Spain) in 2016 jointly with INCIBE
[1]. The proposal focus on an integrated two year post-graduate
studies. The objective is to prepare professionals in cybersecurity in the broader sense from concrete software
engineering to networks and social responsibility or legal
issues. This long term official Master studies will include both
a research mention capabilities and a specific Practicum.
Graduate Master Students will be ready both to start as
professionals and to begin a Ph. D. degree in Cyber-security
This Master program is an official master (approved by
ANECA), and has its precedent studies as a Professional
Master Degree in Computer Security (2007-2009) and then a
Professional Master Degree in Cyber-Security (2009-2015).
These programs included neither a specific Practicum nor a
Research Mention: this has been shown as a gap that the two
year program is designed to fulfill.
Another relevant difference with previous studies is its
online modality: The studies are programmed to be performed
both as an on-line course and traditional, allowing the students
to choose the modality that suits them better. We will follow

previous experiences in our School of Engineering of Masters
degrees in Industrial Engineering within this dual format, and
will use online technologies like Moodle or AVIP (Audio y Voz
por IP, a tool developed by Spanish UNED, Universidad de
Educacin a Distancia).
The impact of globalization and internationalization is an
important integrating theme consequently we pay attention to
the concrete experiences and studies in the field [2]. For this
same reason, the Master is taught fully in English (this is the
last difference with the Master program predecessor), which
should make it more accessible and interesting for student
around the world.
Choosing English as the Master language also allows for
participation of internationally recognized cybersecurity
researchers from other Universities like Washington, Arizona
or Duke, to name a few, which will collaborate in the teaching
of some topics and subjects.
Technological change is fundamental to the development of
education systems therefore we focus on a careful selection of
curriculum, pedagogy and didactic aspects covering relevant
aspects from more classical engineering courses to more
contemporary courses. The goal is to obtain professionals and
future researchers that are transversal and somewhat plastic in
their capabilities or skills.
II. TEACHING
Online modality is implemented in two ways: all regular
in-class teaching is recorder and Live streamed using AVIP
technology previously mentioned. This tool allows student to
attend the class from remote locations while letting them
participate (the tool allows real time iteration with the teacher
and the rest of students, no matter they are also online students
or regular student physically in the classroom). On top of that,
the recorded class session is uploaded to the Moodle, making
it available for delayed viewing for both regular and online
students.
AVIP tool is described as a virtual presentiality tool for
their own creators and is an attempt to reduce some of the
disadvantages of online studies: student solitude and lack of
iteration with others. Making the contents available to be
viewed later greatly increases flexibility.
195
JNIC2015
On top of that, teachers correspond with students through

e-mail, chat rooms or whatever prompt reply media, therefore.
Teachers are able to address different learning styles by
incorporating technology, written work and other group
assignments into coursework. They don't need any in-person
contact with their students because all discussions and
assignments are distributed online. Moreover for the standard
attendees this becomes a bonus because a standard student
could often choose to attend the course online.
Online courses are becoming a popular substitute to
traditional courses, since it's a more convenient way for busy
professionals to advance their education. It should be
remarked here that previous editions of Master in Cybersecurity have been performed both in regular format (from
Monday to Thursday) and in the so-called executive format
(Friday and Saturday). Both formats have their own audience
and these two kind of students (regular students in the former
format and professionals in the latter) have shown different
calendar requirements. The dual format proposed here (both
online and at classroom) is intended to fulfill these nonmatching requirements.
In addition to the basic requirements for teaching at the
postsecondary level, teachers and instructors need a
comprehensive knowledge of Internet resources and how to
use them. Teachers must incorporate engaging, active learning
into their lesson plans and course material. There are
educational programs offered by the University of Len which
include certificates in technology-based learning for
specialization in online teaching. Some skills that these
courses or programs emphasize for teachers can include
student group work, online assessment, copyrighted material,
Internet resources and course mapping.
Teachers should also be open to feedback from their
students. The Office of Evaluation and Quality form
University of Len manages polls for students to find out
which activities, assignments or projects were most effective
for learning.
III. STUDENTS
Previous editions of Master had enrolled about 25 students
each. Their grade formation was mainly related with
Computer Engineering degrees, often graduates in
Mathematics and rarely Electrical/Electronic Engineers,
graduates in Physics and lawyers or graduates in Economics.
To allow for a more heterogeneous audience, we have
granted access to the Mater to any graduated student, no
matter their field of knowledge. However, some formation
complements to be coursed by students without formation in
Computer or Telecommunications Engineering are proposed:
Networks, Operating Systems and Software Engineering. All
these formation complements must be acquired before
enrolling in the Master.
IV. GRADUATED SKILLS (COMPETENCIAS)

In order to perform a complete report of the skills of a
Master graduate student, concrete Competencias or capabilities
or skills are listed in the documentation of the Master title.
Competencias are collected in:
1. Basic skills: To elaborate and to report solutions to
concrete problems in computer security and communications;
to collect relevant data and report relevant information from
data; to deploy coherent ethic, social or scientific statements or
reports from the perspective of cyber-security; to develop
cybersecurity solutions to the industrial environment; to learn
in an autonomous way; to develop projects in computer
security and communications.
2. Specific skills related to cyber-security: Management of
operating systems; networks and services; to program and to
analyze; design secure software; understand and apply
cryptographic protocols; understand basic applied mathematics
to cybersecurity; applied biometry; detect, analyze and prevent
threads; deployment of a secure network system; basics of
security management; analyze and develop a secure web
system; Spanish laws related to cybersecurity; fundamentals of
a CERT; security guidelines in financial and business centers;
basics of complex robust systems; development of secure
applications in several operating systems; to prevent cyber
fraud; fundamentals of physical security; main forensic
techniques; detection and classification of malware; Spanish
cybersecurity plan/agenda; basics of cybercrime and cyber
defense; basics of social engineering and psychology;
cybersecurity in mobile technology; basics of scientific
research; industrial/intellectual rights and property; innovation
as the implementation of concrete industrial solutions from
research and development results; design of secure networks
and operating systems; secure system administration; software
and malware analysis; exploiting techniques; social
responsibility of cyber-security professionals, corporations and
public agencies.
This is a summary of the most relevant capabilities
belonging to compulsory subjects, meaning all student will
acquire them. Elective content have its capabilities also, but
they are not included here for simplicity reasons.
The final and official master verification report containing
all relevant information regarding this and other topics, with a
detailed and complete capabilities list, will be publically
available at http://seguimiento.calidad.unileon.es after ANECA
final resolution.
V. THE SYLLABUS
In order to grant above skills for graduate students, the
following list of matters has been gathered. It is worth to note
here that the deign focus on the homogeneous work
requirements at any matter (6 European Transfer Credit System
ECTS) and that theoretical work is programmed to be
performed mainly in the first year saving the second for
practicum, research topics and Master Thesis. The Formation
complements, only for students without formation in Computer
or Telecommunications Engineering and to be acquired before
196
JNIC2015
enrolling in the Master, are also included here for completeness

reasons.
(with purely online content) is proposed for the student to

choose from.
Semester and Subject
Master Thesis aims at putting into practice the knowledge

and skills acquired in the master's program by students through
the development of a research project within a research center
or a company with a high level of R+D+i. The Master thesis
development may take place in any of the collaborating entities
and is evaluated by a university court (which also requires
physical presence of the student).
ECTS
Formation Complements
[for no IT/Telecom graduates]
Programming
Operating Systems
Communication Networks
Evaluation of students is performed online through Moodle

and with a final physical exam. These applies to students of
both modalities, as imposed by internal University of Len
regulation.
First Semester
Cybersecurity and Cybercrime Foundations
Mathematics for Cybersecurity I - Cryptography
Human Aspects
Cybersecurity
and
Legal
Implications
of
The student is required to complete at least 120ECTS in

order to get his/her diploma.
6
ACKNOWLEDGMENT
Secure Design and Programming
Security of Cyber-physical Systems I
This work was partially supported by INCIBE according to

rule 19 of the Digital Confidence Plan (Digital Agency of
Spain) and the University of Len under contract X43.
Mobile and Distributed Ecosystems
REFERENCES
Trustworthy Systems I
Systems Auditing and Forensics I
Software Analysis I
Intrusion, Detection, Management and Prevention of

cyber-attacks
Second Semester
[1]
[2]
[3]
[4]
Third Semester
Research Science
24 ECTS to be chosen from [Elective]:

-
Practicum (practical experience)
18
Elective I
Elective II
Elective III
Elective IV
6
Fourth Semester
Master Thesis
30
Elective matters will be proposed yearly and it is planned to

be specific matters of recent advances in the field, current
trends and emerging threads in cyber-security, management of
information systems, second course on trustworthy systems,
software analysis, forensics and authentication technologies.
Since Practicum (practical experience), is performed in a
center or a company, it may require physical presence of the
student. Given this may be a problem for online modality
students, a big enough amount of alternative elective subjects
197
INCIBE, Instituto Nacional de Ciberseguidad, https://www.incibe.es

A. Rovai, The Internet and Higher Education Elsevier, 2009.
M.E. Cano Garca, La evaluacin por competencias en la educacin
superior, Profesorado, Revista de curriculum y formacin del
profesorado, 12(3), 2008.
E. Martn, A. Moreno, Competencia para aprender a aprender, Alianza
ed.
2007.
JNIC2015
Una apuesta por la educacin en ciberseguridad

desde el mbito universitario
Andrs Caro
Dpto. Ingeniera de Sistemas Informticos y Telemticos - Universidad de Extremadura
andresc@unex.es
Resumen- En este trabajo se exponen diferentes experiencias
realizadas en los ltimos aos desde el mbito universitario (desde la
Universidad de Extremadura) para fomentar la educacin en temas de
Ciberseguridad, en el entorno universitario y fuera de l. El creciente
inters en este tipo de educacin por parte de la sociedad en general,
unido al progresivo aumento de delitos informticos, fraudes y la
situacin de alarma que todo ello conlleva, estimula la participacin,
de un modo u otro, en alguna de las actividades que se han llevado a
cabo durante el ltimo ao y que desde este trabajo se comparten.
I.
INTRODUCCIN
Los equipos informticos, las redes e Internet forman parte

de las vidas de cada vez ms ciudadanos en el mundo. Como
consecuencia de ello, el uso del trmino ciberseguridad
tambin est en auge en los ltimos aos. Por desgracia,
tambin es habitual encontrar en prensa noticias relacionadas
con delitos informticos que tienen su causa, aunque sea en
parte, en la falta de concienciacin de los usuarios. As, ya en
2010 aparecen algunas noticias en las que se pona de
manifiesto la falta de seguridad en el desarrollo de aplicaciones
informticas [1]. Incluso en 2012 se modific el Cdigo Penal
para castigar la difusin en la red de vdeos ntimos sin permiso
[2]. Tambin aparecen en prensa otros pases de nuestro
entorno, como por ejemplo Francia, con noticias relacionadas
con el castigo a personas por las descargas que otros realicen
desde su red [3]. En nuestro pas, no hace mucho que
aparecieron noticias sobre la detencin de personas por
piratear la WiFi del vecino [4]. Las suplantaciones y
usurpaciones de identidad en las redes sociales, por desgracia,
tambin estn a la orden del da desde hace unos aos
[5][6][7].
Las Fuerzas y Cuerpos de Seguridad del Estado se han
adaptado a este tipo de delitos tecnolgicos, e incluso disponen
de personal especializado para combatirlos. A modo de
ejemplo, en la pgina web del Cuerpo Nacional de Polica
(http://www.policia.es) puede consultarse la catalogacin de
delitos informticos que hace la Brigada de Investigacin
Tecnolgica.
Por todo ello, la educacin en ciberseguridad, la difusin de
contenidos y la concienciacin en este tipo de materias,
dirigida hacia todo tipo de usuarios, se presenta como un reto
ciertamente apasionante. Como se comentaba anteriormente,
cada vez son ms los ciudadanos que disponen de ordenadores,
porttiles, telfonos inteligentes y otros tipos de dispositivos
que manejan informacin sensible y datos personales que es
preciso gestionar de forma segura. En este trabajo se quieren
compartir las diferentes experiencias llevadas a cabo, siempre
desde el mbito universitario (particularmente desde la

Universidad de Extremadura, UEx) relacionadas, en todo o en
parte, con la educacin en ciberseguridad.
II. INFORMTICA FORENSE Y COLEGIOS PROFESIONALES
Uno de los mbitos de actuacin llevados a cabo en cuanto a
formacin de usuarios ha sido en conjuncin con el Colegio
Profesional de Ingenieros en Informtica de Extremadura
(CPIIEx). La informtica forense juega un papel importante y
supone una salida profesional relacionada con el campo de la
seguridad informtica. La figura del perito en informtica,
como aquel profesional cualificado que es capaz de determinar
las causas (y los efectos) que ha originado un evento o
incidente en un sistema se presenta tambin como una primera
aproximacin a temas relacionados con la ciberseguridad. En la
actualidad, muchos expertos en ciberseguridad ejercen,
adems, como peritos en informtica.
En este sentido, desde la UEx se colabor con las I
Jornadas de Peritaje Informtico, organizadas por CPIIEx y
que se desarrollaron en la propia Universidad en el ao 2007.
Indicar que CPIIEx se crea en el mismo ao 2007, y sus
primeras directivas (hasta el ao 2014) estaban formadas por
profesores universitarios principalmente. De ah que
Universidad y Colegio Profesional se integrasen en un mismo
foro formativo, siendo muy fluida la colaboracin entre ambas
instituciones, as como el intercambio de ideas y experiencias.
Esto favoreci especialmente a los estudiantes universitarios,
que tenan informacin y formacin de primera mano en estos
aspectos, tan novedosos en aquella poca.
As, tambin se colabor en las siguientes ediciones de estos
cursos de peritaje en los aos 2008, en las II Jornadas de
Peritaje Informtico - Conceptos y ejemplos prcticos de
peritajes informticos y 2009 III Jornadas de Peritaje
Informtico - La experiencia en el peritaje informtico. Varios
profesores universitarios participan en el Comit Organizador
de estas jornadas. Estos cursos estaban destinados a colegiados,
y tambin a profesionales y estudiantes de las titulaciones de
informtica en general. Es importante comentar que esta
experiencia de formacin supuso un importante impulso en la
figura del perito en informtica en la Comunidad Autnoma de
Extremadura, donde, hasta la fecha, no se haban creado listas
de peritos que repartir en los juzgados de Extremadura. Por
ende, sent las bases para que profesionales, estudiantes y
profesores universitarios tuvieran un foro de debate en el que
compartir experiencias e inquietudes relacionadas con la
198
JNIC2015
informtica forense principalmente, pero tambin con la

ciberseguridad y el hacking tico.
En los aos sucesivos, desde CPIIEx, y siempre apoyados
por la UEx, se organizaron tambin jornadas relacionadas con
la Seguridad Informtica. As, en 2011 se organizan las I
Jornadas de Ley Orgnica de Proteccin de Datos y Seguridad
Informtica, y en 2012 las II Jornadas de Seguridad
Informtica - Esquema Nacional de Seguridad y LOPD. Igual
que en las jornadas de aos anteriores, estas jornadas estn
enfocadas a colegiados, profesionales y estudiantes de
informtica en general, y sirvieron para consolidar aspectos
fundamentales relacionados con la ciberseguridad.
En 2013, se continua con las IV Jornadas de Peritaje
Informtico - El perito informtico forense donde se presenta
un enfoque eminentemente prctico en unas sesiones
presenciales, acompaado de las IV Jornadas de Peritaje
Informtico - Resolucin de casos prcticos, una segunda
edicin no presencial que, por primera vez, presenta retos a
resolver por parte de los participantes. Indicar que la directiva
de CPIIEx, en todo momento, trata a los estudiantes
universitarios de las titulaciones de informtica en condiciones
similares a las de sus colegiados / precolegiados. El xito de
participacin de los estudiantes es grande en ambos eventos.
Finalmente, en 2015 se organizan las V Jornadas de Peritaje
Anlisis Forense de dispositivos mviles (iOS y Android) y
se formaliza la I noche de la ingeniera en informtica de
Extremadura. La figura 2 muestra la web de CPIIEx donde se
comenta cmo se desarrollaron estas actividades. A estas
alturas, el conocimiento en cuanto a Informtica Forense, tanto
en el mbito universitario como fuera de l, est ms que
consolidado en Extremadura.
Figura 1. Total de colegiados en CPIIEx (en rojo) y participantes en

las actividades programadas.
La figura 1 muestra el nmero de participantes en cada una

de las actividades organizadas por CPIIEx y anteriormente
comentadas. En color rojo puede observarse la lnea de
crecimiento de colegiados a CPIIEx desde su creacin en 2007,

que se encuentra estabilizada en el rango 80-85 colegiados,
aproximadamente. En barras se muestran los participantes en
las distintas actividades programadas en estos aos,
distinguiendo los participantes por su titulacin. En azul se
muestran los titulados en Ingeniera Informtica (colegiados) y
en naranja el resto de titulados. Puede observarse un nmero
cercano a los 40 participantes en las ltimas actividades
ofertadas.
III. FORMACIN EN ASIGNATURAS DE GRADO Y MSTER
La reforma de los planes de estudio de Ingeniera e
Ingeniera Tcnica en Informtica hacia los actuales ttulos de
Grado y Mster supone la aparicin de nuevas asignaturas y
nuevos contenidos. Ello da pie a que sea posible incluir
cuestiones anteriormente no consideradas en los planes
antiguos, como la figura del auditor y perito en informtica,
legislacin informtica, con especial sensibilidad hacia la
LOPD, y aspectos como la calidad de los Sistemas
Informticos, donde la seguridad es una base incuestionable
para cualquier sistema que quiera presumir de calidad.
En la Universidad de Extremadura (UEx), desde el curso
2011/12 se imparte la asignatura Auditora, Certificacin y
Calidad de Sistemas Informticos", del Master de Ingeniera
Informtica. Se trata de una asignatura obligatoria de 6 crditos
ECTS donde se tratan cuestiones de seguridad informtica, as
como normas de certificacin en seguridad y en calidad. Se
insiste en la figura del auditor de sistemas y en el desarrollo de
software seguro, incluyendo pruebas de software que permitan
desarrollar aplicaciones no slo correctas desde el punto de
vista funcional, sino tambin seguras.
Y desde el curso 2012/13 se imparte la asignatura Auditora
y Legislacin Informticas, asignatura obligatoria de 6
crditos ECTS, de tercer curso en los Grados de Ingeniera
Informtica (Ingeniera del Software e Ingeniera de
Computadores). En esta asignatura se presenta la figura del
perito y auditor en informtica, cuestiones de legislacin
informtica, informtica forense, seguridad informtica y
hacking tico. Las prcticas de la asignatura se centran
principalmente en retos sobre informtica forense, auditora
informtica y seguridad informtica y hacking tico. Muy a
destacar el alto ndice de aprobados que alcanza la asignatura
(sobre un 80% en primera convocatoria). Con un temario muy
atractivo y muy cercano a la realidad, la asignatura es capaz de
conseguir una alta motivacin de los estudiantes, lo que se
refleja en las encuestas oficiales y en los comentarios que de
ella hacen los propios estudiantes. Esta asignatura aparece
indexada en el Mapa de Enseanza de Seguridad de la
Informacin (MESI) elaborado por la red temtica de
criptografa y seguridad de la informacin de la Universidad
Politcnica de Madrid [8].
De nuevo, indicar que el autor de este trabajo es profesor de
ambas asignaturas desde que empezaron a impartirse. Desde
luego, en la Universidad de Extremadura existen otras
199
JNIC2015
asignaturas donde se imparte temas relacionados tambin con

la ciberseguridad, aunque el autor de este trabajo no imparte
docencia en tales asignaturas y no puede compartir esas
experiencias.
IV. INICIATIVA UNIVERSITARIA DE ANLISIS FORENSE EN
INFORMTICA
Como consecuencia del entusiasmo manifestado por un gran
nmero alumnos de la asignatura Auditora y Legislacin
Informticas, y estimulado por el autor de este trabajo, en
marzo de 2014 se organiza el grupo universitario Iniciativa
Universitaria de Anlisis Forense en Informtica [9]. Este
colectivo involucra a profesores, personal de administracin y
servicios (PAS) y estudiantes de la UEx, interesados en
informtica forense, hacking tico y seguridad y auditora de
sistemas en general. Bajo el lema aprender y compartir se
cimenta la base de trabajo del grupo, que se organiza como una
iniciativa universitaria, y no como una asociacin. Ello
compromete un grupo de trabajo, gente con inquietud e inters
en los temas. Es la primera iniciativa en este sentido llevada a
cabo en la UEx. Destaca su carcter universitario (por y para
universitarios, pero tambin para titulados, e incluso empresas
interesadas en seguir esta filosofa). En particular, se centra en
la titulacin de Informtica: ingeniera e ingeniera tcnica en
informtica, grados y mster en informtica. Se pretende
considerar las salidas profesionales relacionadas con temas de
seguridad, informtica forense y hacking tico, dentro de la
profesin informtica. Como se ha comentado, el germen de la
iniciativa est en los estudiantes de la asignatura Auditora y
Legislacin Informticas, y aqu el objetivo no es la docencia
de esta asignatura, sino el antes y el despus de ella, con la idea
de instaurar y consolidar un grupo de trabajo, ao tras ao. Las
perspectivas profesionales en este sentido son amplias, siendo
tambin conscientes de la falta de medios en Polica y Guardia
Civil en las materias relacionadas con la ciberseguridad.
Como consecuencias del inters, es posible organizar
formacin por parte de la propia universidad, en cuanto a
contenidos del mster, cursos de postgrado, cursos de
especializacin y tambin en formacin por parte de CPIIEx,
donde en 2013 se cont con todos los universitarios de
titulaciones en informtica de la UEx, para sus cursos de
formacin, lo cual supuso un buen punto a favor.
Los principios de la iniciativa son bsicos: debe existir un
compromiso, de modo que si alguien se compromete a
desarrollar algn tema, debe cumplir con los objetivos;
aprender y compartir entre compaeros, como se ha
comentado, es el objetivo base; y el tiempo, que tanto
preocupa, no debe ocupar demasiado, ya que se es consciente
de que se tienen otras cosas que hacer.
La forma de trabajo es mediante un espacio virtual y correos
electrnicos. Se pretende huir de las reuniones presenciales que
tanto tiempo consumen y tan difciles son de encajar en las
agendas de cada uno. Los trabajos y retos se presentan,
sugieren, proponen y discuten entre iguales. Se sugieren temas
de investigacin, enlaces webs, materiales, libros. La idea es

fomentar la creacin de un hacklab (laboratorio de hacking) y
de un computer forensic lab (laboratorio de informtica
forense), algo que empieza a concretarse tambin mediante la
realizacin de diversos Trabajos Fin de Grado.
En poco ms de un ao, el perfil de Twitter de esta iniciativa
universitaria (@InForensics_UEx) ha alcanzado un nmero
considerable de seguidores (450 en la fecha de redaccin de
este trabajo).
V. HCKING TICO
Apenas dos meses despus de la creacin de la iniciativa
universitaria @InForensics_UEx, el grupo se plantea el reto de
organizar alguna sesin para la Semana del Centro (de la
Escuela Politcnica de la UEx), que se organiza cada ao a
mediados del mes de mayo. De este modo, en mayo de 2014,
esta iniciativa universitaria organiza una sesin de Hacking
tico y Seguridad Informtica para la Semana de la Escuela
Politcnica. Desde el punto de vista metodolgico, las sesiones
se organizan proponiendo entre los participantes la exposicin
de determinados temas, seleccionando de entre ellos los que se
entenda que podan tener ms inters para los alumnos
asistentes a las jornadas. As, se organizan tres sesiones,
relacionadas con el hacking de aplicaciones Web (SQL
injection), ataques en redes locales (Man in the Middle), y
pentesting. Una de las sesiones la dirige un profesor, otra un
estudiante, y la tercera un tcnico del PAS. Casualmente, de
este modo quedan reflejados los tres colectivos universitarios.
Como continuacin del trabajo realizado, en mayo de 2015
el colectivo organiza las II sesiones de Hacking tico y
Seguridad Informtica tambin para la Semana de la Escuela
Politcnica. En esta ocasin se imparten sesiones relacionadas
con python scripting, buffer overflow, hacking de redes wifi, y
hardening de sistemas. En esta ocasin, tres sesiones son
dirigidas por estudiantes y la cuarta por una empresa
especializada.
Indicar que la participacin de los organizadores en estas
sesiones se realiza de forma voluntaria y desinteresada.
VI. FORMACIN EN CURSOS DE ESPECIALIZACIN
Paralelamente a todo lo anterior, durante el curso 2013/14 se
producen una serie de reuniones entre el director de la Escuela
Politcnica, el director de la Facultad de Derecho, personal de
la Asociacin Nacional de Ciberseguridad y Pericia
Tecnolgica (ANCITE) y del Colegio de Ingenieros en
Informtica de Extremadura (CPIIEx). Esas reuniones estn
enfocadas a la creacin de una oficina de referencia en
seguridad informtica y pericia informtica. La consecuencia
de estas reuniones fructifica en la decisin de organizar un
curso universitario de especializacin, de forma virtual, y
ofrecido por una Universidad Pblica como es la UEx, para
fomentar en la sociedad en general el desarrollo del perfil de
perito informtico forense. El curso en s estara fundamentado
200
JNIC2015
en dos cuestiones principales: por una parte, Derecho

Tecnolgico, donde se incluyen todas aquellas cuestiones
novedosas en cuanto a derecho, legislacin y delitos
informticos que puedan ser de inters para los expertos en
seguridad informtica e informtica forense. Y, por otra parte,
en Informtica Forense, donde se imparten materias relativas a
pericia informtica, seguridad informtica, hacking tico y, por
supuesto, informtica forense. Finalmente, el curso se perfila
como un curso de especializacin, de 150 horas, realizado de
forma virtual, denominado Derecho Tecnolgico e
Informtica Forense (DTIF) [10], y se desarrolla con bastante
xito entre los meses de febrero y mayo de 2015. Como
profesores del mismo aparecen figuras tan destacadas como,
entre otros muchos, Eloy Velasco (juez de la Audiencia
Nacional), ngel Juanes (Vicepresidente del Tribunal
Supremo), Jorge Bermdez (Fiscal de Delitos Telemticos),
por parte de la rama de Derecho, y Pedro Snchez (Conexin
Inversa) y Lorenzo Martnez (Securzame), por parte de la
rama de Informtica.
La figura 2 muestra las titulaciones de los participantes que
realizaron este curso de especializacin. Puede observarse que
2/3 de los alumnos de esto curso procedan de titulaciones de
Informtica, mientras que 1/4 de los mismos perteneca al
mundo del Derecho. Un 9% proceda de titulaciones variadas,
cercanas relativamente a uno u otro de las titulaciones bsicas
del curso (Derecho e Informtica).
parte de Derecho Tecnolgico (50% Satisfactorio-Bastante +

12% Muy Satisfactorio-Mucho).
La satisfaccin de los participantes es tan grande que anima
a los organizadores a gestionar una nueva edicin del mismo
para 2016. Esta vez diseando un curso de mayor categora y
envergadura, como es un Curso de Experto Universitario, con
una duracin de 200 horas y un plantel de profesorado que
incluye y mejora al de la primera edicin.
INFORMTICA
DERECHO
Figura 3. Grado de satisfaccin de los participantes que finalizaron

el curso, agrupados en la temtica de Informtica Forense y en la de
Derecho Tecnolgico.
El principal valor de estas propuestas formativas, y que las

diferencian notablemente del resto de ofertas, radica en que el
curso conjuga temas de Derecho Tecnolgico y de Informtica
Forense con total naturalidad, ofreciendo una perspectiva clara
y factible para los profesionales de una y otra titulacin,
condenados a entenderse en cada vez ms situaciones de la
vida real. En [10] pueden consultarse ms detalles acerca de
contenidos, metodologas, evaluacin, profesorado
VII. CTEDRA SOBRE SEGURIDAD Y AUDITORA DE SISTEMAS
Figura 2. Titulaciones de procedencia de los participantes en el

curso Derecho Tecnolgico e Informtica Forense.
El curso es finalizado de forma satisfactoria por participantes

de toda Espaa as como de Iberoamrica, como puede
apreciarse en la figura 3. En ella se resume parte de la encuesta
de satisfaccin que, voluntaria y annimamente, rellenaron
aquellos participantes que consiguieron culminar con xito el
curso. Cuantitativamente, puede observarse cmo un 61% de
los estudiantes muestran un grado alto de satisfaccin con la
parte de Informtica Forense (43% Satisfactorio-Bastante +
18% Muy Satisfactorio-Mucho). Del mismo modo, un 62% de
ellos muestran tambin un alto grado de satisfaccin con la
Como consecuencia de la colaboracin entre la Universidad

de Extremadura y diversas empresas del sector de la
Informtica en el mster de Ingeniera Informtica, el 27 de
abril de 2015 se firma el convenio por el que se crea la Ctedra
de patrocinio INSA-UEx sobre Seguridad y Auditora de
Sistemas Software [11].
La firma de esta Ctedra de patrocinio implica que se pone
de manifiesto, una vez ms, la importancia que los temas en
ciberseguridad estn alcanzando en los ltimos aos, no solo a
particulares, sino tambin a grandes empresas del sector como
puede ser INSA, filial de IBM Espaa.
El objetivo de la ctedra es poder avanzar en la mejora de
todos los aspectos relacionados con la Seguridad del Software.
A travs de ella se realizarn actividades de investigacin,
desarrollo y transferencia de tecnologa, particularmente sobre
201
JNIC2015
investigacin de modelos de desarrollo de Software Seguro,

seleccionando las prcticas ms adecuadas para mejorar los
modelos
actuales.
Tambin
se
trabajar
en
el
perfeccionamiento de los modelos actuales de Pruebas de
Seguridad, para aumentar sus prestaciones y eficiencia.
A travs de la Ctedra, se pondrn a disposicin de la
sociedad en general las novedades en la dimensin de
Seguridad del Software, actuando como un Observatorio de la
Seguridad y organizando actividades de formacin y
divulgacin en el mbito de la ciberseguridad.
Desde luego, la apuesta de una gran empresa por el
patrocinio de una Ctedra relacionada con la ciberseguridad da
pruebas de la necesidad de inversin en investigacin
relacionada con estos temas, y tambin de la confianza en el
sector universitario como fuente de desarrollo de estos trabajos.
Finalmente, indicar que est previsto que los trabajos de esta
Ctedra se financien durante, al menos, tres aos, y culminen
con la lectura de una tesis doctoral en temas de ciberseguridad
por parte de un estudiante de doctorado de la UEx.
VIII.
exportable a otras universidades y comunidades de un

tamao similar al que aqu se presenta.
Figura 4. Actuaciones universitarias en ciberseguridad en

Extremadura.
RESULTADOS Y CONCLUSIONES
Los resultados de todas las experiencias que se han querido

compartir mediante este trabajo se resumen a continuacin.
Bsicamente, el Colegio Profesional de Ingenieros en
Informtica de Extremadura (CPIIEx), en conjuncin con la
Universidad de Extremadura, ha venido ofreciendo formacin
en temas relacionados con peritaje, informtica forense,
seguridad y legislacin en los aos 2007, 2008, 2009, 2011,
2012, 2013 y 2015.
En cuanto a formacin universitaria, las asignaturas de grado
(ALI Auditora y Legislacin Informticas) y mster (ACCSI
Auditora, Certificacin y Calidad de Sistemas Informticos)
comentadas anteriormente se han venido desarrollando desde
los cursos 2012/13 y 2011/12 hasta la actualidad,
respectivamente.
El grupo de Iniciativa Universitaria de Anlisis Forense en
Informtica ha venido desarrollando actividades de hacking
tico y seguridad en los aos 2014 y 2015.
Por ltimo, se ha desarrollado formacin con el formato de
curso de especializacin en una primera edicin en 2015, que
tendr continuidad en aos venideros, y se ha firmado una
Ctedra de patrocinio sobre Seguridad y Auditora de Sistemas
tambin en 2015, con previsin para tres aos.
Los resultados, mostrados por anualidades, se reflejan en la
figura 4. Segn esta figura, puede observarse cmo las
actuaciones universitarias en materia de ciberseguridad en la
Comunidad Autnoma de Extremadura se acumulan,
principalmente, en los ltimos 3-4 aos, siendo muy destacable
cmo en 2015 se ha doblado el nmero de actuaciones
realizadas conforme al ao anterior.
Como conclusin, queda mucho trabajo por hacer, pero es
evidente que en los ltimos aos se ha ido consolidando una
base sobre la que poder crecer, para poder seguir aprendiendo y
compartiendo con toda la sociedad. El modelo puede ser
AGRADECIMIENTOS
Un agradecimiento especial a todas las personas que han
colaborado, desinteresadamente, en la realizacin de las
actividades desarrolladas en estos ltimos aos, especialmente
a los estudiantes que han conseguido encontrar tiempo libre
entre sus muchas ocupaciones para sacar adelante algunas de
las acciones realizadas.
REFERENCIAS
[1]
Crdoba, 22-06-2010
http://elpais.com/elpais/2010/06/22/actualidad/1277194631_850215.html
[2] Madrid, 11-10-2012
http://politica.elpais.com/politica/2012/10/11/actualidad/1349953208_19
9770.html
[3] Francia, 20-08-2010
http://elpais.com/diario/2010/08/20/sociedad/1282255201_850215.html
[4] Madrid, 26-11-2013
http://www.elmundo.es/madrid/2013/11/25/5293b89463fd3d7c458b457b
.html
[5] Granada, 14-04-2009
http://www.delitosinformaticos.com/04/2009/delitos/usurpacion-de-laidentidad-en-internet-para-insultar-y-ofrecer-favores-sexuales
[6] Segovia, 2-06-2011
http://www.delitosinformaticos.com/06/2011/noticias/condenadas-dosadolescentes-por-suplantar-a-una-companera-y-crear-un-peril-faso-en-lared-social-tuenti
[7] Cceres, 29-10-2012
http://www.hoy.es/20121029/local/caceres/detenida-joven-suplantaridentidad-201210291332.html
[8] Mapa de Enseanza de Seguridad de la Informacin (proyecto MESI)
http://www.criptored.upm.es/mesi/mesi2/mesi2ES.html
[9] Iniciativa Universitaria de Anlisis Forense en Informtica
https://inforensicsuex.wordpress.com/
[10] Derecho Tecnolgico e Informtica Forense
http://dtif.unex.es/
[11] Ctedra INSA-UEx sobre Seguridad y Auditora de Sistemas Software
http://escuelapolitecnicacc.blogspot.com.es/p/catedra-insa.html
202
JNIC2015
Una propuesta para la enseanza de la Ciberseguridad

en el Grado de Ingeniera Informtica
Jos Antonio Gmez Hernndez
Departamento de Lenguajes y Sistemas Informticos - Universidad de Granada
jagomez@ugr.es
Resumen- La Ciberseguridad es un bien a proteger dado su

impacto poltico, socio-econmico y personal. Como la misma
descansa en la construccin y uso seguro de sistemas informticos,
nuestros graduados deberan adquirir unos conocimientos bsicos
para abordar su trabajo profesional con la responsabilidad
necesaria y bajo los estndares reconocidos. Esta
I.
INTRODUCCIN
La Ciberseguridad es un bien a proteger dado su impacto a

nivel poltico, social, econmico tanto a nivel de estados u
organizaciones como individual. Gran parte de nuestro mundo
descansa en el uso de multitud de sistemas informticos sobre
los que realizamos una amplia variedad de actividades
cotidianas,
especialmente
en
pases
desarrollados
tecnolgicamente.
Vamos a comentar algunas cifras para establecer una
estimacin de la magnitud del problema al que nos
enfrentamos al usar esos sistemas. En [15] para 2014 se estima
el coste del cibercrimen en 400.000 millones de dolares, lo que
supone entre un 15% y un 20% del dinero que se mueve en
Internet. Las principales causas de estas brutales perdidas
provienen segn las empresas encuestadas en [14] de: el 68,32
% debido a phishing, un 66,48% a malware, el 50.14% por
intentos de hacking, un 43,54% por ingeniera social, un
43,89% por perdida de dispositivos mviles, 25,28% de los
trabajadores (insiders), 21,88% de Inyeccin SQL, etc.
Pero no solo hay que tener en consideracin los aspectos
econmico, sino tambin los problemas sociales y personales a
que dan lugar. Por ejemplo, va en aumento delitos como el
ciberacoso o el sexting, que afectan especialmente a nuestros
jvenes. En parte, la forma de evitar dicho tipo de cibercrmenes pasa por una educacin en seguridad de los usuarios,
y la construccin de sistemas-herramientas destinados a
detectarlos y si es posible evitarlos, como el bloqueo de tuits
violentos [7]. Sin dejar de mencionar aspectos estratgicos
relacionados con ataques a infraestructuras crticas, o que
afectan a la privacidad como las brechas de datos (ltimamente
crecientes en nmero y volumen, por ejemplo, en Estados
Unidos crecieron un 27,5 % en 2014 respecto a 2013) [13].
En Espaa, este fenmeno tambin es creciente tal como
podemos ver el primer informe sobre Cibercriminalidad
presentado por el Ministerio del Interior [16]. Adems, hay que
resaltar que el nmero de ataques sufridos por Espaa en 2014
fue de 70.000 lo que nos posiciona en tercer lugar tras EEUU y
ponencia plantea la enseanza de la seguridad como una

competencia transversal de forma que todos los alumnos la cursen
y se integre fcilmente en los planes de estudios. Uno de los puntos
ms conflictivo sera establecer un equilibrio entre los contenidos
propios de una materia y su uso de forma segura.
Reino Unido [10]. Debemos resaltar que un 95% de estos

delitos [9] quedan impunes por diferentes causas: no son
denunciados, o encuentran problemas tecnolgicos y/o legales.
Como podemos ver, el incremento y volumen del
cibercrimen son lo suficientemente graves como para no
abordar el problema con rapidez y contundencia. En especial,
si deseamos consolidar el uso de las Nuevas Tecnologa por la
mayora de la poblacin. Como se indica en [5], solo un 53%
de los usuarios de Internet declaran que compran bienes o
servicios online, un 48% realiza operaciones bancarias en
lnea, y el 20% vende bienes o servicios. Este aspecto tambin
esta reconocido por su importancia en la Estrategia de
Ciberseguridad Nacional [18].
La estructura de la ponencia aborda en el Apartado II cmo
ha quedado la enseanza de la Seguridad en los Grados de
Ingeniera Informtica en Espaa y, especialmente, en la
Universidad de Granada. En el Apartado III, se presenta y
justifica una propuesta de mejora para solucionar algunos
problemas. Adems, se vern algunos ejemplos concretos de
asignaturas afectadas por la propuesta. Para terminar con un
resumen de la propuesta realiza en la ponencia.
II. CONSIDERACIONES GENERALES
El BOE 187/2009 [2] establece las recomendaciones para la
solicitud de ttulos de Ingeniera Informtica, y ms
concretamente, el Apartado 3 del Anexo I enumera las
competencias que todos los estudiantes deben adquirir. Una de
ellas establece necesaria la Capacidad para disear,
desarrollar, evaluar y asegurar la accesibilidad, ergonoma,
usabilidad y seguridad de los sistemas, servicios y aplicaciones
informticas, as como de la informacin que gestionan.
Volviendo a aparecer el trmino seguridad tanto en las
competencias en mdulo de rama como en los de
especializacin. En una lnea similar, la versin de 2013 del
Curriculum de Informtica de la ACM/IEEE incluye el rea de
conocimiento Garanta de la Informacin y Seguridad [1] .
Para la adquisicin de competencias relacionadas con la
Ciberseguridad, en muchos planes de estudios se ha optado por
incluir cierto nmero de asignaturas dedicadas al tema, tal
203
JNIC2015
como se puede ver en el magnifico trabajo de Rami [20] a

travs del proyecto MESI.
Si bien la situacin de la enseanza de la Seguridad ha
mejorado respecto de los planes de estudios anteriores, es
actualmente a todas luces insuficiente, mxime cuando en
algunos casos estas asignaturas son bien optativas, bien
troncales pero solo se cursan en alguna mencin concreta y, por
tanto, no son cursadas por todos los alumnos del ttulo.
Algunas propuestas [19] abalan la creacin de una titulacin
propia en seguridad para la formacin de profesionales en esta
materia. Si bien esta propuesta es muy interesante solo cubrira
una parte del problema. La seguridad informtica no es solo
cuestin de profesionales de la seguridad, es algo que nos
afecta a todos los que usamos y/o construimos software. Por
tanto, hay que buscar una solucin que permita que nuestros
alumnos conocer los principales problemas relacionados con la
seguridad y cuales son sus soluciones.
En el caso concreto del Grado en Ingeniera Informtica de
la Universidad de Granada, las asignaturas especficas sobre
Seguridad que se establecieron fueron Seguridad y Proteccin
de Sistemas Informticos, Seguridad en Sistemas
Operativos, y Criptografa y Computacin.
Seguridad y Proteccin de Sistemas Informticos es
obligatoria en la mencin de Tecnologas de la Informacin.
Esta dedicada en gran parte a la criptografa, si bien cubre
algunos aspectos de seguridad en redes y comunicaciones,
identidad digital, privacidad en Internet y comercio electrnico.
Seguridad en Sistemas Operativos optativa de la mencin de
Ingeniera del Software. Asignatura diseada para completar la
parte de seguridad vista en la asignatura de Sistemas
Operativos de segundo curso, pero que tambin cubre otros
aspectos de la seguridad que los estudiante de la mencin de
Ingeniera del Software no ha visto, como son: desarrollo de
software seguro, malware e ingeniera inversa, e informtica
forense.
Criptografa y Computacin es una optativa de la mencin
de Computacin y Sistemas Inteligentes. Como su propio
nombre indica aborda adems de aspectos de cifrado de la
informacin, incluye los contenidos de seguridad de la
asignatura de Sistemas Operativos que suelen incluirse en
cursos bsicos sobre la materia, como son bsicamente
autorizacin y control de acceso.
A la luz de lo indicado, es notorio que no hay una asignatura
especfica de seguridad bsica que cursen todos los estudiantes
del Grado y que exponga la complejidad y amplitud del tema.
A continuacin se esbozar una propuesta que cubrira de
manera razonable estas deficiencias en seguridad y que tiene
una implementacin cmoda y flexible dentro de los diferentes
marcos curriculares establecidos. La propuesta es abierta en el
sentido que trata de ser vlida para muchos planes de estudios
no solo el de la Universidad de Granada y depender del
profesorado involucrado la inclusin de determinados
contenidos en las asignaturas a su cargo. Dado que no se ha
materializado no podemos ofrecer evidencias de sus resultados.
III. PROPUESTA DE MEJORA

La propuesta presentada se destina, como comentbamos en
los prrafos anteriores, a que todos nuestros estudiantes
alcancen unas conocimientos bsicos de seguridad necesarios
para construir/usar sistemas software seguros tal como
demanda la sociedad.
Esta propuesta trata de alcanzar este objetivo sin necesidad
de hacer una reforma del plan de estudios que requiera incluir
nuevas asignaturas. Reforma que sera costosa, compleja y
tardara en poder aplicarse dado la tramitacin burocrtica de
los ttulos. Adems esta propuesta no es incompatible, al
contrario complementaria, de la situacin actual donde hay
asignaturas especficas de seguridad tanto en la troncalidad
como en las diferentes menciones, ni con la implantacin de un
ttulo propio en seguridad.
Se trata de plantear una serie de competencias bsicas de
seguridad como competencias transversales de forma que se
enseen en asignaturas ya existentes (en lugar de pretender
crear nuevas asignaturas). Es decir, dedicar parte los
contenidos de asignaturas ya existentes a abordar aspectos
bsicos de seguridad. Esto el algo que en algunos caso ya se
hace parcialmente pero que habra que potenciar y coordinar.
Es evidente que esto presenta un problema: cmo incluir
competencias nuevas en asignaturas que ya de por s esta
sobrecargadas. Las respuesta no es ni sencilla, ni nica. Es
evidente que supone un gran esfuerzo de coordinacin a nivel
de ttulo en que debemos valorar que equilibrio en la
formacin de nuestro estudiantes damos a dos aspectos
contrapuestos en muchos casos: inclusin de conceptos y/o
tecnologas avanzados frente a conceptos/tecnologas que
hagan ms seguros los sistemas que pretendemos construir.
Como es evidente y pretenda dejar manifiesto en la
introduccin, la postura defendida en ste artculo es
considerar necesario (obligatorio) sacrificar la inclusin de
algunos temas, bien avanzados bien secundarios, para facilitar
la inclusin de elementos de Ciberseguridad. Afortunadamente,
esto solo ocurrira en el peor de los casos. En otros casos se
pueden incluir modificando contenidos prcticos.
A menudo, vemos como nuestros desarrollos en una veloz
carrera por ofrecer nuevas soluciones tecnolgicas de cara a
abarcar cuotas de mercado dejan atrs aspectos de seguridad.
Esto tiene en muchos casos consecuencias nefastas para los
usuarios. El grado de penetracin de competencias de
seguridad en las asignaturas dependera, en este enfoque, del
grado de sensibilizacin del profesorado hacia el tema, que sin
dejar atrs las competencias legales establecidas para las
asignaturas podra aadir aspectos de seguridad bsicos
reduciendo algunos contenidos de las asignaturas que se han
aadido en el proceso de confeccin de las mismas y que no
vienen obligados por las fichas.
Evidentemente, no se trata de que todos los alumnos sean
profesionales de la Seguridad Informtica, pero si que
conozcan, se sensibilicen y sean capaces de abordar los
problemas que se producen al no tenerla en cuenta y cmo
pueden resolverlos ellos mismos o cundo es necesario recurrir
204
JNIC2015
a tcnicos especializados. Esto les permitir eliminar de

entrada determinados defectos de sus construcciones software
y facilitar la comunicacin en equipos multidisciplinares con
profesionales de la seguridad.
La propuesta se puede resumir como debemos ligar la
enseanza de la tecnologa con su uso de forma segura. Este
lema puede ser extensible a todos los niveles docentes donde se
ensee tecnologa. Por ejemplo, deberamos ensear a nuestros
adolescentes de la Enseanza Secundaria Obligatoria o
Bachillerato, no solo a utilizar un navegador, sino a utilizar de
forma segura un navegador, por citar un ejemplo. Lo mismo
sera aplicable al uso seguro de redes sociales, dispositivos
mviles, etc.
Por poner un smil, cuando decimos voy a sacarme el carnet
de conducir, no solo estamos asumiendo que vamos a
aprender a manejar un vehculo, sino que un gran porcentajes
de los conocimientos que abordaremos son de seguridad vial.
Debemos cambiar de mentalidad, como ocurre en otras
ingenieras, y ensear no solo tecnologas sino el uso seguro de
las mismas.
A nivel universitario, esta propuesta se alinea con trabajos
previos como [11, 12, 22], donde se realizan diferentes
propuestas de integrar la Seguridad en el currculo, pero que
desgraciadamente no son muy numerosas ni parecen haber
arraigado lo suficiente.
Otro elemento importante, una vez concienciados de la
necesidad de incluir competencias de seguridad en nuestras
asignaturas, es establecer el sentido en el que debemos
modificarlas para incluir dichos conocimientos.
Para responder a esta cuestin, se proponen dos lneas de
actuacin. La primera enfocada al desarrollo y construccin de
software seguro, que afectara a las asignaturas relacionadas
con Programacin e Ingeniera del Software. La segunda,
desde el punto de vista de hacking, ver cuales son las amenazas
ms frecuentes y estudiar las soluciones para paliar o anular
dichas amenazas. Vamos a dar primero una visin general para
luego concretar, en los subapartados siguientes, algunos
ejemplos concretos de contenidos que debera abordarse en
asignaturas ya establecidas y que actualmente se hacen de
manera baja o nula, al menos en el Grado de la Universidad de
Granada.
Vaya por adelantado la aclaracin de que algunos elementos
de seguridad ya se ven el algunas asignaturas pero a veces no
estn sistematizados y dependen de la concienciacin del
profesor correspondiente. Por lo que la propuesta presentada no
solo va en la lnea de incluir nuevos contenidos si no tambin
tratara de sistematizar contenidos y distribuir competencias de
forma coordinada.
Para ayudarnos, en [4] podemos encontrar la lista de las 25
errores software ms usuales que los programadores deberan
mitigar o eliminar. Estos errores estn agrupados en tres
categoras (interaccin insegura entre componentes, gestin
arriesgada de recursos, y defensas porosas) que vamos a
despiezar en funcin de las asignaturas en los que se podran
incluir.
Las primeras asignaturas seran las relacionadas con la

Ingeniera del Software (como Fundamentos de Ingeniera del
Software, de 2 curso), donde no se cubre una metodologa de
desarrollo software que tenga en cuenta la Seguridad como un
requisito no funcional. La seguridad es un requisito que en
muchas ocasiones no se estudia por falta de tiempo.
Las asignaturas bsicas de programacin (Fundamentos de
Programacin y Metodologa de la Programacin, de primer
curso) son las candidatas naturales para introducir conceptos
fundamentales de programacin segura (o defensiva)
destinados a eliminar vulnerabilidades en la etapa de
codificacin, como por ejemplo, desbordamiento de bfer.
Otras asignaturas afectadas derivadas de las principales
amenazas en sistemas, son las asignaturas de programacin
web. Los sistemas web estn expuestos a un elevado nmero
de amenazas que el alumno debe conocer y saber paliar bien
manualmente bien utilizando algn framework de desarrollo
que lo haga. El uso de un framework permite solventar ciertos
tipos de ataques lo que no supone un incremento importante de
contenidos.
Estas consideraciones pueden extenderse como ejemplos de
prcticas a otras asignaturas, por ejemplo, de Big Data [16] que
nos pueden ayudar a procesar grandes volmenes de
informacin dispar con los algoritmos adecuado.
En los subapartados siguientes, concretamos algunos de los
aspectos anteriormente mencionados en las asignaturas ms
directamente afectadas.
A. Asignaturas de programacin
En las asignaturas de programacin se incluiran muchos
de los elementos que caen en el segundo grupo de errores
etiquetado con el nombre de Gestin arriesgada de recursos
que incluira los problemas derivados de: copia de bferes sin
comprobar las entradas (Buffer Overflow) [8], limitacin
inadecuada de un nombre de camino a un directorio restringido
(Path traversal) [17], uso de funciones potencialmente
peligrosas, clculo incorrecto del tamao de un bfer, cadenas
con formato incontrolado o desbordamiento de enteros.
Muchos de estos elementos se ven en las programaciones
bsicas por lo cual lo nico que deberamos hacer es darles
consistencia y ligarlas con la seguridad del programa/sistema
en construccin.
Quizs un elemento que debera incluirse es la utilizacin
de alguna herramienta para el anlisis esttico del cdigo
resultante en los supuestos de programacin. Esto se puede
hacer como parte de las prcticas y no debera ser muy costoso
en recursos.
B. Asignaturas de Ingeniera de Software
La mejor forma de evitar ataques (que no hacen ms que
aprovechar vulnerabilidades) es el desarrollo de software
seguro desde sus inicios. Para ello es necesario el uso de una
metodologa de desarrollo software que contemple la seguridad
desde los inicios de proyecto. Esta necesidad se recoge en
asignaturas como [22], donde se describe la asignatura de
205
JNIC2015
Seguridad de Sistemas Software enmarcada dentro de la

especialidad de Ingeniera del Software.
La propuesta citada es perfectamente vlida para una
especializacin en desarrollo de software, pero responde a un
enfoque diferente al adoptado en la propuesta: no beneficiara a
todos los estudiantes del Grado y duplicara una asignatura. Por
tanto, la propuesta presentada, va en la direccin de tener la
seguridad inmersa en las asignaturas bsicas de Ingeniera del
Software.
Entre los contenidos bsicos a incluir tendramos el uso de
una metodologa segura y el uso de herramientas de anlisis,
verificacin y prueba de software seguro. En estas asignaturas
sera ms costosa la integracin pues supondra en muchos
casos el cambio completo de metodologa software utilizada y
posiblemente presentara ms reticencias al cambio por parte
del profesorado. Pero no cabe duda que los beneficios en la
seguridad del software que construyan nuestros futuros titulado
lo merece.
Se pueden incluir contenidos del grupo de defensas
porosas de los 25 errores comunes del software entre los que
se incluiran: perdida de autenticacin en funciones crticas,
perdida de autorizacin, falta de cifrado de datos sensibles, o
asignacin incorrecta de permisos para recursos crticos.
C. Asignaturas de desarrollo web
El grupo de interaccin insegura entre componentes
incluye mayoritariamente aspectos relacionados con el
desarrollo web, a saber: neutralizacin inadecuada de
elementos especiales en las rdenes SQL (SQL injection),
neutralizacin inadecuada de entradas en la generacin de
pginas web (Cross-site scripting), carga sin restricciones de
archivos con tipos peligrosos, falsificacin de solicitudes
cruzadas (Cross-Site Request Forgecy CSRF), redireccin de
URLs a sitios no confiables, o exposicin de informacin a
travs de mensajes de error.
Tambin seran elementos potenciales a incluir, algunos de
segundo grupo gestin arriesgada de recursos, a saber, la
descarga de cdigo sin comprobacin de integridad, y la
inclusin de funcionalidad desde una esfera de control no
confiable, por ejemplo, cdigo mvil.
Es evidente la dificultad de incluir en dos o tres asignaturas
de 6 crditos la descripcin de todos los elementos citados,
pero sera aconsejable que los alumnos al menos conociesen de
que tratan y, al menos, cmo evitarlos en los casos ms
comunes. Adems de tener presente que deberan de trabajar
con profesionales del tema cuando desarrolla aplicaciones/sitio
web de forma profesional.
Aqu es tambin posible una distribucin de contenidos
entres las numerosas asignaturas sobre desarrollo web incluidas
en los nuevos planes. Por otro lado, en las prcticas de estas
asignaturas se pueden plantear proyectos conjuntos con otras
asignatura, como la que imparto de Seguridad en Sistemas
Operativos, para realizar test de penetracin de sitios web, por
ejemplo.
D. Asignaturas de sistemas operativos

Tradicionalmente, las asignaturas generales de sistemas
operativos suelen incluir algn tema terico de seguridad, que
incluye una introduccin a la misma, y suele centrarse
generalmente en aspectos de autenticacin, autorizacin y
control de acceso.
A esto puntos, habra que aadir algunos elementos
fundamentales y que no son muy difciles de alcanzar ya que se
pueden incluir de manera natural en las prcticas de la
asignatura. Estos hacen referencia a la gestin de
actualizaciones del sistema operativo y las aplicaciones, la
gestin de listas blancas (white lists), y restriccin de
privilegios de administrador a los usuarios que lo necesitan.
Estos elementos aseguran una reduccin del orden del 70% en
la presencia de amenazas, tal como se indica en [2].
Estos elementos pueden completarse, en la medida que el
temario prctico lo permita en la parte de administracin del
sistema con gestin de copias de seguridad (una medida contra
el ransomware), y endurecimiento del sistema operativo (OS
hardening como medida para reducir el frontera de ataque).
IV. CONCLUSIONES
Puesta de manifiesto la importancia creciente de la
construccin de sistemas informticos seguros de cara a
satisfacer las necesidades presentes y futuras de la Sociedad de
la Informacin, se ha pretendido concienciar la necesidad de
una formacin bsica en materia de Ciberseguridad para todos
los estudiantes del Grado en Informtica.
Para ello, se propone un modelo que permitira incluir
competencias de seguridad en los actuales planes de estudios
de forma transversal sin necesidad de una modificacin
estructural de los mismos, sino que afecta al diseo de
contenido de asignaturas ya existentes. Este rediseo puede ir
desde la sistematizacin de contenidos hasta la adaptacin de
nuevas competencias, dependiendo de la asignatura.
Tambin se ha puesto de manifiesto como este modelo
depender de una coordinacin transversal de los contenidos
que si bien exige esfuerzo por parte del profesorado es
fcilmente modularizable para separar dichas competencias en
asignaturas y cuyo resultado sera la formacin profesionales
concienciados con la construccin de sistemas seguros.
La propuesta realizada es abierta a cualquier plan de estudios
de Informtica de forma que sean los profesores responsables
de las asignaturas afectadas quienes decidan los aspectos de
seguridad que pueden cubrir y la profundidad de los mismos.
REFERENCIAS
[1]
[2]
[3]
[4]
206
ACM/IEEE-CS Joint Task Force on Computing Curricula. 2013.

Computer Science Curricula 2013. ACM Press and IEEE Computer
Society Press. DOI: http://dx.doi.org/10.1145/2534860 .
Australian Defence Signals Directorate (DSD), Strategies to Mitigate
Targeted Cyber Instrusions Mitigation Details, Oct. 2012.
BOE, resolucin de 8 de junio de 2009 de la Secretara General de
Universidades, n 187 de 2009, 4 Agosto de 2009.
Steve Chistey (Ed.), CWE/SANS Top 25 Most Dangerous Software
Errors, Common Weakness Enumeration, Sep. 2011.
JNIC2015
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
Comisin Europea, "Ciberdelincuencia: Los ciudadanos de la UE,

preocupados por la seguridad de la informacin personal y los pagos en
lnea". Bruselas 9/6/2012. http://europa.eu/rapid/press-release_IP-12751_es.htm?locale=en.
Neil Couch y Bill Robins, Big Data for Defence and Security, Royal
Unidted Service Institute (RUSI), Septiembre de 2013.
Shreyas Doshi, Building a saer Twitter, publicado el 2 de diciembre de
2014, disponible en https://blog.twitter.con/1024/building-a-safer-twitter.
Mark E. Donaldson, Inside the Buffer Overflow Attack:Mechanism,
Method, & Prevention, SANS Institute InfoSec Reading Room, 2002.
Jess Duva, El 95% de los ciberdelitos cometidos quedan impunes, El
Pas, 4/5/2014.
http://politica.elpais.com/politica/2014/05/03/actualidad/1399117342_852
720.html.
Europa Press, "Espaa sufri ms de 70000 ataques cibernticos, la cifras
ms alta tras EEUU y Reino Unido", Madrid, 5/2/2014.
http://www.europapress.es/nacional/noticia-espana-sufrio-2014-mas70000-ataques-ciberneticos-cifra-mas-alta-eeuu-re20150205115531.html.
Trudy Howles, Carol Romanowski, Sumita Mishra y Rajendra K. Raj, A
Holistic, Modular Approach to Infuse Cyber Security into Undergraduate
Computing Degree Programs, Annual Symposium on Information
Assurance (ASIA 2011), Albany NY, June 2011.
Cynthia E. Irvine, Shiu-Kai Chin, y Deborah Frincke, "Integrating
Security into the Curriculum" (1998). Electrical Engineering and
Computer Science. Paper 84. http://surface.syr.edu/eecs/84.
Identity Theft Resource Center, Breach Report Hits Record High in 2014,
publicado el 12/1/2015, disponible en http://www.idtheftcenter.org/ITRCSurveys-Studies/2014databreaches.html.
ISACA, State of Cybersecurity: Implications for 2015. An ISACA and
RSA Conference Survey, RSA Conference, 2015.
http://www.isaca.org/cyber/Documents/State-ofCybersecurity_Res_Eng_0415.pdf.
McAfee, Net Losses: Estimating the Global Cost of Cybercrime.
Economic impact of cybercrime II , McAfee, Junio de 2014.
http://www.mcafee.com/us/resources/reports/rp-economic-impactcybercrime2.pdf.
Ministerio del Interior, "Avance de los datos estadsticos de 2013
relativos a la cibercriminalidad" , 2013.
http://www.interior.gob.es/prensa/balances-e-informes/2013.
OWASP, Path Traversal, lima revisin 27/5/2009, disponible en
https://www.owasp.org/index.php/Path_Traversal.
Presidencia de Gobierno, Esquema de Ciberseguridad Nacional, Gobieno
de Espaa 2013.
http://www.lamoncloa.gob.es/documents/20131332estrategiadecibersegur
idadx.pdf.
Jorge Rami, "Introduccin de las Enseanzas de Seguridad Informtica
en los Planes de Estudio de las Ingenieras del Siglo XXI", JENUI 2001.
Jorge Rami, Informe grfico de la tesis doctoral La enseanza
universitaria en seguridad TIC como elemento dinamizador de la cultura
y la aportacin de confianza en la sociedad de la informacin en Espaa.
Len, 12 de diciembre de 2013.
http://www.criptored.upm.es/guiateoria/gt_m001i1.htm.
David G. Rosado, Carlos Blanco, Luis Enrique Snchez, Eduardo
Fernndez-Medina, y Mario Piattini, "La Seguridad como una asignatura
indispensable para un Ingeniero del Software", JENUI 2010, pgs. 205212. http://upcommons.upc.edu/revistes/bitstream/2099/11778/1/a25.pdf.
Blair Taylor, Harry Hochheiser, Shiva Azadegan, y Michael OLeary,
"Cross-site Security Integration: Preliminary Experiences across
Curricula and Institutions", Proceedings of the 13th Colloquium for
Information Systems Security Education, Seattle, WA June 1- 3, 2009.
Georgory White and Georgory Nordstrom. 1997. "Security across the
curriculum: using computer security to teach computer science
principles". En Internet besieged, Dorothy E. Denning and Peter J.
Denning (Eds.). ACM Press/Addison-Wesley Publishing Co., New York,
NY, USA 519-525.
207
JNIC2015
Author Index
Author Index
Alegre, Enrique
Alonso, Javier
Andreu Blazquez, Juan Jose
Anido-Bande, Ruben
Astarloa, Armando
137
195
76
168
78
Bagnulo, Marcelo
Banobre-Gomez, Manuel
Beltran Pardo, Marta
Bilge, Leyla
Brezo, Felix
108
105
161, 176
14
32
Caballero, Juan
Camacho, Jose
Cano, Jose Enrique
Caro, Andres
Carriegos, Miguel V.
Casari, Paolo
Catalano, Dario
Cilleruelo Rodrguez, Carlos
Corchado, Juan M.
Corredera de Colsa, Luis Enrique
Cuesta Parejo, Alberto
14, 18, 86
80, 182
182
148, 198
195
51
84
45, 141
82
82
45
Darriba-Bilbao, Vctor M.
de Fuentes, Jose Mara
De La Prieta, Fernando
Dol, Henry
Doychev, Goran
Dumitras, Tudor
168
88, 110
82
51
72
14
Fernandez Robles, Laura

Fiore, Dario
137
84
Garca, Juan F.
Garca Moro, Alberto
Garca Ordas, Diego
Garca Ordas, Mara Teresa
Garca Villalba, Luis Javier
Garca-Olalla Olivera, Oscar
Garca-Planas, Mara Isabel
Garca-Teodoro, Pedro
Garitano, Inaki
195
99
137
137
26, 67
137
116
74, 80
59
208
JNIC2015
Author Index
Gasca, Rafael M.
Gayoso Martnez, Vctor
Gil Perez, Manuel
Goetz, Michael
Gomez Hernandez, Jose Antonio
Gomez-Casero Marichal, Jose Miguel
Gonzalez Manzano, Lorena
Gonzalez Perez, Pablo
Gonzalez Vasco, Mara Isabel
Guarnido Ayllon, Mara
Guevara, Cesar
122
88, 110
76, 129
51
203
141
88, 110
92
90
182
8
Hernandez Encinas, Ascension

Hernandez Encinas, Luis
Holgado, Pilar
1, 190
110
39, 129
Iturbe, Mikel
59
Jacob, Eduardo
Johnson, Richard
78
14
Kalwa, Joerg
Komulainen, Arwid
Kotzias, Platon
Kopf, Boris
51
51
18, 86
72
Leus, Geert
Leyva Garca, Monica
Lopez, Victoria
Lopez Barriuso, Alberto
Lopez Hernandez-Ardieta, Jorge
Lopez Perez, Francisco
Lutu, Andra
51
182
8
82
160
182
108
Macia-Fernandez, Gabriel
Maestre Vidal, Jorge
Magret, Maria Dolors
Mandalari, Anna Maria
Marco, Hector
Martn de Diego, Isaac
Martn del Rey, Angel

Martn Munoz, Agustn
Martn Perez, Miguel
Martn Vaquero, Jesus
Martnez Perez, Gregorio
Martnez-Torres, Javier
Matic, Srdjan
74, 80
26, 67
116
108
22, 24
176
1, 190
110
20
1, 190
76, 129
160
18, 86
209
JNIC2015
Author Index
Molina, Elas
Munoz Gijon, Antonio
Munoz Munoz, Alfonso
78
182
92
Nappa, Antonio
Nasta, Stefano
Nilsson, Bernt
Nilsson, Jan
Nissen, Ivor
Nizzardo, Luca
14
51
51
51
51
84
Otnes, Roald
51
Pacini, Francesco
Parra Lopez, Pascual
Pasic, Aljosa
Perez del Pozo, Angel

Luis
51
160
156
90
Queiruga Dios, Araceli
1, 190
Reyes Maldonado, Anabel

Ribadas-Pena, Francisco J.
Ripoll, Ismael
Rivera, Richard
Rodrguez, Ricardo J.
Rodrguez Sanchez, Gerardo
Rodrguez-Gomez, Rafael A.
Rubio, Yaiza
182
105, 168
22, 24
86
16, 20
1, 190
74, 182
32
Sanchez Rubio, Manuel

Sandoval Orozco, Ana Lucila
Santos, Matilde
Santos Esteban, David
Schreiber, Sabrina
Sevillano, Fernando
Strandberg, Henrik
Suarez Corona, Adriana
45, 141
26, 67
8
160
51
161
51
90
Theron, Roberto
80
Um, Laurence
Uribeetxeberria, Roberto
116
59
van Walree, Paul
Varela Vaca, Angel

Jesus
Vila, Jose
Villagra, Vctor A.
51
122
16
39, 99, 129
210
JNIC2015
Author Index
Vinals, Vctor
20
Zago, Mattia
Zorzi, Michele
Zurutuza, Urko
76
51
59
Oberg,
Tommy
51
211

Jnic2015 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Jnic2015 PDF

Caricato da

Copyright:

Formati disponibili

RIASC, Universidad de Leon INCIBE

ACTAS DE LAS PRIMERAS

Jornadas Nacionales de Investigacion en Ciberseguridad (1a . 2015. Leon)

(Informatica)-Investigacion-Congresos. I. Universidad de Leon. Area

IMDEA Software Institute

Industrial Track Chair

Instituto Nacional de Ciberseguridad

Education & Innovation Track

Challenges Track Chair

Universidad Carlos III de Madrid

Students Session Chair

IMDEA Software Institute

IMDEA Networks Institute

Local Arrangement Chairs

chair: Ramon Angel

Rafael Ignacio Alvarez

Universidad Politecnica de Madrid

Experiences on NFC Relay Attacks with Android: Virtual Pickpocketing

CARONTE : Detecting Location Leaks for Deanonymizing Tor Hidden

Prevencion de ataques ROP mediante Instrumentacion Dinamica . . . . . . .

Robustenciendo Apache frente a ataques de desbordamiento de pila . . . . .

Prevencion de explotacion de vulnerabilidades mediante diversificacion

Neural Networks applied to the learning process of Automated

Resource Monitoring for the Detection of Parasite P2P Botnets . . . . . . . . . 74

Security services as cloud capabilities using MAS . . . . . . . . . . . . . . . . . . . . .

Mara Isabel Gonz

Prototipado rapido de un analizador de malware para Android

Evolving from a static toward a proactive and dynamic risk-based

Bachillerato de Excelencia, Criptografa y Seguridad de la Informacion:

Primera sesion: Vulnerabilidades, malware y exploits 1

Propagacion del malware: nuevos modelos para

Resumen La mayor parte de los modelos matem

Primera sesion: Vulnerabilidades, malware y exploits 1

conclusiones se presentan en la seccion 4.

II. Los modelos individuales: una breve

Primera sesion: Vulnerabilidades, malware y exploits 1

Fig. 1. Diagrama de flujo representando la din

Primera sesion: Vulnerabilidades, malware y exploits 1

malware en cada instante de tiempo y e es la probabilidad

Observese que para evitar que se produzca una epidemia

E0 (82,2581, 0, 0, 19,7419), de modo que en el instante

A.4 Puntos de equilibrio del sistema

de equilibrio libre de infeccion, y E1 = (S1 , P1 , I1 , R1 )

Primera sesion: Vulnerabilidades, malware y exploits 1

B. El modelo individual basado en agentes

B.1 Caractersticas de los agentes

1, con probabilidad [i, j, t] q[i, j]

0, con probabilidad 1 [i, j, t] q[i, j]

El coeficiente de sistema operativo [i]: ser

1, si el tipo de dispositivo al que pertence

Primera sesion: Vulnerabilidades, malware y exploits 1

B.2 Las reglas de transicion

En este sentido existen diferentes tipos de dispositivos

Las reglas de transicion entre los diferentes estados en

Transicion de susceptible a infeccioso: El agente i-esimo

Transicion de portador o infeccioso a recuperado: El

Primera sesion: Vulnerabilidades, malware y exploits 1

[13] T. Terano, H. Kita, T. Kaneda, K. Arai, H. Deguchi (Eds.),

Primera sesion: Vulnerabilidades, malware y exploits 1

Sistema de Deteccion de Intrusos aplicando

Resumen Esta trabajo propone un modelo de datos y

Con los tipos anteriores de recolecci

Palabras Clave: Sistema inmune artificial, Sistema