KD Argentina

XIX Congreso Argentino de Ciencias de la Computación CACIC 2013
Improving versatility in keystroke dynamic

systems
Enrique Calot, Juan Manuel Rodriguez, and Jorge Salvador Ierache?
Laboratorio de Sistemas de Información Avanzados,

Facultad de Ingenierı́a, Universidad de Buenos Aires,
Buenos Aires, Argentina
{ecalot,jmrodri}@fi.uba.ar,jierache@yahoo.com.ar
Abstract. Keystroke dynamics is a biometric technique to identify users

based on analyzing habitual rhythm patterns in the way they type. In
order to implement this technique different algorithms to differentiate an
impostor from an authorized user were suggested. One of the most pre-
cise method is the Mahalanobis distance which requires to calculate the
covariance matrix with all that this implies: time processing and track
each individual keystroke event. The hypothesis of this research was to
find an algorithm as good as Mahalanobis which does not require track
every single keystroke event and improve, where possible, the process-
ing time. To make an experimental comparison between Mahalanobis
distance and euclidean normalized, a distance which only requires calcu-
late the variance, an already studied dataset was used. The results were
that use normalized euclidean distance is almost as good as Mahalanobis
distance even in some cases could work better.
Keywords: Keystroke Dynamics, Web based authentication, Mahalanobis

distance, Biometrics, typing biometrics
1 Introduction
The variables that help make a handwritten signature a unique human identifier
also provide a unique digital signature in the form of a stream of latency periods
between keystrokes. The handwritten signature has a parallel on the keyboard.
The same neurophysiological factors that make a written signature unique are
also exhibited in a user’s typing pattern[1].
Password typing is the most widely used identity verification method in
World Wide Web based electronic commerce. Due to its simplicity, however,
it is vulnerable to impostor attacks. Keystroke dynamics and password checking
can be combined to result in a more secure verification system[2].
This authentication is fragile when there is a careless user and/or a weak
password. Biometric characteristics are unique to each person and have advan-
tages as they could not be stolen, lost, or forgotten[3, 4].
?
This paper was done with Cloodie R&D Support
ISBN 978-987-23963-1-2 1434

2 Improving versatility in keystroke dynamic systems
The biometric technology employed in this paper is the typing biometrics,

also known as keystroke dynamics. Typing biometrics is a process that analyzes
the way a user types at a terminal by monitoring the keyboard inputs in attempt
to identify users based on their habitual typing rhythm patterns[5, 4].
Even though WWW keystroke dynamic systems may run locally on the web
browser, due to security measures it should be ran on the webserver layer. This
paper discusses an approach to reduce data transmission size.
Using a know dataset[6] we designed an experiment to compare three methods
to compute the keystroke dynamics of users and compare them with impostors.
Our hypothesis is that one of the most used and precise method –the Maha-
lanobis distance– is as successful as the second method –normalized euclidean
distance–. Ignoring the success rates, there are some advantages that the normal-
ized euclidean distance has over the Mahalanobis distance, so if the hypothesis
is confirmed using this method should prove to be a more useful way to calculate
keystroke dynamics.
Some advantages of the normalized euclidean distance ar the lesser trans-
ferred information, processing time and the bigger versatility when changing
passwords.
2 Current implementations
There are different methods to compare keystrokes, all based on measuring the
distances between two strokes, a negative result is found when both differ more
than a threshold. One of the best methods is the Mahalanobis distance[2, 6].
Three methods are shown below, each method is a generalization of the
previous one.
2.1 Euclidean distance
The time a user press a key or the time between one key and the other may
result in a vector of events (Γ ). Each event represent a key hold time or the
elapsed time between two keys. Since in the training phase an event may occur
several times, the vector is a list of the expected values of every event time.
Calculating the euclidean distance between two vectors works as a compari-
son algorithm, with relatively high success rates[6].
N
X
d(Γ1 , Γ2 )2 = kΓ1 − Γ2 k2 = (Γ1,i − Γ2,i )2 (1)
i=1
Where Γ1 is the vector of training event times and Γ2 is the vector of testing
event times.
To optimize calculation timings the squared norm is actually used.
ISBN 978-987-23963-1-2 1435

Improving versatility in keystroke dynamic systems 3
2.2 Normalized euclidean distance
A disadvantage of the former method is that important information is ignored.

The variance of each event time should be taken into consideration, and that is
exactly what the normalized euclidean distance does: adding the variance (s2i )
of each event time.
Using the inverted variance of the training set (Γ1 ) as a weight factor, the
normalized euclidean distance is defined as
N
X (Γ1,i − Γ2,i )2
d(Γ1 , Γ2 )2 = (2)
i=1
s2i
where s2i is the variance of each element of Γ1 .
2.3 Mahalanobis distance
Again, the former method is skipping information, this time is the covariance
between events.
Mahalanobis distance is defined as
d(Γ1 , Γ2 )2 = (Γ1 − Γ2 )T S −1 (Γ1 − Γ2 ) (3)

Where S −1 is the inverted covariance matrix corresponding to all events in
the training set Γ1 [7].
3 Problems of Mahalanobis distance in keystroke

dynamics
Translating each method to a kernel matrix it turns out that in equation 3 the
matrix S is the identity in the euclidean distance, a diagonal with the variances in
the normalized euclidean distance and the covariance matrix in the Mahalanobis
distance.
3.1 Distance kernel matrix size
To generate the covariance matrix for the Mahalanobis distance all key-press
events and their respective timings should be transmitted to the server while
training –or at least the covariance matrix and the expected event timings–.
But to generate the diagonal matrix for the normalized euclidean method is it
possible to send only three integer numbers per event or two floats.
2
Using the property V ar[X] = E[X 2 ] − E[X]
Pn it is possible to generate
Pn the
2
variance using only the sum of squares SS = i=0 Γ1,i , the sum S = i=0 Γ1,i
and the total n since E[X 2 ] = SS S
n and E[X] = n . All three numbers are natural
and may be combined in an N3 vector which supports commutative addition
properties. This method allows parallelized variance calculus[9].
ISBN 978-987-23963-1-2 1436

Table 1. Different parameters to be sent to the server
Distance Method Variables

Euclidean (S, n) ∈ N2×n or Γ = E[X] ∈ Rn
Normalized euclidean (S, SS, n) ∈ N3×n
Mahalanobis Γ = E[X] ∈ R and Cov[X] ∈ Rn×n
n
There are several ways to send the data depending on the algorithm to be
used. Table 1 compares them.
For example, when 20 events are used, the covariance matrix has 20×20 = 400
values and the Γ = E[X] vector has 20 values. Normally a Rn×n matrix can be
encoded with n2 numbers, but as Cov[a, b] = Cov[b, a], covariance matrix is
symmetric and therefore it can be encoded with n(n+1) 2 numbers. Assuming a
real number and an integer has the same size, the transmission would be of
20×21
2 + 20 = 230 numbers while the normalized euclidean only transmits 3 ×
20 = 60 numbers. Generalizing, the data transmission of Mahalanobis distance
is n(n+1)
2 + n reals, that is O(n2 ), normalized euclidean is 3n integers, that is
O(n) and euclidean is 2n integers or n reals, that is also O(n).
3.2 One password algorithm

Another problem is that training is done with only one password. A new pass-
word should require the user to re-train all the covariance matrix with Maha-
lanobis.
Normalized euclidean distance may reuse the variances of the common keys
between two different passwords while Mahalanobis distance may not.
3.3 Backspace eliminating digraphs

When the user trains it is possible that mistakes a character and use backspace
to correct it, in this case one event will be missing. For example the word “train”
has 5 characters so the events will be t.hold, t.up-r.down, r.hold, etc. The
problem occurs when “te[backspace]rain” is typed, the event t.up-r.down was
not recorded because there were two keys in the middle “e” and [backspace].
Having a variable number of events per key is a problem to calculate the
covariance matrix, but allows to process backspaces in passwords (sacrificing
the success rate due to lesser information available) and free text.
Table 2 shows an example of Mahalanobis method with three pairs of events
and normalized euclidean with three and two times per event respectively.
3.4 Processing times

Calculating the covariance matrix and inverting it should take a considerable
amount of time for the Mahalanobis method, the time here is expected to be
ISBN 978-987-23963-1-2 1437

Table 2. Example of how timing counts are dependent on the event in Mahalanobis
distance
Method Key Times Inverse S −1

Matrix S
67 175 556 350

A.hold 90 99 97 3 6 2209
− 2209
, , 175 139 350 268
A.up-B.down 161 171 174 6 3
− 2209 2209
Mahalanobis 67 3
A.hold {90}, {99}, {97} 3
0 67
0
Normalized 1
A.up-B.down {161}, {171} 0 50 0 50
euclidean
O(n2 ). Normalized euclidean should also take time to compute the variances,
but this procedure is O(n). Inverting the matrix lacks of relevant costs due to
the properties of the diagonal matrices. Euclidean distance should be the fastest
algorithm because of its simplicity.
It is important to remark that due to parallelized calculation of the vari-
ance, part of the calculating time in training mode for the normalized euclidean
distance may be done while reading the keyboard by the user machine.
The experiment also intends to measure algorithms processing time.
4 Experimental comparison
We use an already studied dataset for two main reasons, one is because it was
collected in a controlled laboratory environment, the second reason is because
14 detection algorithms were tested using this dataset[6] and that give us a
big framework to start our research. The data was collected from 50 different
users along 8 days or sessions –totalizing 400 cases per user–, in each session the
users typed always the same string: “.tie5Roanl” which represents a reasonable
secure password. When any error in the sequence was detected, the subject had
been prompted to retype the password. To make this a laptop was set up with
an external keyboard to collect data and a Windows application was developed
to prompt the subjects to type the password. The application displays it in a
screen with a text-entry field. In order to advance to the next screen, the subject
must type the 10 characters of the password correctly in sequence and then press
Enter. The data set contains the hold time of each key, the time between two
consecutive keys were pressed and the time since one key was released and the
next was pressed. One of the three values depends linearly of the other two. Due
to preconditions of covariance one value was dropped away leaving two values
per key.
From the 400 cases per user, the first 200 cases were used to train the detec-
tion algorithm and the second 200 cases were used to validate it, also the first 5
cases of all the other users were taken to generate an impostor dataset in order
to validate negative cases. This data set and schema was taken from Killourhy
and Maxion[6].
We performed 19 tests, the first using two events (the first two values of the
Γ vector) and increasing the number of events until the last one, using all twenty.
ISBN 978-987-23963-1-2 1438

We expected to have a best success rate in the last test because it counts with
more information. We ran the three mentioned algorithms in each test.
Finally we calculated the area under the receiver operating characteristics
(ROC) curve –a performance measure for machine learning algorithms com-
monly used in systems that learns by being shown labeled examples[8]–. This
method, known as AUC, was chosen because it is a classifier performance eval-
uator independent of the decision threshold chosen on the keystroke distances.
5 Results
With the one key test case we obtained in one sample user Γ = [98.98, 166.905],
where first value corresponds to the expected key-hold time and the second to the
expected elapsed time until the next key was pressed. Both times are expressed
in milliseconds.
−1
−1 −1 341.29 282.19 0.0031 −0.00016
SM ahalanobis = Cov[Γ ] = =
282.19 5464.9 −0.00016 0.0002
−1
−1 341.29 0 0.0029 0
SnormalizedEuclidean = =
0 5464.9 0 0.00018

−1 10
Seuclidean = Seuclidean =
01
Note that SM ahalanobis and SnormalizedEuclidean have the same diagonal val-
ues but this is not the case with their inverses.
Table 3. Experimental results
N Method Total Errors ROC Zero-miss False-Alarm Time

2 Mahalanobis 0.01887 80.43% 7461 of 12750 769 of 10200 1.356s
2 Normalized euclidean 0.01899 80.17% 7451 of 12750 788 of 10200 1.300s
2 Euclidean 0.02240 70.61% 9030 of 12750 649 of 10200 0.872s
20 Mahalanobis 0.00970 94.60% 5576 of 12750 464 of 10200 1.896s
20 Normalized euclidean 0.00919 94.84% 5581 of 12750 428 of 10200 1.764s
20 Euclidean 0.01440 88.27% 6853 of 12750 844 of 10200 1.704s
Table 3 shows the results of the 3 methods with 2 and 20 timing events
respectively. Each method shows the area under ROC curve in percentage among
with zero-miss and false-alarm rates. It is also shown the total processing time
ISBN 978-987-23963-1-2 1439

of training, testing all the 12750 positive and 10200 negative sets and calculating
the results.
In the last test –with 20 events–, normalized euclidean distance method per-
formed even better than Mahalanobis.
As expected, our hypothesis that in the test with 20 timing events is better
than the test with 2 was confirmed and that Mahalanobis and normalized eu-
clidean distance are both superior than euclidean distance was confirmed too.
Processing is, as expected, bigger for Mahalanobis and decreasing for normalized
euclidean and finally, the fastest method, euclidean distance.
100
95
90
ROC Area (%)
85
80
75
Mahalanobis
Normalized Euclidean
Euclidean
70
2 4 6 8 10 12 14 16 18 20
Number of events
Fig. 1. Distance methods compared in success versus amount of information
In Figure 1 it is possible to appreciate how similar are the normalized eu-

clidean and Mahalanobis distances compared to the euclidean.
6 Conclusions
Normalized euclidean distance and Mahalanobis distance are almost the same
in all ran tests. In the case of 20 events the results varied 0.24%. Normalized
euclidean was faster than Mahalanobis distance for 132ms but slower than eu-
clidean for only 60ms. Versatility in normalized euclidean is also an advantage,
passwords may be changed and the already-trained keys be kept in the new train-
ing. Those results lead to the conclusion that normalized euclidean distance is
strong enough to be used and its advantages in data sizes and versatility are con-
siderably important to be chosen against Mahalanobis distance and its success
rate suggests that it should be employed against euclidean distance.
6.1 Future lines of research

We are exploring the way users may vary keystroke dynamics over the time.
Using variance parallelization principle[9] there is a way to “forget” the train-
ing, making it autoadaptive with this time-wise learning technique. We are also
exploring new fields on keystroke dynamics that include user emotional state
detection.
Acknowledgments. This paper acknowledges support from Cloodie R&D.
References
1. Joyce, R.; Gupta, G.: Identity authentication based on keystroke latencies. Commun.
ACM 33, 2 (February 1990), 168-176. http://doi.acm.org/10.1145/75577.75582
(1990)
2. Cho, S.; Han, C.; Han., D. H.; Kim, H. I.: Web based Keystroke Dynamics Iden-
tity Verification using Neural Network. Journal of Organizational Computing and
Electronic Commerce, Vol. 10, No. 4, pp. 295–307 (2000)
3. Polemi, D.: Biometric Techniques: Review and Evaluation of Biometric Techniques
for Identification and Authentication, Including an Appraisal of the Areas Where
They are Most Applicable. Institute of Communication and Computer Systems,
National Technical University of Athens, Athens, Greece. Retrieved on 2013-07-
01: ftp://ftp.cordis.lu/pub/infosec/docs/biomet.doc, EU Commission Final Rep.
(1997)
4. Araujo, L. C. F.; Sucupira, L. H. R.; Lizarraga, M. G.; Ling, L. L.; Yabu-Uti, J.
B. T.: User authentication through typing biometrics features. Signal Processing,
IEEE Transactions on, vol. 53, no. 2, pp.851–855 (2005)
5. Monrose, F.; Rubin, A. D.: Keystroke dynamics as a biometric for authentication.
Future Gen. Comput. Syst., vol. 16, no. 4, pp. 351-359 (2000)
6. Killourhy, K. S.; Maxion, R. A.: Comparing Anomaly-Detection Algorithms for
Keystroke Dynamics. In International Conference on Dependable Systems & Net-
works (DSN-09), pp. 125–134, Estoril, Lisbon, Portugal, 29 June to 02 July 2009.
IEEE Computer Society Press, Los Alamitos, California (2009)
7. Mahalanobis, P. C.: On the generalised distance in statistics. Proceed-
ings of the National Institute of Sciences of India 2 (1): 49-55. Re-
trieved on 2013-07-01: http://www.new.dli.ernet.in/rawdataupload/upload/
insa/INSA_1/20006193_49.pdf (1936)
8. Bradley, A. P.: The use of the area under the ROC curve in the evaluation of
machine learning algorithms. Pattern Recognition, Volume 30, Issue 7, July 1997,
Pages 1145–1159, ISSN 0031-3203, http://dx.doi.org/10.1016/S0031-3203(96)
00142-2. (1997)
9. Chan, T. F.; Golub, G. H.; LeVeque, R. J.: Updating Formulae and a Pair-
wise Algorithm for Computing Sample Variances. Technical Report STAN-
CS-79-773, Department of Computer Science, Stanford University. Retrieved
on 2013-07-01: ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/79/773/
CS-TR-79-773.pdf (1979)
ISBN 978-987-23963-1-2 1441

Gestión Integral de Seguridad de Infraestructuras críticas paralas

organizaciones locales alineadas a las Normas IRAM ISO IEC 27.001 y
27002.
Mag. Licenciada Mirta Elizabeth Navarro1 Mag. Abogado María del C. Becerra22,
marisabecerra2005@yahoo.com.ar, mirthaenavarro@yahoo.com.ar
Abstract.:Con esta propuesta de gestión integral diseñada para la protección de la información alineada
a la norma IRAM ISO IEC 27001, 27002 y a lastendencias y normas de seguridad informática, consistente
en la creación y adopción de un marco regulatorio que favorezca la identificación y protección de las
infraestructuras estratégicas y críticas de la U.N.S.J., se favorecerá la colaboración entre los diversos
sectores públicos y privados, para el desarrollo de estrategias y estructuras adecuadas para la protección de
los activos de información. Todo ellodará real importancia a la nueva visión del estado, liderada por la
incorporación de las TIC´s en los procesos administrativos y bajo el sustento de la comunicación íntegra y
confidencial necesaria en el entorno globalizado de e-gobierno, se busca dar impulso a la administración
electrónica.
Keywords: Gestión Integral de seguridad. Infraestructuras críticas. Propuesta para implementar el plan
Infraestructuras críticas y ciberseguridad.
1 Introducción
Para ayudar a garantizar una gestión de integral de las infraestructuras críticas3 de las empresas se
tomaron en cuenta dos normas de la familia de las normas ISO 27000 adaptadas y traducidas en nuestro país,
especialmente las Normas IRAM ISO 27.0014 y 270025 y su antecedente 17799), en base a ellas se
definieron los requisitos para el sistema de gestión de seguridad (SGSI) propuesto.
En el proyecto “Convergencia de Tecnologías informáticas y Metodologías para la implementación de
sistemas de Información”se analizaron las políticas, prácticas, procedimientos y estructuras organizacionales
como conjunto de controles necesarios para implementar un sistema de gestión para las infraestructuras
críticas.
En Argentina por Resolución 580/2011 se crea, en el ámbito de la Oficina Nacional de Tecnologías de
Información de la subsecretaria de Tecnologías de Gestión de la Secretaria de Gabinete de la Jefatura de
Gabinete de Ministros, el “Programa Nacional De Infraestructuras Criticas De Información y Ciberseguridad”
en el marco de lo establecido la Ley de Ministerios (t.o. Decreto Nº 438/92), a fin de impulsar la creación y
adopción de un marco regulatorio específico que propicie la identificación y protección de las infraestructuras
1Licenciada en Administración de empresas egresada de la U.N.S.J. Magíster en Gestión de Organizaciones egresada de la

Universidad de Valparaíso. Chile. Docente de la U.N.S.J. Directora del Proyecto Convergencia de Tecnologías
informáticas y Metodologías para la implementación de Sistemas de información
2Abogado, egresado de la UCC. Magíster en Informática egresado de la Universidad Nacional de la Matanza. Docente
Investigadora de la U.N.S.J. Directora del Instituto de informática del Foro de Abogados de San Juan
3
Las infraestructuras críticas son aquellas instalaciones, redes, equipos físicos y de tecnología de la información cuya
interrupción o destrucción tendría un impacto en el bienestar de los ciudadanos o en el eficaz funcionamiento del
gobierno. Las infraestructuras críticas están presentes en numerosos sectores: financiero, transporte y distribución,
energía, salud, comunicaciones, y administraciones públicas.
4
En Argentina es IRAM, como organismo nacional de normalización, quien la estudia a través del Subcomité de
Seguridad de la Información y la adopta como IRAM-ISO/IEC 27001. Se publica bajo el nombre Tecnología de la
información. Sistemas de gestión de la seguridad de la información (SGSI). Requisitos, difundiéndola en la región a
través de cursos y seminarios.
5Aprobada y consensuada por el IRAM (Instituto de Normalización Argentino) en el año 2002
ISBN 978-987-23963-1-2 1442

estratégicas y críticas del Sector Público Nacional, los organismos interjurisdiccionales y las organizaciones
civiles y del sector privado que así lo requieran, y la colaboración de los mencionados sectores con miras al
desarrollo de estrategias y estructuras adecuadas para un accionar coordinado hacia la implementación de las
pertinentes tecnologías, entre otras acciones.
El “Programa Nacional de Infraestructuras Criticas de Información y Ciberseguridad” no interceptará ni
intervendrá en conexiones o redes de acceso privado de acuerdo a lo estatuido por la Ley Nº 25.326 de
Protección de los Datos Personales y su Decreto Reglamentario Nº 1558 del 29 de noviembre de 2001.
El programa de ICIC, tendrá a su cargo los siguientes objetivos:
a) Elaborar y proponer normas destinadas a incrementar los esfuerzos orientados a elevar los umbrales de
seguridad en los recursos y sistemas relacionados con las tecnologías informáticas en el ámbito del Sector
Público Nacional.
b) Colaborar con el sector privado para elaborar en conjunto políticas de resguardo de la seguridad digital
con actualización constante, fortaleciendo lazos entre los sectores público y privado; haciendo especial
hincapié en las infraestructuras críticas.
c) Administrar toda la información sobre reportes de incidentes de seguridad en el Sector Público Nacional
que hubieren adherido al Programa y encausar sus posibles soluciones de forma organizada y unificada.
d) Establecer prioridades y planes estratégicos para liderar el abordaje de la ciberseguridad, asegurando la
implementación de los últimos avances en tecnología para la protección de las infraestructuras críticas.
e) Investigar nuevas tecnologías y herramientas en materia de seguridad informática.
f) Incorporar tecnología de última generación para minimizar todas las posibles vulnerabilidades de la
infraestructura digital del Sector Público Nacional.
g) Asesorar a los organismos sobre herramientas y técnicas de protección y defensa de sus sistemas de
información.
h) Alertar a los organismos que se adhieran al presente Programa sobre casos de detección de intentos de
vulneración de infraestructuras críticas, sean estos reales o no.
i) Coordinar la implementación de ejercicios de respuesta ante la eventualidad de un intento de vulneración
de las infraestructuras críticas del Sector Público Nacional.
j) Asesorar técnicamente ante incidentes de seguridad en sistemas informáticos que reporten los
organismos del Sector Público Nacional que hubieren adherido.
k) Centralizar los reportes sobre incidentes de seguridad ocurridos en redes teleinformáticas del Sector
Público Nacional que hubieren adherido al Programa y facilitar el intercambio de información para
afrontarlos.
I) Actuar como repositorio de toda la información sobre incidentes de seguridad, herramientas, técnicas de
protección y defensa.
m) Promover la coordinación entre las unidades de administración de redes informáticas del Sector Público
Nacional, para la prevención, detección, manejo y recopilación de información sobre incidentes de seguridad.
n) Elaborar un informe anual de la situación en materia de ciberseguridad, a efectos de su publicación
abierta y transparente.
ñ) Monitorear los servicios que el Sector Público Nacional brinda a través de la red de Internet y aquellos
que se identifiquen como Infraestructura Crítica para la prevención de posibles fallas de Seguridad.
o) Promover la concientización en relación a los riesgos que acarrea el uso de medios digitales en el Sector
Público Nacional, las Organizaciones de Gobierno, al público en general, como así también del rol
compartido entre el Sector Público y Privado para el resguardo de la Infraestructura Crítica.
p) Difundir información útil para incrementar los niveles de seguridad de las redes teleinformáticas del
Sector Público Nacional.
k) Interactuar con equipos de similar naturaleza.
II.-Gestión integral de la seguridad.
A los efectos de garantizar la selección de controles de seguridad adecuados y proporcionales y para

proteger la información crítica de las organizaciones se eligieron las Normas IRAM ISO IEC mencionadas
porque se consideran recomendables para cualquier empresa grande o pequeña en cualquier parte del mundo
y para aquellos sectores que tienen información crítica o gestionan la información de otras empresas.
ISBN 978-987-23963-1-2 1443

Para protegerse de estas amenazas la British Standards Institution publicó en 1995 la norma BS 7799 -
parte 1 y 2- que sirvió como antecedente a ISO para el estudio de dos estándares internacionales adoptados y
reconocidos a nivel mundial: la norma ISO/IEC 17799:2000 Information technology - Security techniques -
Code of practice for information security management, revisada en 2005 y reemplazada por la ISO/IEC
27002, que establece los requisitos fundamentales a tener en cuenta para establecer, operar, controlar, revisar,
mantener y mejorar un sistema de gestión de seguridad de la información. La norma 27.002 establece un
conjunto de reglas de normalización de los conceptos y operatorias de seguridad informática.
Tal cual lo enfatizan los autores, la seguridad de la información se logra implementando un conjunto
adecuado de controles que abarca políticas, practicas, y procedimientos, estructuras organizaciones y
funciones del software. Estos controles deben ser establecidos para garantizar que se logren los objetivos
específicos de seguridad de la organización”.
La edición 2000 de esta norma fue publicada por IRAM dando como resultado la IRAM-ISO/IEC
17799:2002. Ésta fue estudiada por el Subcomité de Seguridad de la Información de IRAM (revisión de la
IRAM 17798 cuyo antecedente es la BS 7799-2).
La norma está basada en el mismo modelo de los sistemas de gestión de la calidad de la familia ISO
9000. Establece conceptos similares sobre Requisitos de la documentación: alcance, política de seguridad,
enfoque sistémico de identificación y valoración de riesgos, operaciones para el tratamiento de los riesgos,
objetivos de control, controles y aplicabilidad de los mismos.
Actualmente para certificar un Sistema de Gestión de la Seguridad implementado bajo la norma ISO/IEC
17799 (ISO 27002) se utiliza la norma ISO/IEC 27001: 2005.
Tal como lo prevé la Norma IRAM ISO IEC 27.001 para una adecuada gestión de la seguridad de la
información se propone implantar en las organizaciones locales un sistema que aborde esta tarea de una
manera metódica, documentada y basada en objetivos claros de seguridad y en una evaluación de los riesgos
a los que está sometida la información de las organizaciones locales.
En la práctica esta norma se presenta embebida en varias normativas estatales en Argentina. Forma parte
de reglamentaciones de organismos del Estado para cumplir con diversos procedimientos, entre los que se
destaca la comunicación A4609 del BCRA (Banco Central de la República Argentina). Un decreto del Poder
Ejecutivo de la Secretaria de la Función Pública (2006) instaló la norma con el nombre de Sistema de Gestión
de Seguridad del Estado. Existen 400 organismos estatales que la implementan pero no la certifican.
La comunicación A-4609 del Banco Central de la República Argentina6, resulta así aplicable al conjunto
de entidades del sistema regulado por dicha institución y establece los “Requisitos mínimos de gestión
implementación control de los riesgos relacionados con la tecnología informática, sistemas de información y
recursos asociados para entidades financieras”.
En el apartado referido a la Gestión de seguridad la comunicación establece que las entidades financieras
deben considerar en su estructura organizacional un área para la protección de los activos de información, con
el fin de establecer los mecanismos para la administración y el control sobre el acceso lógico y físico a sus
distintos ambientes tecnológicos y recursos de información: equipamiento principal, plataforma de sucursales,
equipos de departamentales, subsistemas o módulos administradores de seguridad de los sistemas de
aplicación, sistemas de transferencias electrónica de fondos, base de datos, canales de servicios electrónicos,
banca por Internet y otros.
Por la complejidad de la implementación de la Norma, sería conveniente que la Administración Pública
definiera de manera sistemática el alcance el proyecto, principalmente en las áreas de CONTROL DE
ACTIVOS Y SEGURIDAD DE LOS RECURSOS HUMANOS.
Adoptar una norma de gestión de la seguridad de la información garantiza la correcta consideración de los
activos de información de una organización junto con el análisis de su vulnerabilidad y amenazas, también
asegura que se establezcan controles de procedimiento y tecnológicos (gestión de accesos mediante registro
de huellas, control de información por Internet y mails, controles sobre el software y las bases de datos).
Mediante la norma estos procedimientos se desarrollan de manera ordenada, pautada y controlada; no como
simples impulsos aislados, sino como un verdadero sistema que garantice la confidencialidad, integridad y
acceso a la información de gestión, de dirección, y pública de la empresa.
A partir de la generalización de la tecnología de la información y la comunicación proliferaron las
situaciones de riesgo para los sistemas de información, las bases de datos y los recursos de hardware, a los
cuales denominamos activos de la información.
6
B.O. 31.156,16/05/2007, corregida por la Comunicación C-48.583/2007 BCRA y actualizada por la Comunicación B-
9042/2007 BCRA
ISBN 978-987-23963-1-2 1444

Se tomó en cuenta la decisión administrativa 669/2004 que estableció que los organismos del Sector
Público Nacional comprendidos en los incisos a) y c) del artículo 8º de la Ley Nº 24.156 y sus modificatorias
deberán dictar o adecuar sus políticas de seguridad. Conformación de Comités de Seguridad en la
Información. Funciones de los mismos y responsabilidades en relación con la seguridad.
Los comités deberán integrado al menos por un miembro del Directorio o autoridad equivalente, y el
responsable máximo del área de Tecnologías Informática y sistemas.
III.- Infraestructuras críticas.
Infraestructuras Criticas son las infraestructuras estratégicas (es decir, aquellas que proporcionan
servicios esenciales) cuyo funcionamiento es indispensable y no permite soluciones alternativas, por lo que su
perturbación o destrucción tendría un grave impacto sobre los servicios esenciales”. Se refiere tanto a
empresas del sector TIC, agua, energía, industria nuclear, sistema financiero o transporte, ente otras.
Las Infraestructuras Criticas, son consideradas un conjunto de recursos, servicios, tecnologías de la
información y redes, que en el caso de sufrir un ataque, causarían gran impacto en la seguridad, tanto física
como económica, de los ciudadanos o en el buen funcionamiento del Gobierno de la Nación, siendo menester
dictar medidas para la protección de tales infraestructuras.
Existen gran variedad de formas de ataque a los sistemas, con el fin de obtener esta información.
Pero también existen políticas y paradigmas de seguridad actuales que nos permiten poner una brecha a estos
ataques y proteger este recurso tan valioso.
Tomando en cuenta que el mundo contemporáneo se caracteriza por los profundos cambios
originados en el desarrollo y difusión de las tecnologías de la información y la comunicación en la sociedad,
las cuales se encuentran sustentadas en gran medida en el ciberespacio. Y que la utilización de las
comunicaciones virtuales es un recurso que depende de la infraestructura digital, la cual es considerada como
infraestructura crítica, entendiéndose ésta como imprescindible para el funcionamiento de los sistemas de
información y comunicaciones, de los que a su vez dependen de modo inexorable, tanto el Sector Público
Nacional como el sector privado, para cumplir sus funciones y alcanzar sus objetivos.
En el planteamiento de los instrumentos de planificación, se detectaron cambios estratégicos de
protección que hasta ahora estaban enfocados principalmente a la seguridad física y que, ahora, como no
podía ser de otra manera tienen un enfoque integral y actual de protección de las Infraestructuras críticas
como conjunto de actividades destinadas a asegurar la funcionalidad, continuidad e integridad de las
infraestructuras críticas con el fin de prevenir, paliar y neutralizar el daño causado por un ataque deliberado
contra infraestructuras y garantizar la integración de estas actuaciones.
Se requiere un planteamiento de seguridad holístico (física, lógica, personal y operativa) de
verdadera Seguridad Integral = Protección + Prevención donde la Gestión de riesgos debe ser su protagonista
más importante y las soluciones pasen por la Evaluación de Impactos, establecimiento de Planes de
contingencia, Planes de continuidad del negocio y de las operaciones y la determinación de los Sistemas y
aplicaciones de garantía de alta disponibilidad.
En la Protección de Infraestructuras Críticas, es preciso estudiar los criterios que permitan determinar
qué factores confieren carácter crítico a una infraestructura o elemento de infraestructura particular. Los
criterios de selección deberían basarse en conocimientos sectoriales y generales. Pueden definirse tres factores
de identificación de una infraestructura crítica potencial:
• Alcance - la pérdida de un elemento de infraestructura crítico se mide por el tamaño del área geográfica que
pudiera verse afectada por su pérdida o indisponibilidad.
• Magnitud - el grado del impacto o de la pérdida puede evaluarse como nulo, mínimo, moderado o principal.
Entre los criterios que podrían utilizarse para evaluar la magnitud potencial se encuentran los siguientes:
(a) impacto público (cantidad de población afectada, pérdidas de vidas, enfermedades, lesiones graves,
evacuación);
(b) económico (efecto PIB, volumen de pérdida económica y/o degradación de productos o servicios);
(c) ambiental (impacto en el lugar y sus alrededores);
(d) interdependencia (con otros elementos de infraestructura críticos).
(e) político (confianza en la capacidad de las administraciones públicas);
Efectos en el tiempo - estos criterios determinan en qué plazo (tiempo) la pérdida de unelemento podría tener
un impacto. En caso de sufrir un ataque, las estructuras críticas, causarían gran impacto en la seguridad, tanto
física como económica del país. Este impacto se mide según unos criterios horizontales que determinan la
ISBN 978-987-23963-1-2 1445

criticidad de una infraestructura. Se han establecido tres: el número potencial de víctimas, el impacto
económico y el impacto público.
En la República Argentina se enuncia que El Programa Nacional de Infraestructuras Críticas de
Información y Ciberseguridad (ICIC) tiene como finalidad impulsar la creación y adopción de un marco
regulatorio específico que propicie la identificación y protección de las infraestructuras estratégicas y críticas
del Sector Público Nacional, los organismos interjurisdiccionales y las organizaciones civiles y del sector
privado que así lo requieran, y la colaboración de los mencionados sectores con miras al desarrollo de
estrategias y estructuras adecuadas para un accionar coordinado hacia la implementación de las pertinentes
tecnologías.
También impulsa una Encuesta Nacional sobre Acceso y Uso de Tecnologías de la Información y la
Comunicación (ENTIC) en Hogares y Personas, que permite contar con información desde la perspectiva de
los usos y accesos de los hogares y de las personas a dichas tecnologías en la Argentina. La ENTIC se
administró a todos los hogares para la Encuesta Anual de Hogares Urbanos (EAHU), cuya estimación se
extiende al total de la población residente en hogares particulares urbanos, en localidades de 2.000 o más
habitantes.
Mediante el Programa Nacional de Infraestructura Crítica de Información y Ciberseguridad (ICIC) e
Internet Sano
- Se promoverá la concientización de la protección de las infraestructuras críticas de información y la
ciberseguridad dentro de las dependencias del Sector Público Nacional, brindando asistencia técnica a los
organismos nacionales, provinciales y municipales que lo requieran.
- Se actualizará la Estrategia Nacional ICIC.
- Se dictarán talleres y charlas técnicas sobre Ciberseguridad.
- Se formularán ejercicios de respuesta a incidentes.
- Se creará la Política de Seguridad de la Información.
- Se generarán nuevos contenidos para concientización de la ciudadanía.
- Se desarrollarán exposiciones y conferencias de concientización.
- Se concertarán alianzas público-privadas para la creación y difusión de contenidos.
Organismo responsable: Subsecretaría de Tecnologías de Gestión. Jefatura de Gabinete de Ministros.
Fecha tentativa: diciembre 2013
IV. Propuesta para implementar en la UNSJ.

La Universidad Nacional de San Juan (U.N.S.J.) ha desarrollado una plataforma tecnológica a través de la
cual se registra, procesa, transmite y almacena información mediante diferentes activos de Información, que
permiten interactuar con la comunidad académica, ciudadanía en general y el personal universitario de todo el
país, y como además se reconoce que la información que posee es un bien estratégico para sus fines, por lo
que se requiere que sea protegida también su obtención, procesamiento, transmisión y almacenamiento.
Considerando que la Resolución 580/2011 crea, el “Programa Nacional De Infraestructuras Criticas De
Información y Ciberseguridad” en el marco de lo establecido la Ley de Ministerios (t.o. Decreto Nº 438/92), a
fin de impulsar la creación y adopción de un marco regulatorio específico que propicie la identificación y
protección de las infraestructuras estratégicas y críticas del Sector Público Nacional, los organismos
interjurisdiccionales y las organizaciones civiles y del sector privado que así lo requieran. Dado que las
universidades nacionales como órganos académicos deberían adherirse a lo previsto por la resolución
580/2011 que se creó, en el ámbito de la Oficina Nacional de Tecnologías de Información de la subsecretaria
de Tecnologías de Gestión de la Secretaria de Gabinete de la Jefatura de Gabinete de Ministros, el “Programa
Nacional De Infraestructuras Criticas De Información y Ciberseguridad” en el marco de lo establecido la Ley
de Ministerios (t.o. Decreto Nº 438/92), se impone para la U.N.S.J. la obligación de establecer una Política de
Seguridad que fije las directrices generales que oriente la materia de seguridad dentro de cada Unidad.
Para ello se crearía un comité que será el responsable máximo del área de Tecnologías Informática y
sistemas. Y que deberá dictar o adecuar sus políticas de seguridad de la Universidad Conformación de
Comités de Seguridad en la Información. Funciones de los mismos y responsabilidades en relación con la
seguridad.
El encargado de seguridad de los activos de información debería establecer un organigrama de
funciones, determinando la cantidad de miembros de la Unidad, cargos y funciones (discriminando quienes
son los administradores de seguridad y/o miembros del comité). Tendría además a su cargo el desarrollo y
actualización de las políticas de seguridad y controlar su implementación, utilizando como referencia las
ISBN 978-987-23963-1-2 1446

Normas IRAM ISO 27.0017 y 270028 y su antecedente 17799) debido a que en base a ellas se definieron los
requisitos para el sistema de gestión de seguridad (SGSI) propuesto.
Para ello sería necesario para ello adoptar las medidas para la protección de la Infraestructuras críticas
donde se fije entre otras cosas, la necesidad de que para esta gestión se fije:
• Un Plan de Seguridad del Operador (PSO)
• Un Plan de Protección Especifico (PPE) para cada una de las infraestructuras que haya sido
identificada como critica por la Secretaria de para la Protección de Infraestructuras Criticas.
El encargado de seguridad debería recoger los contenidos mínimos que deben articular estos planes, y
desarrollar un nuevo documento en el que se describe el modo de abordar la implantación de las medidas y
más tarde reflejarlo en dichos planes.
Se entiende por incidente de seguridad todo incidente que impida el normal funcionam8ento de los
activos de información y que afecte la Seguridad Informática.
La gestión de incidentes de Seguridad tiene por objeto restaurar la operación normal de los sistemas con
tanta rapidez como sea posible y mitigar el impacto adverso a sus procesos, asegurando así que se mantenga
debidamente la confidencialidad, integridad y disponibilidad de la información de la U.N.S.J.
El comité de Seguridad Informática definirá las pautas a seguir en la gestión de incidentes de seguridad,
lo que deberán ser implementados por el Departamento de Sistemas de la U.N.S.J. bajo la coordinación del
encargado de Seguridad de los activos de información.
Además deberá elaborar una Guía aplicativa del sistema de seguridad utilizando como apoyo la Norma
IRAM ISO IEC 27001.
Se propone un sistema de gestión de Incidentes de seguridad porque es la forma en que la Organización
dirige y controla aquellas actividades asociadas a la seguridad. De una manera más amplia debería contar con
dos grandes apartados alineados con la estructura del Plan de Seguridad del Operador (PSO) y del Plan de
protección Específico (PPE):
• Un capítulo dedicado al análisis de riesgos, uno de los aspectos principales de los mencionados
planes.
Dos capítulos dedicados a recoger las medidas de seguridad lógicas y físicas que se deberán:
• Construir y proponer una normativa de seguridad aplicable al entorno local mediante la
• Implementación de un Equipo de Respuesta a Incidentes para la Universidad Nacional de San
Juan.
La Metodología propuesta para el Manejo de Incidentes CSIRT9 – UNSJ, básicamente se ha

estructurado de acuerdo al siguiente esquema:
Cada uno de los pasos propuestos se describe a continuación:
1. Preparación y Protección
La fase de preparación consiste, principalmente, en la implementación de un equipo de Respuesta a
Incidentes de Seguridad Informática (CSIRT), las actividades propuestas, que se deben realizar en esta fase
son:
• Planificación del CSIRT – UNSJ
• Implementación del CSIRT – UNSJ
• Evaluación y funcionamiento del CSIRT
• Lecciones Aprendidas.
A más de definir un proceso de implementación de un equipo de CSIRT, es importante tomar en cuenta la
Protección de la infraestructura de la Universidad para de esta manera asegurar que los sistemas, redes y
aplicaciones tengan un nivel de seguridad adecuado. Las actividades de esta fase se realizan en conjunto con
7 En Argentina es IRAM, como organismo nacional de normalización, quien la estudia a través del Subcomité de
Seguridad de la Información y la adopta como IRAM-ISO/IEC 27001. Se publica bajo el nombre Tecnología de la
información. Sistemas de gestión de la seguridad de la información (SGSI). Requisitos, difundiéndola en la región a
través de cursos y seminarios.
8Aprobada y consensuada por el IRAM (Instituto de Normalización Argentino) en el año 2002
9
Un Equipo de Respuesta ante Emergencias Informáticas (CERT, del inglés Computer Emergency Response Team)
es un centro de respuesta a incidentes de seguridad en tecnologías de la información. Se trata de un grupo de expertos
responsable del desarrollo de medidas preventivas y reactivas ante incidencias de seguridad en los sistemas de
información. Un CERT estudia el estado de seguridad global de redes y ordenadores y proporciona servicios de
respuesta ante incidentes a víctimas de ataques en la red, publica alertas relativas a amenazas y vulnerabilidades y
ofrece información que ayude a mejorar la seguridad de estos sistemas.
ISBN 978-987-23963-1-2 1447

el área de Seguridad, pero básicamente el área de Manejo de incidentes tiene a su cargo la prevención de
ataques, y si estos suceden mitigar el impacto. El área de seguridad realiza actividades de protección, en
cuanto a configuraciones y garantiza la infraestructura informática de la Universidad.
2. Detección de Incidentes de Seguridad
Esta fase está compuesta de varias actividades, tales como: detección de incidentes, análisis inicial y
documentación del incidente y tiene como objetivo la búsqueda de toda posible señal de ocurrencia de un
incidente. Todas las actividades e información generada en esta fase en enviada al proceso de Triage,
haciendo uso de los reportes establecidos.
La Detección de incidentes es un proceso que permite identificar las actividades inusuales que pueden
comprometer la misión del CSIRT, consiste en la detección y evaluación de posibles incidentes, determinar si
un incidente ha ocurrido, y de ser así, el tipo, extensión y magnitud del problema.
Estas actividades se pueden identificar de manera reactiva y proactiva.
Los incidentes se pueden detectar a través de muchos medios tales como: IDS basados en red
(NIDS) y en host (HIDS), software antivirus, software de control de integridad de archivos, sistemas de
monitoreo de red, analizadores de logs, etc.
Los incidentes también pueden ser detectados por medios manuales, tales como reportes de incidentes de
usuarios.
En el proceso de detección están involucrados: Encargado de Seguridad, CSIRT-UNSJ, Gestión de
Servicios TI, Infraestructura de TI, usuarios que han sido víctimas de algún ataque y otras áreas, incluye
los siguientes aspectos:
• Señales de un incidente
• Detección de incidentes mediante la utilización de herramientas
• Detección de incidentes mediante el reporte de terceros.
Señales de un Incidente:
En el proceso de detección, la información sobre potenciales incidentes, vulnerabilidades, información de
seguridad informática o de manejo de incidentes, puede ser obtenida de dos maneras:
• Detección Reactiva
Un incidente puede haber ocurrido o estar ocurriendo en este momento, puede ser detectado de varias
maneras:
• El antivirus detecta que un equipo está contaminado con algún tipo de virus.
• Incidentes en el servidor web
• Envío de alertas y notificaciones por parte de otras organizaciones.
• Detección Proactiva
• Monitoreo de Red
• Escaneo de vulnerabilidades
• Investigación
• Análisis de Riesgos
La detección de incidentes es un proceso que permite saber si el sistema está en peligro o si los servidores
corren el riesgo de detener sus servicios.
Esta actividad va de la mano con la detección proactiva, se debe tomar en cuenta el personal que se
encargue del monitoreo y detección de actividad sospechosa, análisis de logs, uso de software de detección de
intrusos, para cada una de estas actividades se deben tomar en cuenta los procesos establecidos en el Área de
Seguridad para estas actividades.
Todos los datos analizados y los considerados sospechosos se envían al proceso de Triage.
Detección de incidentes mediante el reporte de terceros va de la mano con la detección reactiva, el
usuario notifica del incidente al área de Gestión de Servicios, si el incidente se encuentra en la base de
conocimiento de esta área, es atendido por ellos, caso contrario se envía el reporte del incidente al equipo
CSIRT – UNSJ, en donde, primeramente se verifica que sea un incidente de seguridad.
Los incidentes que se envían al CSIRT-UNSJ y los que se atienden, son los que constan en la
Categorización de incidentes del CSIRT-UNSJ.
• Análisis de Incidentes de Seguridad
En este proceso se busca analizar cada reporte de incidentes presentado, tanto por los usuarios y por los
reportes obtenidos de las herramientas utilizadas, con la finalidad de verificar si realmente se trata de un
incidente de seguridad, o son falsos positivos.
ISBN 978-987-23963-1-2 1448

Se debe recalcar que el equipo CSIRT debe trabajar rápidamente en el análisis y validación de los
incidentes, todas las acciones realizadas deben ser documentadas.
Uno de los mecanismos que sirve de soporte para Detección es la documentación del incidente, se han
definido varios formatos para el reporte y respuesta de incidentes y vulnerabilidades, el uso de reportes ayuda
a:
• Proveer información completa de un incidente al equipo
• Organizar la información recibida
• Priorizar reportes
La información que se solicita en el reporte de incidente es:
• Información de contacto
• Fecha de reporte
• Sistemas afectados
• Descripción del incidente
• Observaciones
A más de los reportes de incidentes, parte de la documentación incluye un documento en el que se detalla
el cómo los usuarios deben realizar el reporte de los incidentes al equipo, etc.
Adicional al reporte de incidente enviado por el usuario, por parte del Equipo CSIRT-UNSJ se debe
enviar un documento de respuesta a incidentes, en el que se detalle la información relativa a la atención y
respuesta del incidente reportado, dependiendo del tipo de incidente, esta información será enviada a
autoridades, y personal que requiera de esta información. (Esta sección, se detalla en la fase de la respuesta a
incidentes).
En cuanto a los recursos humanos, es necesario que el plantel de empleados sea idóneo para la realización
del trabajo de la Organización, pero además debe definir y comunicar sus funciones y responsabilidades.La
misma organización debe establecer las necesidad información y facilitar y evaluar la eficacia de la formación
y de esto debe haber evidencia (Es decir, se exige un registro de capacitación del personal y en lo posible la
formación de una tablero de comando al efecto).
También se debe sensibilizar a toda la organización sobre la importancia de la capacidad humana de la
Organización descansa sobre la formación que da a todos sus empleados. La organización dispone un
potencial que debe ser aprovechado para poder subsistir y este es el potencial humano para ello se debe
implantar los siguientes aspectos motivación, adiestramiento y Comunicación.Implantar en las
infraestructuras críticas para mejorar los niveles de protección integrales.
Se propone crear un CSIRT dentro de la UNSJ, ello es un proceso que involucra un cambio estructural,
organizacional y desde luego requiere de mucho esfuerzo y compromiso a todos los niveles. Sin duda un
CSIRT viene a darle un gran valor a la organización ya que provee un punto de contacto único para afrentar,
resolver y proponer en el campo de las nuevas tecnologías.
La protección del ciberespacio requiere de una organización que sirva de centro nacional decoordinación para
asegurar y proteger el ciberespacio, cuya misión incluye vigilancia, alerta,respuesta y recuperación, con la
colaboración de las entidades gubernamentales en los ámbitosnacional, estatal y local, el sector privado, el
sector académico y la comunidad internacional.
Los principales objetivos que debe cubrir este centro nacional son:
Desarrollar un sistema nacional de seguridad y respuesta ante incidentes cibernéticos paradetectar, prevenir,
responder y recuperarse de incidentes en el ciberespacio.
• Establecer un centro de coordinación para la gestión de incidentes cibernéticos que reúnen los
elementos críticos del gobierno y los elementos esenciales de las infraestructuras de los operadores y
los proveedores para reducir el riesgo y la gravedad de los incidentes.
• Participar en la vigilancia, alerta y mecanismos de intercambio de información.
• Elaborar y probar los planes de respuesta de emergencia, procedimientos y protocolospara asegurar
que los colaboradores gubernamentales y no gubernamentales puedanfomentar la confianza ypuedan
coordinarse de manera eficaz en caso de crisis.
La implementación del CSIRT-UNSJ permitirá:
• Contar con un equipo capacitado para la atención de incidentes brindando servicios
proactivos, reactivos y de aseguramiento de la calidad en temas de seguridad de la información.
• Concientizar a la comunidad universitaria y usuarios finales sobre los riesgos y
beneficios del uso de internet, pero, sobre todo de la importancia de tomar en cuenta las medidas
de seguridad adoptadas en la Universidad.
ISBN 978-987-23963-1-2 1449

Por otra parte como objetivo fundamental el construir y proponer una normativa de seguridad aplicable al
entorno local, la implementación del equipo permitirá compartir la experiencia y resultados obtenidos con
otras universidades.
Los beneficiarios de la implementación de este proyecto serán principalmente la UNSJ y con la
implementación del proyecto:
• Otras Universidades, con la finalidad de profundizar y proponer temas de investigación.
• Organizaciones públicas y privadas que mantienen Equipos de Seguridad.
• Empresas y profesionales que brindan servicios de atención de incidentes.
• Participación efectiva de todos los intervinientes en el proyecto.
Hasta la fecha la participación de los integrantes del equipo se ve reflejada en el cumplimiento de las
actividades, estas se han realizado acorde a lo planificado.
Se ha involucrado a personal de Marketing para la publicidad del CSIRT.
Se han realizado reuniones de Coordinación
Se mantuvieron reuniones con:
• Grupo de seguridad para la presentación de la metodología para el manejo de
incidentes.
• Grupo de Administradores para comunicarles la existencia del CSIRT-UNSJ, uso
de reportes de incidentes y políticas.
Se realizaran actividades de Difusión mediante emisión de boletines con tips de seguridad para usuarios,
los mismos que se emitirán mensualmente. Como estrategia de marketing, durante el primer mes se emitirán
boletines semanalmente, con el objetivo de posicionar el CSIRT-UNSJ en la comunidad universitaria.
• En conjunto con el área de marketing de la UNSJ se está preparando unaestrategia
de comunicación para realizar la difusión del CSIRT-UNSJ, lo que incluye boletines
informativos, notas periodísticas, etc.
• Emisión de un boletín sobre el CSIRT-UNSJ al área de marketing para que sea
difundido a nivel interno en la UNSJ
Finalmente la guía deberá incluir un Anexo dedicado a la protección de los sistemas de monitorización y
control de procesos e infraestructuras, dada su relevancia en este tipo de infraestructuras, así como un
apartado en el que se recogen, de manera exhaustiva, todas las referencias utilizadas.
V. Conclusiones
La seguridad de la infraestructura digital se encuentra expuesta a constantes amenazas, que en caso

de materializarse pueden ocasionar graves incidentes en los sistemas de información y comunicaciones, por lo
que resulta imprescindible adoptar las medidas necesarias para garantizar el adecuado funcionamiento de las
infraestructuras críticas.Los riesgos se han incrementado y sofisticado y hay una demanda de mayor eficacia
que exige nuevas respuestas que requieren tecnología, eficacia y calidad. Eficacia y calidad que deben ser
percibidas por el usuario.
La propuesta para gestión integral de la seguridad de la información diseñada para la protección de

la información de las organizaciones locales, basada en las tendencias, normas de seguridad y estándares
actuales y la creación y adopción de un marco regulatorio que favorecerá la identificación y protección de las
infraestructuras estratégicas y críticas de la U.N.S.J. , promoverá la colaboración entre los distintos sectores y
propiciara el desarrollo de estrategias y estructuras adecuadas para la protección de los activos de información
de las organizaciones locales.
El proyecto de Creación e Implementación de un CSIRT Académico para la Universidad Nacional de

San Juan, tiene como objetivo fundamental, el construir y proponer una normativa de seguridad aplicable al
entorno local, la implementación del equipo permitirá compartir la experiencia y resultados obtenidos con
otras universidades Nacionales con el objetivo de proponer la creación de una red nacional de CSIRTs
académicos y contribuir así a la investigación y desarrollo de metodologías y buenas prácticas que permitan
mejorar la seguridad de las redes.
ISBN 978-987-23963-1-2 1450

Así hemos de concluir en que, sin duda hoy la responsabilidad y respuesta de una única Seguridad
con mayúscula, integral e integrada, pública y privada, es estrictamente necesaria e irreversible.Por todo ello,
para un adecuado presente y futuro hay que integrar el sistema de gestión de la Seguridad Pública y la
Seguridad Privada hacia una nueva visión común y especial cultura de seguridad sobre la base de las
amenazas complejas y la interdependencia e incrementar los recursos de análisis y liberarlos de viejas
patologías y rigideces para desarrollar el esquema de Gestión Integral e Integrada de la Seguridad.
VI.-Referencias
31“Evaluación y Seguridad de un Sistema de Información”, por José Alfredo Jiménez
http://www.monografias.com/trabajos/seguinfo/seguinfo.shtml
32. “Administración segura de la información: Una experiencia de vinculación entre un ente del estado
provincial y la U.N.P.A”. Javier Díaz, L.I.N.T.I. – Universidad Nacional de La Plata
http://www.ing.unp.edu.ar/wicc2007/trabajos/ISBD/066.pdf
33. “Propuesta para un modelo de gestión de documentos electrónicos de archivo en la administración
pública”- documento de trabajo elaborado por Carlos Alberto Zapata y Nelson Javier Pulido para el comité de
gestión de documentos del sistema nacional de archivos
34.http://www.slideshare.net/scarchivistas/propuesta-para-un-modelo-de-gestin-de-documentos-
electrnicos-de-archivo-en-la-administracin-pblica
Gómez Vieites, Álvaro (2007). Enciclopedia de la Seguridad Informática.
3.5Altmark, Daniel Ricardo y Molina Quiroga Eduardo. Tratado de Derecho Informático. Tomo III.
Publicado por la Ley año 2012
ISBN 978-987-23963-1-2 1451

Model Design for a Reduced Variant of a Trivium Type

Stream Cipher
Antonio Castro Lechtaler1, Marcelo Cipriano1, Edith García2, Julio Liporace2, Ariel
Maiorano2, Eduardo Malvacio2,
Escuela Superior Técnica “Gral. Div. Manuel N. Savio”, Facultad de Ingeniería
Instituto de Educación Superior del Ejército Argentino
1
{acastro, marcelocipriano}@iese.edu.ar;
2
{edithxgarcia, jcliporace, maiorano, edumalvacio}@gmail.com
Abstract. We analyze the family of stream ciphers N-viums: Trivium and

Bivium. We present the Trivium algorithm and its variants. In particular, we
study the NLFSRs used in these generators, their feedback functions and their
combination. Two reduced variants of these models are presented, labeled
Toys. Finally, we delve into the open problems ingrained in these
cryptosystems.
Keywords: LFSR, NLSFR, Trivium, Bivium, Trivium-Toy, Bivium-Toy.
1 Introduction
The revolution of communications and technology has taken cryptology from the
military and diplomatic realm into everyday life.
E-mailing, home banking, user authentication in social networks, mobile
communications, and wireless technology have increased the requirements for
confidentiality while data is transferred via insecure channels.
Some ciphering systems meet the requirements to protect data satisfactorily.
However, they do not meet the increasing demand for higher transfer rates.
Because of the resources used and the processing power required, the existing
algorithms lag behind the increasing needs for data transfer security.
Stream ciphers may prove suitable to use in portable devices. Their hardware
adaptability turns them into feasible solutions, responding to the increasing demand
and high transfer rate standards.
1.1 Stream Ciphers.
A perfect cryptosystem entails the capacity for an algorithm to cipher a message

which can be deciphered only by the intended receiver.
ISBN 978-987-23963-1-2 1452

Vernan and Mauborge created such a system in 1917 at the AT&T labs. In their
design, the required key is as long as the length of the message. Both, transmitter and
receiver must have the key which must be destroyed after use. Otherwise, security is
jeopardized.
Because of this feature, the system is known as One-Time-Pad. The key must be
random and is used for both processes: ciphering and deciphering. Hence, users need
to share it at both ends. Cryptosystems under this particular secret key configuration
belong to a class known as symmetric-key algorithms.
In 1949, Shannon demonstrated the invulnerability of this system by satisfying the
requirements for perfect secrecy established by the rising field of Information Theory.
Nonetheless, two weaknesses become apparent, not in the algorithm itself, but in
its application. On one hand, a problem arises in the generation of the secret key; and,
on the other, in the security of key distribution.
A possible solution is to find a deterministic procedure to generate the key. Such a
key would not be random, but pseudorandom, and shall meet additional requirements
to be considered secure.
1.2 LFSRs and Non-LFSRs
Currently, Linear Feedback Shift Registers (LFSRs) are used extensively to generate
pseudorandom sequences with controlled period and linear complexity.
Research on LFSRs began in the 60s [6] and continued through several years. A
significant number of results and applications have been produced: algorithm design,
error control codes, and linear complexity analysis of binary sequences with the
Berlekamp-Massey algorithm [7].
Because of their linearity, LFSRs alone are insecure. It is widely known that, when
2n-1 consecutive bits of an outbound sequence are known, it becomes predictable.
Attempts to add linear complexity by combining LFSRs with, among other things,
nonlinear functions have not met the desired standards yet.
Nonlinear Feedback Shift Registers (NLFSRs), a generalization of their linear
counterparts, have been relegated for a long time. While LFSR theory is robust and
well understood, many fundamental problems with NLFSRs remain unanswered.
One such problem is the determination of the period of outbound sequences in
NLFSRs. In recent years, research has focused on nonlinear registers and stream
ciphers using NLFSRs in some form. This is the case for the class TRIVIUM [1][2],
BIVIUM [10].
Our research focuses in the development of a new family of the TRIVIUM-
BIVIUM stream cipher class, designated as Toys.
In our Toys, in which the sizes of the NLFSRs are reduced significantly, we have
modified their taps while maintaining the original design principles.
With these models, observation in a constrained environment may foster more
realistic research projects, as well as allow researchers to compare results within
smaller samples and to conduct tests in a reduced space.
In the future, the Toy family may help contribute in the development of a solid
algebra involving NLFSRs, in particular for generators of the TRIVIUM-BIVIUM
class.
ISBN 978-987-23963-1-2 1453

2. FSR Overview
An n-bit feedback shift register (FSR) is an n-bit length register with a feedback
function:
f:{0,1}n →{0,1} (1)
where the feedback bit (at the tap positions of the register) or the output bit is of the
form:
xn+t = f(xn-1+t,xn-2+t ,…….xt) (t≥0) (2)
For each step t, the register bits shift one position to the right and the taps are fed
into the function and become the bit input for the following step. The n bits of the
register constitute the state of the register at step t. The initial state is defined when
t=0. The period of a FSR is the length of the largest cycle generated by the output
sequence of the register.
If the feedback function is linear, i.e.:
f(xn-1,xn-2 ,…….x0) = c0x0 + c1x1 + c2x2 +………+ cn-1xn-1 (ci ∈ {0,1}) (3)
we say that the registry is an LFSR (Linear Feedback Shift Register). Otherwise,
with a nonlinear feedback function, we have a NLFSR (Nonlinear Feedback Shift
Register).
Fig.1: n-bit FSR Structure.

In the LFSR case, when the coefficients ci belong to a primitive polynomial, the
LFSR output sequence has a maximum length of 2n-1, regardless of the chosen initial
(non-trivial) state. The LFSR output sequences of maximum length are called
maximal sequences or m-sequences [6]. If 2n-1 output bits of an n-length LFSR are
known, then the sequence becomes predictable using the Berlekamp-Massey
algorithm [10].
NLFSRs are more robust to algebraic attacks. However, no systematic and efficient
method is known to construct secure NLFSRs [3][4]. Furthermore, for a given
nonlinear feedback function, it is difficult to predict the period of the output sequence.
A stream cipher is a symmetric ciphering system which takes a sequence of
plaintext and a secret key, and operates on the plaintext, generally bit by bit with the
key bit stream, generated by the secret key and the algorithm.
ISBN 978-987-23963-1-2 1454

Fig.2 Stream Cipher Example
The key bit stream must meet certain cryptologic security conditions, i.e.: the
length of the sequence and the linear complexity must be sufficiently large, and the
binary sequence must satisfy a series of pseudo-random tests [6].
3. Trivium and Bivium
The stream algorithm TRIVIUM was designed by Christophe De Cannière and Bart
Preneel. It was selected as a finalist algorithm in the e-STREAM Project [5]. It was
designed to generate at least 264 bits with the use of an 80-bit secret key and an
initialization vector (IV) of also 80 bits.
Fig.3: Trivium algorithm
It consists of three combined NLFSRs. The first register controls the second, the
second controls the third, and this last register controls the first.
Fig.4: Trivium-Like Structure

The core idea behind the design focuses on using the principles of block cipher
construction in order to create equivalent components in stream ciphers.
ISBN 978-987-23963-1-2 1455

The output consists of three combined non-linear shift registers of length 93, 84,
and 111, and where specific positions are selected to obtain a key bit stream. Whereas
no efficient attack has been encountered to break this generator so far [8][9], its
period remains undetermined and an open research problem.
A complete description is given by the following simple pseudo-code:
INPUT: s0, s1,…,s287 initial state, integer n, si ∈{0,1}.
OUTPUT: binary sequence {kt}
1. Initialization
t1 ← s65 ⊕ s92
t2 ← s161 ⊕ s176
t3 ← s242 ⊕ s287
2. While ( t<n ) do the following:
2.1 kt ← t1 ⊕ t2 ⊕ t3
2.2 t1 ← t1 ⊕ s90 ⊗ s91 ⊕ s170
t2 ← t2 ⊕ s174 ⊗s175 ⊕ s263
t3 ← t3 ⊕ s285 ⊗s286 ⊕ s68
2.3 (s0, s1,…,s92) ← (t3, s0,…,s91)
(s93, s94,…,s176) ← (t1, s93,…,s175)
(s177, s178,…,s287) ← (t2, s177,…,s285)
3. Return {kt}
Note that ⊕ is the XOR operation and ⊗ the AND operation.
BIVIUM was designed by Hårvard Raddum to obtain a reduced sized version of

TRIVIUM. It consists of two combined NLFSRs (while TRIVIUM has three) of
lengths 93 and 84.
Despite the improved security under specific attacks granted by this model, the
results are not entirely satisfactory.
4. The Toy Model
We present reduced variants of TRIVIUM and BIVIUM algorithms as a strategy to

tackle the open problems discussed and the mathematical theory behind the behavior
of NLFSRs. The reduced models (decimated by 3) are based on previous work by
Yun Tian et al, who developed an extended model of the TRIVIUM structure [11].
We have named these models Toys, considering they are miniatures of the originals.
It is noted that every reduction of a model focuses on a quest for simplicity in its
mathematical study and it is not meant to be used in operative information security
environments.
ISBN 978-987-23963-1-2 1456

We assume the following:

A1) Property invariance after size reduction: the reduced size structure of the models
maintains the mathematical properties of the original model.
A2) Computational complexity reduction: The reduction in size contributes to a
reduction of the problem, making the model more manageable under computational as
well as algebraic considerations.
A3) Property invariance after size increase: In the case of identified patterns in the
behavior and mathematical properties in the reduced model, they may be extrapolated
to the original model.
These assumptions need to hold throughout the entire research. In case one of them
does not hold or inconsistences among them are encountered, the procedure presented
here ought to be revised.
4.1. Trivium-Toy
The model consists of three NLFSRs X, Y, and Z of lengths 31, 28 and 37 with the
following states:
X(31): X0, X1,…………,X30
Y(28): Y0,Y1,………….,Y27 (4)
Z(37): Z0, Z1,………….,Z36
Being the feedback of each register, i.e. the bit input in each:
X0: Z21 ⊕ Z36 ⊕ Z35 ⊗ Z34 ⊕ X22

Y0: X21 ⊕ X30 ⊕ X29 ⊗ X28 ⊕ Y25 (5)
Z0 : Y22 ⊕ Y27 ⊕ Y26 ⊗ Y25 ⊕ Z28
and the key bit stream:

Kt:X21 ⊕ X30 ⊕ Y22 ⊕ Y27 ⊕ Z21 ⊕ Z36 (6)
Also, the cipher of the plaintext with the key bit stream is:
Ct = P t ⊕ K t (7)
Fig.5 Trivium vs Trivium Toy
ISBN 978-987-23963-1-2 1457

Pseudo-code of the Trivium is changed to a reduced form as follows:
INPUT: s0, s1,…,s95 initial state, integer n, si ∈ {0,1}.

1. Initialization.
t1 ← s21 ⊕ s30
t2 ← s53 ⊕ s58
t3 ← s80 ⊕ s95
2.1 kt ← t1⊕ t2 ⊕ t3
2.2 t1 ← t1 ⊕ s28 ⊗ s29 ⊕ s55

t2 ← t2 ⊕ s56 ⊗ s57 ⊕ s87
t3 ← t3 ⊕ s93 ⊗ s94 ⊕ s22
2.3 (s0, s1,…,s30) ← (t3, s0,…,s29)

(s31, s32,…,s58) ← (t1, s31,…,s57)
(s59, s60,…,s95) ← (t2, s59,…,s94)
3. Return {kt}
4.2. Bivium-Toy
The model consists of two NLFSRs X, and Y of lengths 31 and 28 respectively with
the following states:
X(31): X0, X1,…………,X30
(8)
Y(28): Y0, Y1,…………,Y27
Being the feedback of each register:
X0: Y22 ⊕ Y27 ⊕ Y26 ⊗Y25 ⊕ X22

(9)
Y0: X21 ⊕ X30 ⊕ X29 ⊗X28 ⊕ Y25
and the key bit stream:
Kt: X21 ⊕ X30 ⊕ Y22 ⊕ Y27 (10)
The cipher process is the same as detailed in formula (7).

Pseudo-code of this reduced cipher is given below:
INPUT: s0, s1,…,s58 initial state, integer n., si ∈ {0,1}.

ISBN 978-987-23963-1-2 1458

1. Initialization.
t1 ← s21 ⊕ s30
t2 ← s53 ⊕ s58
2.1 kt ← t1⊕ t2
2.2 t1 ← t1 ⊕ s28 ⊗ s29 ⊕ s55

t2 ← t2 ⊕ s56 ⊗ s57 ⊕ s22
2.3 (s0, s1,…,s30) ← (t2, s0,…,s29)

(s31, s32,…,s58) ← (t1, s31,…,s57)
3. Return {kt}
5. Conclusions
In this article we present the class of Trivium-Bivium random sequence generators

using non-linear shift registers (NLFSR).
Because of their size, several research problems remain unanswered: patterns of
behavior, algebraic properties, period lengths, and weak keys among others.
Under this framework, we present reduced sized variants of these generators for
research and applications in cryptology, laying out the formulae of the feedback
functions as well as the key bit streams. We assume that the properties identified in
the reduced sized models would remain invariant in the original ones.
6. Further research.
The Toy family may foster additional research in the following areas:
- Search for length of the period or cycles.
- Distribution of taps and their changes to determine algebraic properties and
personalization of N-viums.
- Algebraic analysis of the non-linear functions used in the models.
- Search for possible weak keys.
7. Acknowledgements
The financial support provided by Agencia Nacional para la Promoción Científica y

Tecnológica (Project PICTO 11- PICTO 11-18621) is gratefully acknowledged.
ISBN 978-987-23963-1-2 1459

8. References
1. De Canniére, C. and Preneel, B. “TRIVIUM A Stream Cipher Construction Inspired

by Block Cipher Design Principles”. In Workshop on Stream Ciphers Revisited,
(2006).
2. De Canniére, C. and Preneel, B. “TRIVIUM Specifications”. eSTREAM, ECRYPT
Stream Cipher Project, Report. (2008).
3. Dubrova, E. “A List of Maximum-Period NLFSRs”, Cryptology ePrint Archive,
Report 2012/166, March 2012, http://eprint.iacr.org/2012/166
4. Dubrova, E. “A scalable method for constructing Galois NLFSRs with period 2n −1
using cross-join pairs”. Technical Report 2011/632, Cryptology ePrint Archive,
November 2011. http://eprint.iacr.org/2011/632.
5. eSTREAM: eSTREAM – The ECRYPT Stream Cipher Project:
http://www.ecrypt.eu.org/stream/
6. Golomb. “Shift Register Sequences”. Aegean Park Press (1982).
7. Massey, J.L. “Shift-register synthesis and BCH decoding”. IEEE Transactions on
Information Theory 15 (1969).
8. Maximov, A. and Biryukov, A. “Two Trivial Attacks on Trivium”, Selected Areas
in Cryptography, Lecture Notes in Computer Science, Vol.4876, Springer, 2007.
9. McDonald, C. and Pieprzyk, C. “Attacking Bivium with MiniSat”, Cryptology
ePrint Archive,Report 2007/040 (2007).
10. Raddum, H.“Cryptanalytic Results on Trivium”, eSTREAM, ECRYPT Stream
Cipher Project, Report 2006/039 (2006).
11. Yun Tian, Gongliang Chen, Jianhua Li: “On the Design of Trivium”. IACR
Cryptology ePrint Archive (2009).
ISBN 978-987-23963-1-2 1460

Usability Support Security Patterns
Susana Romaniz1, Marta Castellaro1, Juan Carlos Ramos1, Ignacio Ramos1

1
Facultad Regional Santa Fe - Universidad Tecnológica Nacional,
Lavaise 610 (S3004EWB) Santa Fe Argentina
{sromaniz, mcastell, jramos, iramos}@frsf.utn.edu.ar
Abstract. The main feature of secure software lies in the nature of processes and
practices used to specify, design, develop and implement software. Security
patterns applied the concept of pattern in the security realm. Its description helps
to capture immediately the essence: what is the problem to which attends and
what the proposed solution is. The different formats that exist for its description
and the multiplicity of sources make its discovery demand effort that discourages
the systematic use by potential recipients. This paper presents the prototype of a
catalogue that seeks to establish a bridge between the knowledge and experience
security experts and the needs of knowledge of software development teams.
Keywords: Security patterns. Security intelligence. Security patterns catalogue.
1 Security in the software development process
The main feature of secure software lies in the nature of the processes and practices
used to specify, design, develop and deploy the software [1]. A project that adopts an
improved security software development process incorporates a set of practices that
reduce the number of exploitable flaws and bugs. Over time, these practices become
more systematic, so it should decrease the likelihood that such vulnerabilities are
present in the software at the moment that releases. The results in the field of research
and experiences in the industry indicate the importance of reducing such potential
vulnerabilities as early as possible within the software development lifecycle. The
adoption of improved security processes and practices is much more profitable than the
solution widespread today to develop and release patches for the operating software [2].
This early attention of the security has to do with the adoption of a set of activities
that make possible the security integration in the software development lifecycle [3],
including [4]: 1) identify security objectives, 2) apply security design guidelines, 3)
create threat models, 4) conduct security architecture and design reviews, 5) complete
implementation security reviews, and 6) run deployment security reviews.
We note the active development of tools and methods for testing that allows assessing
the robustness and resilience of software products and their underlying infrastructure
under attack conditions (for example, those used in penetration testing). Namely, there is
intelligence domain of attacks that exploit vulnerabilities and compromise the security of
software-intensive systems. All this produces a complex deal scenario.
There are criteria that help to secure software production [5]:
ISBN 978-987-23963-1-2 1461

 Keep in mind that the security and cost of production of a software system
depends strongly on the knowledge about its requirements [6].
 Include security treatment in each of the different stages of the software development
cycle is an accepted criterion for improving the security of the final product. [7]
 Incorporate security patterns, which represent the best practices achieved by the
industry in order to stop or limit security attacks [8].
In the secure software development process’ case, security patterns are a way to
bridge the gap between theory and practice. Although there are theoretical
approaches, they are limited to relatively complex systems, and require a grade of
knowledge and experience that is not available at the necessary level.
Then, we may infer that promote the use of security patterns to guide and drive the
building of secure software development models, from the early stages of the process,
is an approach that will allow us to ensure greater security in the behavior of a
software product.
2 Security Patterns
The concept of “pattern” is known by the community as a solution to common

problems in software development, whose effectiveness has been verified by solving
similar problems in the past and that is reusable (applicable to different design
problems in various circumstances). In the case of the security software aspects,
which are found throughout all phases of development, its original definition [9]
states that: “Each pattern is a three-part rule, expressed as a relation between a
certain context, a certain system of forces that occur repeatedly in this context, and a
certain software settings that allows these forces to resolve themselves.”
Extending the concept to software security, security patterns documented well
known solutions to recurring problems of information security, allowing an efficient
transfer of experience and knowledge. They apply the pattern concept to the realm of
security, describing a particular recurrent security problem occurring in a specific
context and presenting a well-proven generic solution accepted by the community of
experts [10]. To make explicit the assumptions under which apply their solutions are
applicable, reduce the risk of inappropriate use.
The solution proposed by a security pattern consists of a set of interacting roles that
can be organized in multiple structures (applicable to the phases of requirements analysis,
design, coding, testing or implementation, as appropriate pattern) concrete, as well as a
process to create a particular structure in these [8]. According to what is expressed in [11]
“a pattern defines a process and a thing: the ‘thing’ is created by the ‘process’.” Security
patterns can be categorized according to a point of view associated with a software
development lifecycle [12]. In this way there are patterns to the requirement phase,
patterns to the design phase and patterns for the implementation phase. In general terms,
guide the analysis through the context of security patterns allows integrate the problem
addressed and the forces present that determine the problem.
Specifically, highlights the following advantages in the use of an approach to the use
of patterns in security treatment: (i) express the basics security in a structured and
understandable way; (ii) its representation is familiar to software developers and system
ISBN 978-987-23963-1-2 1462

engineers, a key part of their audience; (iii) the patterns already are used to capture the
knowledge about the system and the organization, then using the patterns to capture
security knowledge help to improve security in the systems lifecycles, where results
clearly needed. In particular regard to its development, in the last years different security
groups have been specifying different patterns, as well as have made efforts for
classification purposes [13, 14].
2.1 Security patterns description
Often refers to the model POSA (Pattern-Oriented Software Architecture) model

developed by Buchman and others [15] to describe the context and the use of security
patterns. But you can also see the existence of different descriptive models [16]; even,
in many cases they are described so that the model is no strictly respected. These are
discussed in detail in [17]. With regard on the format adopted for the description of
security patterns, in general, it adopts the definition of a template, which contains a
series of named elements and a defined scope. A good description will help to capture
immediately the essence of a pattern, i.e., what is the problem to which attends and what
is the proposed solution. It also offers all the details necessary to implement it and
consider the consequences of its application.
It is important to note that not all fields are required. For example, in the case of
some patterns is difficult or unnecessary to provide detailed descriptions of their
structure, behavior and the implementation, because the information can be well
integrated in the description of the solution. Likewise, in [18, 19] have defined other
formats for the description of security patterns, also based on templates defined as
sets of named elements and associated scope. A preliminary analysis of the different
types of templates shows that there is not an exact match between the elements and
scope, although all of them captured approximately the same aspects of security
pattern to describe it. In [17] presented the results obtained with respect the variability
of the aspects used for the formal definition of security patterns, which were obtained
from a in-depth review of 364 security patterns collected from different sources,
which were published during the years 1997-2012. These review also allowed us to
see very high heterogeneity on the way of naming the aspects and there are no criteria
of correspondence between the different names, such as exits between the
descriptions of GoF and POSA [20].
2.2 Corporate and community knowledge compilation
But already there is no denying the need to address the problem of security products and
services based on software, responsible for projects still face serious difficulties in
addressing effectively the priorities identified in terms of security. What is the cause of
this discrepancy? We cannot say that only due to ignorance about the existence of
attackers who manage to exploit vulnerabilities in software. In fact, we can observe a
significant disconnect between security experts and software development teams; the
first are focused on the security of a system, while the seconds in building a system. For
the latter, security is one of the non-functional goals with relevant, but just one of many.
ISBN 978-987-23963-1-2 1463

Security patterns constitute a technology adopted for the description, communication

and knowledge sharing, and proposed as a bridge that seeks to reduce this gap by
capturing security expertise in the form of verified solutions to recurring problems. It is
expected that they will be understood and used by the different members of
development teams that are not security experts. Since the emphasis is on security, these
patterns capture the strengths and weaknesses of different approaches in order to allow
development teams to make informed decisions that balance security with other
objectives.
We must emphasize that in this paper we have adopted the intelligence concept to
refer to the set of practices that give rise to a collection of corporate knowledge, which
is used to carry out proactive software security activities across the organization.
We decided to work in the organization and accessibility of that intelligence,
seeking to generate a proposal for cataloguing security patterns. So we have
considered the possibility of having resources that allow you to access a repository
where reference to the set of defined security patterns in a systematic way of special
importance. In this way, we hope to put at the disposal of the different actors involved
in the software development process (project leaders, architects, designers, QA
managers, programmers, testers) this knowledge drawn from the real world on the
basis of the experience of specialists in security.
2.3 Cataloguing security patterns
At present, a multiplicity of sources exists where there are available different groups
of security patterns defined throughout the time. This does that its discovery demands
a level of effort that, normally, discourages to whom they are destinated to make use
of them in systematic form. A centralized catalogue is a tool that acts as a starting
point for the search and identification of one or more solutions to a security problem
that is intended to resolve, expressed through security patterns. In this way it seeks to
establish a bridge between the intelligence developed by security experts and the
needs of knowledge of the software development teams.
To do this, we define as main requirement that the information offered by the
catalogue be appropriate to “find” the security pattern. This information is extracted or
inferred from the description of the pattern itself, and includes extensions that facilitate
the categorization of the pattern according to established criteria. In the current design
of the catalogue we adopted two criteria: (1) the security attributes impacted by the
problem described; (2) the software development process phase to which applies the
pattern. In this way, we hope that the information related with security patterns
presented via the catalogue helps to capture immediately the essential aspects of them.
3 Proposal for cataloguing and its contribution
Our problem then is to define a way of structuring and indexing a catalogue of security
patterns, so it could result quite easy to find a pattern that proposes a solution to an
identified security situation, and from there access to the complete original reference of
ISBN 978-987-23963-1-2 1464

the security pattern description. We define the set of attributes shown in Table 1 as the
common attributes of security patterns that allow finding their references.
Table 1. Attributes for describing security patterns.
Nombre Name of the original definition security pattern.

Objetivo Problem that the security pattern meets. It is a response to a security problema.
Clasificación Based on the phase of the software development process in which normally the
pattern applies: requirements, analysis, design, coding, testing, implementation.
Aspecto seguridad Confidentiality, integrity, availability, accountability, non-repudiation
afectado
Keyworkds They serve as a complementary reference to the security pattern.
Referencias Links towards the documents and/or web pages where one finds the detailed
description of the pattern.
Except for the ‘Nombre’ attribute, for the remaining attributes is necessary to make
an analysis of the security pattern description in its original source, extract the attributes
concepts associated with the selected attributes and perform the cataloguing of the
security pattern. With respect to this concepts extraction process during the review of a
security pattern, we found a guide in [17]; this paper summarized the results about the
quality of the information included in the aspects that describe a security pattern, as well
as the frequency of use of these aspects used along 67 publications of security patterns.
In this regard, we can highlight the following as a guide to the extraction process:
 Solution (present in 87% of publications), is used to describe what security
aspects attends the pattern and how it could be implemented;
 Problem (present in 84% of publications), in many cases includes abstract or
oversimplified description of the problem;
 Related Patterns and Consequences (present in 75% of publications), require a
good understanding of other security patterns as potential impact in the field of
security so that they can be used as elements of distinction.
 Context (present in 49% of publications) generally includes a brief description,
which makes it difficult to extract sufficient knowledge or even an idea about
what the security pattern;
 Known Use (present in 46% of publications), described in what real-life cases
you can use the pattern and provides guidance on its application domain.
4 Cataloguing process and prototype
Here by means of an example, the description of the process of incorporation of a

security pattern to our catalogue. The selected pattern is called Authenticated Session
[21], which is summarized in Figure 1. This process consists in the reading and
analysis of the description security pattern conducted by a security expert, and in
obtaining the data shown in Table 2, which result from the following references (the
latter depends on the particular format adopted by the authors for the description of
the security pattern and the quality of associated information): i) Objetivo: it is
inferred from the Abstract section of the description; ii) Clasificación: the security
expert who performs the reading and analysis of the security pattern inferred that the
ISBN 978-987-23963-1-2 1465

Authenticated Session
(a.k.a. Server-Side Cookies, Single Sign-On)
Abstract
An authenticated session allows a Web user to access multiple access-restricted pages on a Web site
without having to re-authenticate on every page request. Most Web application development environments
provide basic session mechanisms. This pattern incorporates user authentication into the basic session model.
Problem
HTTP is a stateless, transaction-oriented protocol. Every page request is a separate atomic transaction with
the Web server. But most interesting Web applications require some sort of session model, in which multiple
user page requests are combined into an interactive experience. As a result, most Web application
environments offer basic session semantics built atop the HTTP protocol. And the protocol itself has evolved
to provide mechanisms -such as basic authentication and cookies- that allow session models to operate
correctly across different Web browsers. An obvious use for session semantics is to allow users to authenticate
themselves once instead of every time they access a restricted page. However, great care must be taken when
using session semantics in a trusted fashion. Most session mechanisms are perfectly adequate for tracking non-
critical data and implementing innocuous transactions. In such cases, if an end user circumvents the session
mechanism, no harm is caused. But it is easy to make mistakes when applying session mechanisms to
situations where accountability, integrity, and privacy are critical.
Solution
An authenticated session keeps track of a user’s authenticated identity through the duration of a Web
session. It allows a Web user to access multiple protected pages on the Web site without having to re-
authenticate him/her-self on every page request. It keeps track of the last page access time and causes the
session to expire after a predetermined period of inactivity. …..
Examples
Many significant Web banking and e-commerce applications rely on this pattern. Any site that enforces
user authentication and does not store that information on the client uses something similar. ….
Related Patterns
· Network Address Blacklist – a related pattern that demonstrates a procedure for blocking a network
address from further access attempts if a session identifier guessing attack is conducted.
· Password Authentication – a related pattern that presents the secure management of passwords, which are
almost always used as the authentication mechanism for this pattern.
References
[1] Coggeshall, J. “Session Authentication”.
http://www.zend.com/zend/spotlight/sessionauth7may.php, May 2001.
[2] Cunningham, C. “Session Management and Authentication with PHPLIB”.
http://www.phpbuilder.com/columns/chad19990414.php3?page=2, April 1999.
[3] Kärkkäinen, S. “Session Management”. Unix Web Application Architectures.
http://webapparch.sourceforge.net/#23, October 2000.
Figure 1. Selected security pattern to cataloguing: Authenticated Session [21].
Table 2. Data for cataloguing the security pattern selected.
Nombre Authenticated Session

Objetivo Allow the access to multiple pages with restricted access, without having
to re-authenticate again and again.
Keep authentication information in the system’s navigation
Clasificación Design
Aspecto de seguridad afectado Accountability, Integrity.
Keywords Authentication, Single Sign-On
Referencias  Security Patterns Repository v1.0.pdf
 Cunningham, C. “Session Management and Authentication with
PHPLIB”. http://www.phpbuilder.com/columns/chad19990414.php3,
(Rev. Mayo 2013).
 Kärkkäinen, S. “Session Management”. Unix Web Application
Architectures. http://webapparch.sourceforge.net/#23, October 2000.
(Rev. Mayo 2013)
ISBN 978-987-23963-1-2 1466

same applies to the design phase, in the aspect of ‘user authentication’; iii) Aspecto de
seguridad afectado: in the final paragraph of section description Problem refers to
“But it is easy to make mistakes when applying session mechanisms to situations
where accountability, integrity, and privacy are critical”, accordingly, the security
pattern seeks to address these shortcomings; iv) Keywords: inferred from Name and
Know-As-As sections; v) Referencias: from the references listed in the References
section, selecting those sources whose availability at the time of cataloguing can be
verified. Obtained these data, we proceed to cataloguing the security pattern selected
for example, using the prototype that we describe in the following section.
To realize this proposal, we analyzed extended use alternative tools that allow us to
its implementation. We define build a prototype using a tool for management of
bibliographic references: ‘JabRef’. This is a very low-cost alternative to test the idea
which, if it actually works, can then be extended to massive tools, as for example a
web application with features ‘wiki’.
JabRef is configurable bibliographic reference management software. It use native
format BibTex (a text-based and independent of the style file format) to define lists of
bibliographic items, articles, thesis, etc. For the generation of the proposed catalogue
we take advantage of this facility for recording references in this manager; in addition,
the existence of distinct and specific attributes in each pattern allows us to generate a
special entry type (Security Pattern type) with their respective fields and general and/or
optional information. Another important feature of JabRef is the use of LaTeX, which
allows us to transfer automatically and without major difficulties (given the use of well-
defined parameters) the current catalogue to any other type of software that allows the
entry of the same language: databases, Wikipedia pages, another specific or general
purpose manager, etc. Figure 2 shows a screen from the JabRef interface, where:
 Groups (section 1). Created groups that correspond to the phases of software
development in which the pattern is normally applicable. Selecting a group in
section 2 (Entry) will appear the patterns that correspond to that classification.
 Entry (section 2). Entries loaded at the base are presented as a table with the
fields as columns, which can be used to select a criterion of order by pressing the
desired column. You can see all the references or related files by right clicking
1 2
3 4
Figure 2. JabRef Catalogue Interface.
ISBN 978-987-23963-1-2 1467

on the desired row in the column ‘File’ (second column), folding a list of values.
If you select one of these, will go to the required reference, whether a document
available locally or on the Internet.
 Search (section 3). It allows to search according to an attribute and filters inside the
entire catalogue. After a search and already showing the selected patterns that
contain the phrase or word searched, when you double-click on them and
navigating through the different tabs of the query, words appear highlighted in blue.
 Preview (Section 4). It shows the information of the security pattern selected in
PDF format, which is a friendly representation of the contents of the pattern by
default. By pressing the right mouse button you can print preview.
This figure shows the way how catalogued information relating to the
Authenticated Session pattern [21] is displayed, where there are the attributes
proposed to categorize a security pattern.
Cataloguing a security pattern: Figure 3 shows some of the facilities offered by the
developed prototype to incorporate information from the attributes listed in Table 2:
Figure 3.a): Loading the ‘Required Fields’ (mandatory): name, objective,
classification, security issues, key words and Bibtexkey (a peculiarity of JabRef and
a) Required Fields.
b) Optional Fields.
ISBN 978-987-23963-1-2 1468

c) Loading
‘Keywords’ and
‘Referencias’.
Figure 3 Interfaces for loading data for cataloguing attributes Authenticated Session security pattern.
bibtex references, which is used for references to the security pattern); Figure 3b)
Information is supplemented with related patterns and other well-known names (in
both cases, if any); Figure 3.c): Defining ‘Keywords’ and ‘Referencias’ for the
security pattern, taking advantage of the JabRef’s facility for linking local and
external files as ‘Files’.
Searching a security pattern in the catalogue: Figure 4 shows the result of a search
for references to security patterns applicable to the design phase and that attend to the
confidentiality as a security attribute.
Figure. 4. Results of a search in the security pattern catalogue.
5 Conclusions and Future Work
This proposal aims to provide to the security community these quick references, and
go replenishing it as it’s used. The tool chosen to build a catalogue of references
ISBN 978-987-23963-1-2 1469

helps us to test in a simple way, and eventually modify, the proposed structure and
criteria, and consider the possibility of replace with another with higher performance
and style. This prototype allows us to define the bases to make an extension to a
wiki-style web tool, which will be available to the whole community, and also to be
updated by it. In addition to the web tool, it will be necessary to propose and publish
criteria to incorporate new references to our catalogue, so that all entries follow these
agreed common criteria. This is the work that we intend to address in a next phase.
References
1. McGraw, G., “Software Security: Building Security In.” Addison-Wedsley. EEUU. (2006).
2. Romaniz, S., “Buenas prácticas de elicitación de los requerimientos de seguridad”. IV Congreso
Iberoamericano de Seguridad Informática -CIBSI2007-, Argentina (2007).
3. Meier, J. et al., “Security engineering explained.” (2005). Available in
http://www.microsoft.com/download/en/confirmation.aspx?id=20528.
4. Castellaro, M. y otros, “Hacia la Ingeniería de Software Seguro.” XV Congreso Argentino de
Ciencias de la Computación, CACIC2009. Argentina. (2009).
5. Solinas, M., “Elicitación y trazabilidad de requerimientos utilizando patrones de seguridad.”
Universidad Nacional de La Plata. Argentina. (2012). Available in
http://sedici.unlp.edu.ar/bitstream/handle/10915/421/Documento_completo.pdf?sequence=1.
6. Garvin, D., “What does product quality really mean?” Sloan Management Review, Vol 26, No
1. (1984).
7. Romaniz, S. y otros, “La seguridad como aspecto organizacional y transversal en proyectos de
Sistemas de Información.” 38 Jornadas Argentinas de Informática 38JAIIO. Argentina. (2009).
8. Schumacher, M. et al., “Security Patterns: Integrating Security and Systems Engineering.” John
Willey & Sons Inc. EEEUU. (2006).
9. Coplien, J.: “Design Pattern Definition - Software Patterns.” Available in
http://www.hillside.net/component/content/article/50-patterns/222-design-pattern-definition.
10. Schumacher, M.: “Security engineering with patterns-origins, theoretical model, and new
applications.” Springer-Verlag. (2003).
11. Alexander, C.: “The Timeless Way of Building.” Oxford University Press. EEUU. (1979).
12. Yoshioka, N. et al.: “A survey on security patterns.” Progress in Informatics. (2008).
13. Fernandez, E. et al. “Classifying Security Patterns.” Progress in WWW Research and
Development Volume 4976. (2008).
14. Washizaki, H. et al. “Improving the Classification of Security Patterns.” 20th International
Workshop on Database and Expert Systems Application, DEXA’09. Austria. (2009).
15. Buschmann, F. et al. “Pattern-Oriented Software Architecture: A System of Patterns.”
Chichester, UK: Wiley, 1996.
16. Schumacher, M. et al., “Security engineering with patterns.” Proceedings of the Conference on
Pattern Languages of Programs, pp. 1–17. (2001).
17. Bunke, M. et al. “Organizating Security Patterns Related to Security and Pattern Recognition
Requirements.” International Journal on Advances in Security, vol 5 no 1 & 2 (2012).
18. Kienzle, D.: “Security Patterns Template and Tutorial version 1.0.” (2008). Available in
http://www.scrypt.net/~celer/securitypatterns/template%20and%20tutorial.pdf
19. Blakley, B. et al. “Security Design Patterns.” The Open Group. (2004). Available in
https://www2.opengroup.org/ogsys/catalog/g031.
20. Henninger, V. et al. “Software pattern communities: Current practices and challenges.”
Proceedings of the Conference on Pattern Languages of Programs PLOP. New York, NY, USA.
ACM, 2007, pp. 14:1–14:19.
21. Darrell M. Kienzle et al. "Security Patterns Repository Version 1.0.” Available in
http://www.scrypt.net/~celer/securitypatterns/repository.pdf
ISBN 978-987-23963-1-2 1470

Analizador de Intents en Android
Joaquı́n Erario, Christian Rovera, Francisco Bavera

Departamento de Computaci on
Universidad Nacional de Ro Cuarto
R
o Cuarto, Argentina
pancho@dc.exa.unrc.edu.ar
Resumen Existen numerosos reportes de vulnerabilidades detectadas

en el sistema operativo Android. Si bien muchas de estas vulnerabilida-
des fueron solucionadas apidamente,
r se detect
o una, que hasta la fecha,
no ha sido solucionada: vulnerabilidades por el uso de \Intent" expl citos.
Un \Intent" explcito es un m etodo que puede ser utilizado en aplicacio-
nes Android para invocar desde una aplicaci on a otra aplicaci
on o ser-
vicio determinado expl citamente. Esta invocacion puede incluir el paso
de alg
un tipo de informaci on (posiblemente sensible o condencial). Esta
forma de invocar Intents puede ocasionar una vulnerabilidad, ya que, la
aplicaci
on o servicio que se invoca puede ser modicada (de forma ma-
liciosa o no) y esta modicaci on puede permitir manipular de manera
indeseada la informaci on recibida. Por ejemplo, una aplicacion que env a
un intent que agregue un contacto de la agenda o un mensaje para pu-
blicar en una red social y la aplicaci on de destino no es la esperada se
puede ltrar informacion sensible o condencial sin el consentimiento del
usuario. En este trabajo se presenta una herramienta para garantizar que
esta vulnerabilidad no pueda ser explotada. El enfoque utilizado segue
los lineamientos de la ecnica
t conocida como integridad de control de
ujo.
Palabras Clave: Integridad de Control de Flujo, Seguridad, Verica-

ci
on, Lenguajes, Programas.
1. Introducción
En los últimos años, el sistema operativo Android, inicialmente pen-

sado para teléfonos móviles, fue creciendo cada vez más en cuanto a po-
pularidad debido a una de sus mejores caracterı́sticas: la libertad.
Es que Android es un sistema operativo completamente libre. Es decir, no
hay que pagar absolutamente nada ni para programar en el ni para poder
instalarlo en un teléfono. Lo que lo hace muy popular entre desarrollado-
res, que deben pagar muy poco para lanzar una aplicación, y fabricantes
de celulares, que ahorran a la hora de elegir el sistema operativo para el
teléfono que quieren lanzar al mercado.
ISBN 978-987-23963-1-2 1471

Otra de las ventajas de ser un sistema operativo libre es que cualquier

persona puede descargar el código fuente, inspeccionarlo, modificarlo y
finalmente compilarlo. Por lo que, como cualquier software libre, es más
fácil detectar errores rápidamente y por ende solucionarlos, esto favorece
mucho a la seguridad en el sistema operativo ya que las vulnerabilida-
des que van surgiendo se van reparando constantemente. Sin embargo,
hay ciertos aspectos en cuanto a seguridad, que a pesar de esto, aún no
han sido cubiertos. Y esta fue nuestra motivación para llevar a cabo este
trabajo: Poder solucionar alguna de estas fallas de seguridad a nivel apli-
cación que a la fecha aún no han sido solucionadas.
Existen reportes de numerosas cantidades de vulnerabilidades detectadas
en el sistema operativo Android, pero como se mencionó anteriormente,
al ser un sistema de código libre, estas vulnerabilidades son solucionadas
rapidamente luego de ser reportadas. Aunque se encontró una que hasta
la fecha, no ha sido solucionada: Vulnerabilidades al usar “Intent” explı́ci-
tos.
Brevemente, un “Intent” es un método que pueden ser utilizados en apli-
caciones Android para invocar desde una aplicación a otra. Esta invoca-
ción puede incluir el paso de algún tipo de información y puede ser de
manera implı́cita o explı́cita. En la forma implı́cita,el programador no
indica que aplicación en concreto quiere invocar sino que simplemente
indica el tipo de información que quiere que sea procesada y el sistema
operativo se encarga de elegir las aplicaciones correctas para que luego
el usuario opte por la que desee. Por otro lado, en la forma explicita, el
programador indica especı́ficamente que aplicación invocar.
Esta segunda forma de hacer el Intent puede ocasionar una vulnerabili-
dad, ya que, la aplicación que se invoca (aplicación destino) puede ser
modificada (de forma maliciosa o no) y esta modificación puede permitir
manipular de manera indeseada la información recibida. Por ejemplo, si
tenemos una aplicación que envı́a un intent que agregue un contacto de
la agenda o un mensaje para publicar en una red social y la aplicación de
destino no es la esperada se puede filtrar información confidencial.
A continucación se presenta una breve introducción a Android, seguido de
una descripción de algunas vulnerabilidades reportadas. Luego, se descri-
be brevemente la técnica que motivó este trabajo: Integridad de Control
de Flujo. Seguido de la presentación de la herramienta. Para finalizar se
presentan las conclusiones.
ISBN 978-987-23963-1-2 1472

2. Android
Android es un sistema operativo basado en Linux, diseñado princi-

palmente para dispositivos móviles con pantalla táctil como por ejemplo
tablets y smarthphones. Fue desarrollado por Android Inc. con el respal-
do económico de Google que en el 2005 termina comprando a la empresa.
Finalmente, en octubre del 2008 se vendió por primera vez un celular con
este sistema operativo.
2.1. Arquitectura de Android

Los componentes principales de Android son cinco:
Aplicaciones: Este primer componente o nivel, esta compuesto por

el conjunto de todas las aplicaciones instaladas en una máquina An-
droid y deben correr en la máquina virtual Dalvik para “garantizar”
la seguridad del sistema. Generalmente las aplicaciones Android están
escritas en Java aunque también se pueden programar en C++ utili-
zando el kit de desarrollo Android NDK (Native Development Kit).
Marco de trabajo de aplicaciones: Los desarrolladores tienen acceso a
los mismos APIs del framework que usan las aplicaciones base (senso-
res, barra de notificaciones, servicios, etc...). Esta capa está diseñada
para simplificar la reutilización de componentes. Cualquier aplicación
puede publicar sus capacidades y cualquier otra aplicación puede luego
hacer uso de estas (respetando siempre las reglas de seguridad del fra-
mework). Este mismo mecanismo permite que los componentes sean
reemplazados por el usuario.
Bibliotecas nativas: Android incluye además un conjunto de librerı́as
de C/C++ que son usadas por varios componentes del sistema. Y
son expuestas también a los desarrolladores por medio del marco de
trabajo de aplicaciones. Se pueden destacar bibliotecas como: System
C library, Media Framework, etc..
Runtime de Android (Máquina Virtual Dalvik): Debido a las limita-
ciones de memoria y procesador de los dispositivos móviles donde ha
de correr Android no fue posible utilizar la máquina virtual estándar
de Java para la ejecución de aplicaciones, Google debió crear una nue-
va máquina virtual Dalvik que funcione mejor ante estas limitaciones.
Algunas caracterı́sticas de la máquina virtual Dalvik que ayudan a
optimizar recursos son:
• Ejecuta ficheros Dalvik ejecutables (ficheros con extensión .dex).
Este formato está optimizador para ahorrar memoria.
ISBN 978-987-23963-1-2 1473

• Basado en registros, en lugar de estar basada en una pila.

• Cada aplicación corre en su propio proceso Linux con su propia
instancia de la máquina.
• Delega al kernel de Linux algunas funciones como threading y el
manejo de la memoria a bajo nivel.
Núcleo Linux: El núcleo de Android está formado por el sistema ope-
rativo Linux. Esta capa proporciona servicios como la seguridad, el
manejo de la memoria, el multiproceso, la pila de protocolos y el so-
porte de drivers para dispositivos. Es la única capa dependiente del
hardware ya que actúa como capa de abstracción entre el hardware y
la pila de protocolos.
2.2. Aplicaciones
Las aplicaciones de Android, como ya mencionamos, se pueden pro-
gramar tanto en C++ como en Java. Cuando se compilan los programas,
el Kit de Desarrollo nos arma un archivo .APK. Los programas compila-
dos son programas en Bytecode para la máquina virtual Dalvik.
Los archivos .APK son los que nos permiten instalar una aplicación en el
celular. Contienen una serie de instrucciones a ejecutar y además otros
recursos como imágenes, sonidos y archivos .xml cómo por ejemplo el An-
droidManifest.xml.
Cada APK se asocia a un proceso único, que proporciona el ambiente de
ejecución de los componentes. De los cuales, uno es el componente inicial
del programa.
Cuando se ejecuta una aplicación se le asigna un proceso Linux y un úni-
co hilo de ejecución (thread), ası́ todos sus componentes corren sobre el
mismo proceso y thread.
2.3. Seguridad en Android

La seguridad es un aspecto clave en cualquier sistema. Si nos descar-
gamos una aplicación maliciosa a nuestro celular, esta podrı́a robarnos
contactos, enviar sms por su propia cuenta y sin nuestra autorización
o hasta incluso saber donde estamos posicionados fı́sicamente utilizando
datos del gps del sistema.
Android propone un esquema de seguridad para proteger a los usuarios,
sin tener que imponer un sistema centralizado en alguna empresa (como
si lo hace el sistema operativo de iPhone por ejemplo). Este esquema es-
ta basado en tres pilares fundamentales: la seguridad de Linux, la firma
digital de la aplicación y un modelo de permisos de acceso a partes del
ISBN 978-987-23963-1-2 1474

sistema. Este último componente establece que muchas decisiones impor-

tantes relativas a la seguridad recaigan en el usuario final.
Seguridad Linux Como se comentó en la sección anterior, Android

está basado en Linux, por lo tanto, se aprovecha la seguridad que in-
corpora este sistema operativo. De esta manera Android puede impedir
que las aplicaciones tengan acceso directo al hardware o interfieran con
recursos de otras aplicaciones.
Firma digital de las aplicaciones Las aplicaciones deben ser firmadas

con un certificado digital que identifique al autor. Esto nos permite ver
que aplicaciones se supone que sean más confiables que otras. Además,
la firma digital nos garantiza que los archivos de una aplicación no han
sido modificados. Si se opta por modificar la aplicación, está deberá ser
firmada nuevamente. Generalmente este certificado digital no es firmado
por alguna autoridad de certificación.
Modelo de permisos: Android Manifest Si queremos que una apli-

cación tenga acceso a partes del sistema que pueden comprometer la se-
guridad del sistema necesitamos utilizar un modelo de permisos, de forma
el usuario puede conocer los riesgos antes de instalar la aplicación. Para
lograr esto, se utiliza el archivo Android Manifest.
Cada aplicación de Android debe contener un archivo AndroidManifest.xml
(con exactamente este nombre) en su directorio raı́z. Este archivo le pre-
senta información esencial sobre la aplicación al sistema operativo, infor-
mación que el sistema debe tener antes de poder correr el código de la
misma.Entre otras cosas, el AndroidManifest.xml tiene:
El nombre del paquete Java que sirve como identificador único para
las aplicaciones del sistema operativo.
Componentes de la aplicación.
Permisos que la aplicación va a solicitar al momento de su instalación.
Pueden ser tanto como para acceder a la API o interactuar con otras
aplicaciones.
Bibliotecas con las que debe linkear.
Nivel mı́nimo de la API de Android requerido para su funcionamiento.
2.4. Vulnerabilidad por Intent Explı́citos

La interacción entre componentes en un sistema Android están dados
por pasaje de mensajes llamados Intents. Estos mensajes están formados
ISBN 978-987-23963-1-2 1475

por una dirección o nombre de destino e información relacionada con la

acción a ejecutar.
Cuando un componente envı́a un Intent, el receptor del mismo iniciará una
actividad, mensaje broadcast o servicio que ejecutarán una acción.
Hay dos tipos de intents posibles, por un lado tenemos los intents implı́ci-
tos donde no se indica el destino del mensaje, sino que solo se indica el
tipo de mensaje (texto plano por ejemplo) y entonces todas las aplicacio-
nes que declaren en su AndroidManifest que pueden recibir ese tipo de
mensajes, aparecerán en una lista para que el usuario decida que aplica-
ción es la que recibirá el mensaje. Un claro ejemplo de esto, es cuando
tenemos más de un navegador web instalado en el celular y hacemos click
en algún link que nos lleve a una dirección web. En ese momento, nos
aparecerá una lista con todos los navegadores instalados de la cual debe-
mos elegir cuál queremos usar.
Por otro lado, tenemos los intents explı́citos, aquellos a los que si quere-
mos indicarle especı́ficamente a quién va dirigido el mensaje, es decir, el
nombre del paquete de la aplicación receptora.
La posible vulnerabilidad de este tipo de intents, radica en que al indicar
solo el nombre del paquete de la aplicación, es posible cambiar la aplica-
ción receptora por otra con el mismo nombre y cuyo comportamiento no
es el que nosotros deseamos.
Para entender mejor esta vulnerabilidad veamos un simple ejemplo:
dada una agenda de contactos que posee la funcionalidad de enviarle los
contactos favoritos a otra aplicación de mensajerı́a (Similar a aplicacio-
nes como Viber o Whatsapp). Esta aplicación de mensajerı́a, recibe los
contactos de esta nueva agenda y los utiliza para poder enviarle y recibir
mensajes de ellos.El problema esta en qué si se cambia esta aplicación de
mensajerı́a, puede ocurrir que en lugar de recibir los contactos y guardar-
los para luego poder comunicarse con ellos, los envié a una dirección de
correo y ası́ nos robe los contactos de la agenda.
3. Integridad del control de flujo
Las computadoras con frecuencia son objeto de ataques externos que

apuntan a controlar el comportamiento de algún software. Generalmente
estos ataques llegan como datos a través de un canal de comunicación nor-
mal y, una vez que residen en la memoria del programa, explotan defectos
preexistentes en el software. Explotando dichos defectos, el atacante des-
estabiliza y toma control del comportamiento del software. Por ejemplo,
un desbordamiento del buffer en una aplicación puede resultar en una
ISBN 978-987-23963-1-2 1476

llamada a una función sensible del software, posiblemente una función

que la aplicación no fue diseñada para su uso.
Las polı́ticas de la integridad de control de flujo [9,10] dictan que la eje-
cución del software deben seguir un camino de su grafo de control de flujo
creado de antemano. El grafo en cuestión puede ser definido por análisis
de código, análisis de los ejecutables o mediante perfiles de ejecución.
Hay varias formas de llevar dicho control, pero en el presente trabajo nos
centraremos en la instrumentación de código debido a que es el método
utilizado en nuestra herramienta.
3.1. Instrumentación de código

La instrumentación de código es la inserción de código con el fin de
asegurar la perfomance de un sistema, diagnosticar errores y escribir in-
formación del flujo del programa. La instrumentación le otorga a un pro-
grama la de incorporar:
Seguimiento de código: recibiendo mensajes informativos acerca de la
ejecución de una aplicación en tiempo de ejecución.
Depuración y un estructurado manejo de excepciones: búsqueda y co-
rrección de errores de programación en una aplicación bajo desarrollo.
Profiling: un medio por el cual los comportamientos dinámicos de los
programas pueden ser medidos durante un ejecución de prueba con
una entrada representativa. Esto es útil para probar propiedades de
un programa que no puede ser analizadas estáticamente con suficiente
precisión, como por ejemplo análisis de aliasing.
Contadores de rendimiento: componentes que permiten el seguimiento
de la performance de una aplicación.
Registro de datos: componentes que permiten el registro y seguimiento
de la mayorı́a de los eventos en la ejecución de la aplicación.
4. La Herramienta
Teniendo en cuenta la vulnerabilidad explicada en la sección anterior

sobre los intents explı́citos, se decidió crear una herramienta que pudie-
ra de alguna forma solucionar este posible problema en las aplicaciones.
La herramienta tiene la funcionalidad de controlar que el flujo de la in-
formación mediante intents sea el requerido por el usuario. Para eso se
introduce en la aplicación que envı́a la información, antes de cada invo-
cación de intent, una verificación para garantizar que efectivamente el
mensaje sea atrapado por la aplicación deseada.
ISBN 978-987-23963-1-2 1477

Para lograr esto se trabajó sobre el control de flujo de la aplicación, más

precisamente se instrumentó código a la aplicación que envı́a el intent. A
grandes rasgos, este código es una función que toma como parámetro el
nombre de una aplicación y un identificador único (id) de la misma. Este
id es obtenida calculando un código hash para luego checkear en una lista
confiable presente en el celular si el id de esa aplicación es el mismo que
el id actual de la aplicación con ese nombre. De esta forma se detecta si
el receptor del mensaje fue modificado o no.
La herramienta y su documentación esta disponible en https://sourceforge.net/projects/
4.1. El Proceso
A continuación se detalla el proceso realizado por la herramienta para
generar las verificaciones. Este proceso se realiza cuando la aplicación es
instalada en el dispositivo Android.
Conversión a código Jasmin En primer lugar, cuando el usuario elige

el programa que desea verificar que sus intents sean correctos, la herra-
mienta transforma el archivo .APK (el programa a instalar en el dispo-
sitivo) a código Jasmin [6] (una representación intermedia de código by-
tecode), para eso invoca una serie de scripts (basados en la herramienta
Dex2Jar [3]:
d2j-dex2jar.sh: Extrae el classes.dex del apk y lo convierte en un
archivo .jar.
d2j-asm-verify.sh: Verifica que el .jar creado sea correcto.
d2j-jar2jasmin.sh: Transforma el código .jar en código Jasmin.
Obtención de la Id de la aplicación Para poder controlar que la

aplicación receptora del mensaje o intent no sea modificada es necesario
asignarle una id única. Para esto se creó un script en Python que obtiene
el código hash de un archivo, de esta forma se le obtiene el hash al archi-
vo instalador (.apk) de la aplicación receptora que si recibe un mı́nimo
cambio entonces su id cambiará. Para obtener el código hash del .apk se
utiliza la librerı́a hashlib de Python.
Inserción de las Verificaciones Dinámicas Se introducen las verifi-

caciones dinámicas que chequean que el id de cada aplicación en tiempo
de instalación se correspondan con el id de la aplicación en tiempo de
ejecución. Estas verificaciones se introducen en el código Jasmin.
ISBN 978-987-23963-1-2 1478

Para esto se implementó un método Check en Jasmin que toma como

parámetros el nombre de la aplicación que se va a checkear y el id o código
hash del mismo que espera. Luego busca en un archivo auxiliar instalado
en el dispositivo donde se encuentran los nombres de las aplicación insta-
ladas con nuestra herramienta y su código hash actual, que si el nombre
de la aplicación pasada como parámetro coincide con alguno del archivo,
sus ids también deben coincidir.
Figura 1. Instrumentaci
on de ocdigo en el archivo principal
Finalmente se introduce antes de cada invocación a un intent que se

desea controlar la llamada a esta función. En pseudocódigo, es una simple
llamada a la función check: check(nombrePaquete,IdEsperado).
ISBN 978-987-23963-1-2 1479

Figura 2. Script insertcheckers.sh: Instrumentaci

on de ocdigo en el resto de los archivos
que invocan a la aplicaci
on receptora
Reconstrucción del .APK Una vez finalizada la inserción de código

solo resta reconstruir el .APK para ello se utilizan algunos scripts de la
herramienta Dex2Jar:
1. d2j-jasmin2jar.sh: Reconstruye el .jar.
2. d2j-asm-verify.sh: Nuevamente se verifica que el .jar sea correcto.
3. d2j-jar2dex.sh: Se reconvierte a código dex.
Posteriormente se crea una copia de seguridad del .apk y se le reemplaza
el dex original con el modificado.
Por último, como Android necesita que los .apk estén firmados para que
te los permita instalar, se vuelven a firmar.
La Verificación El proceso de verificación en tiempo de ejecución, es

decir, la verificación cuando se ejecuta la aplicación es sencilla. El código
instrumentado ejecuta un método qie verifica si el id actual del intent
implı́cito que se ejecutará a continuación es igual al id en tiempo de
instalación. En caso de no coincidir no se permite la ejecución del intent.
4.2. Ejemplos
En primer lugar se implementó una agenda de contactos donde se al-
macenan números telefónicos que pueden ser usadas por otra aplicaciones
ISBN 978-987-23963-1-2 1480

para el envı́o de mensajes.

Si seleccionamos un contacto de la agenda, automáticamente este se lo
envı́a a la aplicación de mensajerı́a quién almacena el número y luego de
que se escriba el mensaje, envı́a su contenido al destinatario.
Como segundo ejemplo se implementó una aplicación de logueo a ho-
mebanking de distintos bancos. La aplicación permite ingresar usuario
y contraseña y elegir a que banco se desea acceder para luego enviar al
modulo del banco seleccionado los datos de sesión y consultar saldo o
movimientos. Este módulo podrı́a ser modificado para que los datos del
cliente se envı́en ocultamente por email, o directamente que se hagan
transferencias no deseadas.
Con estas dos aplicaciones se pudo apreciar que el enfoque es factible
para reforzar la integridad de control de flujo en aplicaciones Android con
la herramienta presentada. En abos casos se detectó cuando las aplica-
ciones fueron cambiadas y/o modificadas.
5. Conclusiones
El desarrollo de esta herramienta se puede fundamentar fácilmente

revisando las vulnerabilidades que están presentes actualmente en el sis-
tema operativo Android y en la presunción (fundamentada en la expe-
riencia hasta el momento) de que se detectarán nuevas vulnerabilidades
en el futuro. Por ejemplo, es posible escalar privilegios y modificar una
aplicación, que se encuentre presente en el celular, receptora de algún
intent o mensaje explı́cito. También puede ocurrir que la aplicación sea
modificada por una actualización de la aplicación (una actualización que
implique un cambio defuncionalidad no deseado).
La herramienta presentada permite controlar por fuera del sistema
operativo y darle más garantı́a a los programadores de Android, de mane-
ra autómatica, verificando que los intent tengan el destinatario esperado.
En otras palabras, la herramienta garantiza la integridad del control de
flujo relacionada con los intents implicitos.
La solución presentada en el presente trabajo tiene la desventaja que
no es una solución a nivel sistema operativo por lo que se necesita sı́ o
sı́ de la herramienta realizada. Esta desventaja no es tan negativa por
el hecho de que son escasas las veces que se requieren realizar este tipo
de checkeos por lo que no es tan molesto tener que recurrir a la herra-
mienta para lograrlo. Además necesita también de otra base confiable, en
este caso de un instalador de aplicaciones alternativos que vaya actua-
lizando y agregando los ids de las aplicaciones instaladas en un archivo
ISBN 978-987-23963-1-2 1481

confiable. Por otro lado, la herramienta tiene la ventaja que se puede mo-
dificar fácilmente o incluso utilizarla para realizar otro tipo de chequeos
o modificaciones de las aplicaciones.
5.1. Trabajos futuros

Los trabajos más relevantes que se deben realizar para mejorar la
herramienta y extender su funcionalidad son:
extender el método de verificación para incluir los intent implı́citos.
En Android cuando se hace un intent implı́cito se crea una lista de
aplicaciones que pueden manejar el tipo de dato enviado (por ejemplo,
texto plano) para que el usuario elija la aplicación que reciba el intent.
Para garantizar la aplicación/es autorizadas a recibir determinado
intent implı́cito es necesario poder generar la lista dinámicamente (y
no tomar la lista generada autómaticamente por Android).
La herramienta esta programada en bash de Linux y en Python ambos
estan disponibles para Android, por lo que es factible hacerla nativa
para Android. Sin embargo habrı́a que modificar o sustituir el instala-
dor de aplicaciones de Android por un instalador “seguro” para darle
mayor grado de confiabilidad.
Es necesario estudiar la posibilidad de implementar este enfoque para
garantizar la integridad del control de flujo desde el receptor de los
intent. Es decir, que el receptor sea el que verifique si el intent fue
disparado por una aplicación autorizada.
Referencias
1. Web oficial de desarrollo para Android,
http://developer.android.com/index.html
2. Android Argentina, http://androidargentina.com.ar/
3. Web oficial de Dex2jar, http://code.google.com/p/dex2jar/
4. ¿Qué es Android?, http://www.xatakandroid.com/sistema-operativo/que-es-
android.
5. Wikipedia: Android, http://es.wikipedia.org/wiki/Android
6. Web de Jasmin, http://jasmin.sourceforge.net/about.html
7. Android Security, https://source.android.com/tech/security/
8. Introduction to Instrumentation and Tracing
http://msdn.microsoft.com/en-us/library/aa983649 %28VS.71 %29.aspx
9. Martı́n Abadi; Mihai Budiu; Úlfar Erlingsson y Jay Ligatti. Control-Flow
Integrity Principles, Implementations, and Applications. ACM Journal Vol V, Fe-
brero 2007.
10. Chao Zhang; Tao Wei; Zhaofeng Chen; Lei Duan; Lászl Szekeres; Step-
hen McCamant; Dawn Song y Wei Zou. Practical Control Flow Integrity &
Randomization for Binary Executables.
ISBN 978-987-23963-1-2 1482

KD Argentina

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

KD Argentina

Uploaded by

Copyright:

Available Formats

XIX Congreso Argentino de Ciencias de la Computación CACIC 2013

Improving versatility in keystroke dynamic

Enrique Calot, Juan Manuel Rodriguez, and Jorge Salvador Ierache?

Laboratorio de Sistemas de Información Avanzados,

Abstract. Keystroke dynamics is a biometric technique to identify users

Keywords: Keystroke Dynamics, Web based authentication, Mahalanobis

ISBN 978-987-23963-1-2 1434

2 Improving versatility in keystroke dynamic systems

The biometric technology employed in this paper is the typing biometrics,

2.1 Euclidean distance

ISBN 978-987-23963-1-2 1435

Improving versatility in keystroke dynamic systems 3

2.2 Normalized euclidean distance

A disadvantage of the former method is that important information is ignored.

where s2i is the variance of each element of Γ1 .

2.3 Mahalanobis distance

d(Γ1 , Γ2 )2 = (Γ1 − Γ2 )T S −1 (Γ1 − Γ2 ) (3)

3 Problems of Mahalanobis distance in keystroke

3.1 Distance kernel matrix size

ISBN 978-987-23963-1-2 1436

4 Improving versatility in keystroke dynamic systems

Table 1. Different parameters to be sent to the server

Distance Method Variables

3.2 One password algorithm

3.3 Backspace eliminating digraphs

3.4 Processing times

ISBN 978-987-23963-1-2 1437

Improving versatility in keystroke dynamic systems 5

Method Key Times Inverse S −1 

ISBN 978-987-23963-1-2 1438

6 Improving versatility in keystroke dynamic systems

Table 3. Experimental results

N Method Total Errors ROC Zero-miss False-Alarm Time

ISBN 978-987-23963-1-2 1439

Fig. 1. Distance methods compared in success versus amount of information

In Figure 1 it is possible to appreciate how similar are the normalized eu-

8 Improving versatility in keystroke dynamic systems

6.1 Future lines of research

Acknowledgments. This paper acknowledges support from Cloodie R&D.

ISBN 978-987-23963-1-2 1441

Gestión Integral de Seguridad de Infraestructuras críticas paralas

1Licenciada en Administración de empresas egresada de la U.N.S.J. Magíster en Gestión de Organizaciones egresada de la

ISBN 978-987-23963-1-2 1442

II.-Gestión integral de la seguridad.

A los efectos de garantizar la selección de controles de seguridad adecuados y proporcionales y para

ISBN 978-987-23963-1-2 1443

ISBN 978-987-23963-1-2 1444

III.- Infraestructuras críticas.

ISBN 978-987-23963-1-2 1445

IV. Propuesta para implementar en la UNSJ.

ISBN 978-987-23963-1-2 1446

La Metodología propuesta para el Manejo de Incidentes CSIRT9 – UNSJ, básicamente se ha

ISBN 978-987-23963-1-2 1447

ISBN 978-987-23963-1-2 1448

ISBN 978-987-23963-1-2 1449

La seguridad de la infraestructura digital se encuentra expuesta a constantes amenazas, que en caso

La propuesta para gestión integral de la seguridad de la información diseñada para la protección de

El proyecto de Creación e Implementación de un CSIRT Académico para la Universidad Nacional de

ISBN 978-987-23963-1-2 1450

ISBN 978-987-23963-1-2 1451

Model Design for a Reduced Variant of a Trivium Type

Abstract. We analyze the family of stream ciphers N-viums: Trivium and

Keywords: LFSR, NLSFR, Trivium, Bivium, Trivium-Toy, Bivium-Toy.

Method Key Times Inverse S −1