Crónica X OWASP Spain Chapter Meeting

El pasado día 17 de noviembre tuvo lugar en Barcelona la X edición de OWASP Spain Chapter. Participaron grandes ponentes, entre los que destaca nuestro compañero de auditoría Luis Enrique Benítez.  A lo largo del día se hicieron varias conferencias de distintos temas, entre ellos: IoT (Internet of Things), XSS (Cross-site Scripting), OWASP como base para realizar auditorías de dispositivos y encontrar vulnerabilidades en páginas web…

La primera presentación del día trató sobre XSS (Cross-site Scripting), de la mano de Ashdar Javed. En ella pudimos constatar lo vulnerables que aún somos ante este tipo de ataques, y es que, aunque XSS se descubrió hace ya muchos años, sigue siendo un vector de ataque muy importante en la red. Por ejemplo, en los 2 últimos años solamente Google ha pagado 1.2M$... Además, se pudo constatar que dichas vulnerabilidades están presentes en una gran cantidad de productos, creados por empresas de prestigio internacional, y usados por millones de usuarios.

La segunda presentación la realizó nuestro compañero Luis Enrique Benítez, y trató sobre IoT (Internet of Things). El nombre de por sí ya era llamativo: “IoT: Insecurity of Things”, y es que delante del auge de todo este tipo de dispositivos nos deberíamos plantear varias preguntas, entre ellas la siguiente: “¿Realmente somos conscientes de lo que conectamos en la red?”. En la presentación pudimos ver como diferentes televisores inteligentes recopilan y envían información de uso a distintos servidores, dependiendo del canal que estamos viendo. Además, la mayoría de dispositivos tenían vulnerabilidades que podían ser explotadas. Y la pregunta final debería ser: “¿Qué pasará cuando los dispositivos se queden obsoletos y dejen de recibir actualizaciones del fabricante?”.

Antes de realizar el coffee-break, para poder asimilar toda la información recibida, fue el turno de Miguel Ángel Arroyo con la presentación “OWASP Mobile Security Project como base para auditar una aplicación iOS”. En ella, aprendimos sobre el OWASP Mobile Security Project, y se pusieron de ejemplo un conjunto de herramientas para llevar a cabo auditorías en dispositivos móviles. A modo de ejemplo, y presentando todo el procedimiento llevado a cabo, el ponente nos mostró cómo pudo incrementar los billetes y las monedas de un juego (y sí, a partir de ese momento el juego ya no tenía gracia…).

Ya después del coffee-break fue el turno de Adrià Massanet, con la presentación “Aprendiendo de los fallos de SSL”, donde pudimos ver los fallos de SSL más comunes, y lo más importante, un conjunto de medidas para poder evitar, en la medida de lo posible, que estos ocurran en un futuro. Una gran presentación a tener en cuenta como guía de buenas prácticas.

En la última presentación de la mañana, titulada “Con la vuln en los servidores. ¿A quién se lo cuento?”, Norberto González nos explicó cómo se debe realizar el reporte de intromisiones en los sistemas, la metodología que tiene que seguirse y las leyes que afectan (y como éstas no se deben tomar en blanco y negro, sino en escala de grises).

Después de la comida fue el turno de Deepak Daswani con la presentación: Hacking del Internet of Things (and Beats). Pudimos concienciarnos, en primer lugar, de la mala configuración de seguridad que aplican diferentes empresas en sus redes inalámbricas y en el conjunto de distintos elementos que la componen, seguramente por desconocimiento. En segundo lugar, pudimos observar una demostración de las vulnerabilidades que posee, en este caso, una mesa de mezcla con conexión inalámbrica para transmitir canciones.

A continuación, Marc Rivero nos deleitó con Fast incident response!. La presentación se centraba en la gestión rápida de incidentes, centrándose en la gestión y el análisis del conjunto de logs obtenidos, y en los métodos procedimentales que se deberían seguir para una correcta gestión de estos. Además, se mostraron algunas herramientas útiles para conseguir este objetivo.

Finalmente, Pedro Candel nos sedujo con OWASP: Wild pentesting in CLM for fun & profit, mostrando diferentes páginas web vulnerables, y ejemplos específicos sobre la forma de aprovechar las vulnerabilidades. Además, se constató que dichas vulnerabilidades están presentes durante mucho tiempo, y que los webmasters o responsables de seguridad no siempre se preocupan de solucionarlas (ni siendo avisados de su existencia).


Autor: Marc de Tébar
Departamento Consultoría

Crónica del First Hacker's Challenge Colombia 2016


Un evento realizado por Olimpia, Radware, Ciberseguridad Colombia y DreamLab con la intención de dar a conocer sus productos de seguridad DefensePro, y alteon de Radware. Con este motivo, crearon el “First Hacker Challenge de Colombia 2016” para tratar de vulnerar una aplicación web protegida por estos productos de seguridad.

El evento tuvo lugar el 3 de noviembre de 1:30pm a 6:00pm en la ciudad de Bogotá, a la cual asistieron 27 hackers y 160 invitados para presenciar el evento.

El escenario del desafío se realizó dividiendo a los hackers por países, donde 3 hackers formaban 1 país, para representar de la forma más realística posible, como se puede atacar un sitio web desde cualquier parte del mundo. Los hackers podían llevar sus equipos y utilizar cualquier tipo de herramienta. Se permitía utilizar el método deseado con la finalidad de vulnerar el sistema. Además, el público también podía realizar pruebas sobre el sistema, donde se les brindaba direccionamiento IP inalámbrico para realizar ataques contra la infraestructura y la web objetivo.


Durante el evento, se configuraron en los equipos DefensePro y Alteon varios niveles de seguridad, con la intención de mostrar la defensa que se puede ofrecer a la infraestructura y a los servicios. A continuación, se relajaba el nivel de seguridad para mostrar cómo de expuesta y vulnerable puede quedar la infraestructura sin la correcta configuración e implementación de estos equipos de seguridad.

El evento mostraba mediante la monitorización y logs de los equipos Radware, todos los ataques que se llevaban a cabo en cada nivel de seguridad configurado, mostrando como se visualiza en la herramienta de gestión los ataques realizados por los hackers. Desde la organización, con la idea de mostrar de una forma más sencilla los ataques que se realizaban a la plataforma, mostraron en una pantalla una visualización del mapa del mundo donde mediante el WAF integrado en su plataforma (Alteon) detectaba qué direcciones IP estaban generando tráfico malicioso, y estas se representaban en el mapa con la bandera del país asociado a dichas  direcciones IP. En otra pantalla, se mostraba la monitorización de la solución defensePro (antimalware) indicando los tipos de ataques bloqueados que alertaban al sistema.

A cada hacker se le facilitó una conexión ethernet y una conexión Wifi, donde se le administraba 10 direcciones IP estáticas, y también podían recibir IP por DHCP. La estructura de la red para el escenario de la competición, constaba de una red segmentada para cada país que simulaba carriers distribuidos alrededor del mundo. La primera línea de defensa era el DefensePro, después un firewall Checkpoint, luego un balanceador de carga que distribuía el tráfico, el cual era enviado para su análisis a un WAF, y finalmente los servidores detrás de esta infraestructura.


Cada vez que se realizaba un ataque con éxito, se recibía una puntuación de acuerdo al nivel de seguridad que se encontrara en ese momento en los equipos de Radware. Cada ronda tenía una duración de 30 minutos, y a continuación se disminuía el nivel de seguridad. Sólo los 5 hackers con mayor puntuación avanzaban a la siguiente ronda.

Los retos a los cuales nos enfrentamos eran basados en el OWASP Top 10. Se había creado un entorno controlado donde el objetivo principal era vulnerar una aplicación de banca online con múltiples vulnerabilidades, protegida con los equipos RADWARE. Estos equipos hacían aún más difícil la intrusión de los hackers participantes. El principal problema radicaba en el baneo o bloqueo de direcciones IP una vez los equipos detectaban ataques.


Durante cada fase del CTF, los administradores del entorno de pruebas, disminuían las capas de protección, generando nuevas brechas de seguridad que podían ser explotadas. Por cada ataque con éxito, el jurado asignaba puntos a los equipos, donde el que obtuviera finalmente la mayor puntución resultaba el ganador de la competición.

Por parte de Internet Security Auditors participaron Richard Javier Oliveros Álvarez y Julián Alberto Muñoz López. Ambos reflejaron el elevado nivel de conocimientos por parte del equipo de Internet Security Auditors, destacando el excelente trabajo realizado por Julian y la obtención del primer lugar del CTF por parte de Richard Oliveros.

Los retos:
Los principales objetivos a cumplir por parte de los equipos eran:
  • Lograr identificar los puertos abiertos del servidor y enumerar posibles vulnerabilidades.
  • Identificación de la base de datos y explotación de la misma a través de distintos tipos de inyecciones.
  • Elevación de privilegios.
  • Explotación de ataques XSS.
  • Manipulación de parámetros con fines delictivos.
  • Ataques de denegación de servicio.

La estrategia Ganadora:
Al igual que en el procedimiento habitual para la planificación de una auditoria a una aplicación web, se debía realizar una fase previa de recopilación de información para conocer las características del sistema objetivo. En la página del evento (http://www.hackers-challenge.co/index.html) se describía previamente que cada participante tendría un pool de 10 direcciones IP, lo cual daba a entender que los equipos de protección (en este caso, RADWARE), bloquearían las direcciones IP que detectaran como sospechosas. De esta forma, se prepararon varias máquinas virtuales y dos equipos físicos a los cuales se les asignó una IP fija a cada uno de ellos para tener disponibilidad en caso de que una de las máquinas fuera baneada.



Por otra parte, se descargaron los manuales de los equipos RADWARE,  con el objetivo de buscar en las especificaciones los tipos de ataques que no soportaban o mitigaban, para así planear la mejor estrategia.

Al conocer que sólo se entregaría un punto de red físico para cada participante, se llevó un switch el cual permitiría conectar los dos equipos físicos a la red.

Como era evidente que los equipos RADWARE bloquearían cada ataque que se realizara, previo al evento, se prepararon notas, scripts, métodos de ofuscación y evasión de escaneos e inyecciones, etc. y se instalaron en la máquina KALI que se utilizaría en el CTF.

Durante el evento, se pudo apreciar el fruto de dicha preparación. Mientras otros equipos encontraban dificultades a la hora de progresar, o se veían bloqueados por los dispositivos de seguridad, el equipo de Internet Security Auditors avanzaba rápidamente.

Cabe destacar que gran parte de las pruebas se ejecutaron de forma manual, y las herramientas, salvo Burp Suite y Tamper Data para la interceptación y manipulación del tráficos HTTP, tuvieron poco peso en las pruebas.

Las herramientas empleadas:
Para el escaneo de puertos y el análisis de vulnerabilidades, se utilizó Nmap con técnicas de evasión, Acunetix con credenciales de acceso a la aplicación, Burp Suite y el plugin de Firefox Tamper Data para la manipulación de peticiones, script Hulk.py y slowloris para ataques de denegación de servicio, y visor de desarrollador de Firefox para el análisis de código.

Como parte de los equipos del CTF, se encontraba personal militar de la unidad de telemática del ejército nacional de Colombia, los cuales no se clasificaron para la ronda final.


Autores: Richard J. Oliveros & Julián A. Muñoz
Departamento Auditoría

Ya está disponible el programa del OWASP Spain Chapter Meeting

Ya está disponible el programa de la décima edición del OWASP Spain Chapter Meeting que como ya anunciamos se celebrará el próximo 17 de noviembre.

Este año, uno de nuestros miembros del equipo de auditoría participará con como ponente con la presentación: IoT (¿Insecurity of Thing?) Usando OWASP para el Internet de las Cosas, en la que hablará de cómo hoy en día se habla mucho del concepto Internet of Things (IoT) y de los riesgos en seguridad que puede conllevar la proliferación de estos dispositivos. Sin embargo, no se encuentran muchos artículos relacionados con resultados de auditorías en dichos dispositivos. En el marco de esta ponencia se expondrán los resultados y las conclusiones obtenidas en un análisis de seguridad en dispositivos IoT tan común como son las Smart TV y como la metodología OWASP es perfectamente aplicable para auditar dichos dispositivos.

 A continuación, encontraréis el programa para este año:

08:00h - 08:55h Registro de asistentes
09:00h - 09:05h Bienvenida. Jaume Abella Fuentes
09:05h - 09:15h Introducción a la jornada. Vicente Aguilera Díaz
09:15h - 10:15h Cross-Site Scripting: The Force Awakens. Ashar Javed
10:15h - 10:45h IoT (¿Insecurity of Thing?) Usando OWASP para el Internet de las Cosas. Luis Enrique Benítez Jaspe.
10:45h - 11:45h OWASP Mobile Security Project como base para auditar una aplicación iOS. Miguel Ángel Arroyo Moreno.
11:45h - 12:30h Coffee-break
12:30h - 13:00h Aprendiendo de los fallos de SSL. Adrià Massanet Bienvenido.
13:00h - 13:30h Con la vuln en los servidores. ¿A quién se lo cuento? Norberto González.
13:30h - 15:00h Pausa
15:00h - 16:00h Hacking del Internet of Things (and Beats). Deepak Daswani.
16:00 - 16:30h Fast incident response! Marc Rivero López.
16:30h - 17:30h OWASP: Wild pentesting in CLM for fun & profit. Pedro Candel (aka "s4ur0n").
17:30h - 17:55h Mesa redonda
17:55h - 18:00h Cierre de la jornada. Vicente Aguilera Díaz.

Podéis encontrar más detalles sobre el programa en la web de OWASP:
https://www.owasp.org/index.php/Spain/Chapter_Meeting

Aplicaciones de Machine Learning en Seguridad Informática II: Machine Learning aplicado a inteligencia de fuentes abiertas

Introducción
En el anterior artículo ofrecimos una primera aproximación de cómo son aplicadas las técnicas de machine learning al campo de la seguridad informática y buscamos familiarizar de manera amigable al lector con los conceptos fundamentales.

El artículo que nos ocupa en esta ocasión pretende mostrar de manera igualmente amigable como aplicar la práctica de lo expuesto en el artículo anterior. Para ello vamos a abordar la definición, entrenamiento y consulta a un modelo inteligente, de manera que se exija al lector el mínimo esfuerzo y conocimientos técnicos previos.

Experimento
En este artículo vamos a construir y evaluar nuestro primer modelo, el cual será el núcleo en un sistema de Ciberinteligencia. Dicho sistema estaría dando soporte a nuestra pequeña agencia de inteligencia, clasificando a usuarios de Twitter por su afinidad política, para el posterior registro y procesamiento de sus perfiles.

Material de trabajo
  • Weka[1]: Es un conjunto de librerías escritas en JAVA para el desarrollo de aprendizaje automático y minería de datos. Además incorpora una interface gráfica (Weka Explorer), que permite trabajar con las librerías de manera muy sencilla.
  • Tinfoleak[2]: Es una herramienta de extracción y análisis de información relevante en Twitter mediante técnicas OSINT (Open-Source Intelligence), desarrollada y mantenida por Vicente Aguilera Díaz[3].
  • Conjuntos de datos: Vamos a utilizar dos conjuntos, uno para entrenamiento y otro de evaluación del  modelo.
NOTA: Es intencionada la elección de Weka, pues el nivel de sencillez con que pretendemos abordar el tema es tal, que vamos definir, entrenar y trabajar con modelos inteligentes “a golpe de clic”. Esto es posible gracias a la interface gráfica que incorpora Weka.

Recolección de la información
El primer paso será obtener la información para el entrenamiento de nuestro modelo. Para ello vamos a apoyarnos en la herramienta Tinfoleak y nuestro objetivo será extraer los hashtags que compondrán el conjunto de entrenamiento.

Para nuestro experimento se han recopilado los hashtags publicados por cada una de las 4 principales, en número de votos, fuerzas políticas: PP, PSOE, Podemos y Ciudadanos. Esta información la convertiremos al formato nativo de Weka .arff, aunque admite otros formatos como .cvs o .data.

Podemos observar como hay dos partes diferenciadas: primero las declaraciones que definen el nombre de la relación/conjunto de datos a clasificar (@relation) y el formato (@attribute) de cada una de las dimensiones/campos del vector de entrada (metadatos), y  por último los datos propiamente dichos a partir de @data.

%comentario - Conjunto de datos en formato nativo Weka
@relation hashtags
@attribute hashtag string
%comentario - PP = 1,PSOE = 2, Podemos = 3, Ciudadanos=4
@attribute partido {1,2,3,4}

@data
'entrevista Afavor aFavor España AFavor Afavor España …’, 1
'Hashtags 26J Periscope L6elecciones L6elecciones ElDíaDelSí …’,2
‘eleccionesA3 L6elecciones L6elecciones UnidosPodemos26J RdPGarzón …,3
‘26JOndaCero CambioaMejor Ciudadanos CambioaMejor CambioaMejor L6elecciones’…,4

Carga del conjunto de entrenamiento
Comenzamos iniciando el entorno de trabajo y cargando el conjunto de datos del entrenamiento.


  1. Llamamos a la interface gráfica de Weka pinchando el archivo RunWeka.bat en la carpeta donde instalamos Weka. 
  2. En la ventana “Weka GUI Chooser”, pulsamos el botón Explorer. Explorer es la única herramienta que vamos a necesitar a lo largo de todo ejemplo. 
  3. En Weka Explorer, pestaña Preprocess, pulsamos  “Open file”, navegamos hasta donde tengamos nuestro archivo .arff y lo abrimos. 
  4. Si no hay errores de formato se cargará y veremos la información cuantitativa y cualitativa de las instancias (cada uno de los registros cargados del .arff) y sus atributos.

Pre-procesado de los datos
Antes de entrenar nuestro modelo tenemos que resolver algunas restricciones. No todos los modelos admiten todos los tipos de valores de entrada, ni clasifican etiquetando en todos los tipos datos de salida, pero sí es posible aplicar filtros para hacer conversiones entre tipos. Weka contempla dos maneras de aplicarlos:
-    De manera explícita, aplicando los filtros disponibles  en la pestaña de preprocesado
-    De manera implícita a través del clasificador FilteredClassifier, que no es más que un contenedor que vincula un modelo clasificador con uno varios filtros. Al entrenar el modelo primero se “dispararán” los filtros y, a continuación, se procederá con el entrenamiento.

Nosotros utilizaremos el segundo método, ya que nos será más cómodo de aplicar cuando en un futuro artículo abordemos este tema desde un enfoque más avanzado y centrado en  desarrollo.

Definición del modelo
El siguiente paso será definir nuestro modelo, para ello nos vamos a:
  1. En la pestaña Classify, menu Classifier, pulsamos el botón Choose y se nos desplegará la lista de clasificadores que incorpora Weka.
  2. Seleccionamos weka->classifiers->meta->FilteredClassifiers

Aunque hasta ahora la herramienta parezca de “juguete”, se empieza a evidenciar la potencia de esta al ver la cantidad de tipos y versiones de clasificadores que implementa.
  1. En la pestaña Classify, menu Classifier, pulsamos el botón Choose y se nos desplegará la lista de clasificadores que incorpora Weka.
  2. Seleccionamos weka->classifiers->meta->FilteredClassifiers
Para este experimento vamos a probar un meta-clasificador, el modelo será uno con base probabilística, el NaiveBayesMultinomial.

Además el modelo NaiveBayesMultinomial es compatible con atributos de entrada numéricos  y los hashtag son palabras. Más concretamente nuestro conjunto de datos está formado por 4 cadenas de hashtags (una por partido), por lo que debemos convertir las cadenas de caracteres a vectores “de palabras”.

'entrevista Afavor aFavor España AFavor Afavor España …’
'Hashtags 26J Periscope L6elecciones L6elecciones ElDíaDelSí …’
‘eleccionesA3 L6elecciones L6elecciones UnidosPodemos26J RdPGarzón …’
‘26JOndaCero CambioaMejor Ciudadanos CambioaMejor CambioaMejor L6elecciones’…,’

Para ello:

  1. En la pestaña Classify, menu Classifier, pulsamos sobre la cadena “weka.classifiers.meta.FilteredClassifier -F
    "weka.filters.supervised.attribute.Discretize -R first-last" -W weka.classifiers.trees.J48 -- -C 0.25 -M 2”.

    ¡OJO!, no sobre el botón Choose, EXACTAMENTE SOBRE LA CADENA.

  2. Nos aparecerá ahora la ventana “weka.gui.GenericObjectEditor” y tres opciones seleccionables, nos interesan: classifier y filter.

  3.  Pulsamos el botón Open de classifier y seleccionamos en la lista weka->classifiers->bayes->NaiveBayesMultinomial.

  4. Pulsamos el botón Open de filter y seleccionamos en la lista filter->unsupervised->attribute->StringToWordVector 

  5. Finalmente, dejamos el resto de opciones del menu Test options igual, y pulsamos Start.

  

NOTA: Tanto el clasificador, como el filtro, como las opciones de test, las hemos dejarlo con los valores por defecto. El filtro por defecto se pasará por todas las dimensiones (first-last en “attributeIndice” para las opciones del filtro), en nuestro ejemplo  procesará la primera entrada de hashtags e ignorará la clase nominal “partido”.  En cuanto a los test, dejaremos que pruebe que tal clasifica respecto al mismo conjunto con el que fue entrenado por ahora.

El resultado muestra:
  • La lista de los nuevos atributos “tokens” que se extrajeron de las cadenas de palabras. Ahora son de tipo numeric, como requiere nuestro modelo.
  • La probabilidad independiente de cada clase.
  • Las probabilidades de que aparezca cada token en cada una de las clases. La base de nuestro modelo.
  • Datos estadísticos que evalúan la calidad del modelo.
La información que más nos interesa, está justo al final, es la matriz de confusión.


Interpretarla es muy simple. La celda (1,1), marcada con 1, significa que el test clasificó como clase 1 (Partido Popular), la cadena de hashtags perteneciente a dicha clase. Por lo que el tener todos los valores concentrados en la diagonal se interpreta como que cada elemento clasificado como X por el modelo pertenece a la clase Y, siendo X=Y, dicho de otra manera, que clasificó correctamente todas las entradas.

Tampoco tiene mucho mérito, le hemos puesto las cosas fáciles al hacer el test con exactamente el conjunto de datos con el que fue entrenado. Cuando los conjunto son realmente grandes y contiene información ambigua y repetida, no será tan trivial que acierte incluso haciendo los test consigo mismo.

Consultando nuestro modelo entrenado

Ahora vamos a la parte realmente interesante, hemos extraído los hashtags de las siguientes cuentas de usuario de Twitter, ayudándonos nuevamente con Tinfoleak, y estos son los distintos conjuntos que forman:

NOTA: Solo se están mostrando en la tabla los primeros hashtags. Nótese los puntos suspensivos (…) al final del mismo.


%Comentario @marianorajoy
@relation hashtags
@attribute hashtag string
@attribute partido {1,2,3,4}

@data
'Afavor RajoyenCOPE RajoyenCOPE España 26J RajoyenCOPE RajoyEnCOPE Afavor España…'

%Comentario @sanchezcastejon
@relation hashtags
@attribute hashtag string
@attribute partido {1,2,3,4}

@data
'Periscope ElDíaDelSí JornadaDeReflexión CaravanaPSOE VotaSíVotaPSOE VotaSíVotaPSOE…'

%Comentario @Pablo_Iglesias_
@relation hashtags
@attribute hashtag string

%Comentario @Pablo_Iglesias_
@relation hashtags
@attribute hashtag string
@attribute partido {1,2,3,4}

@data
'UnidosPodemos26J UnidosPodemos26J UnidosPodemos VotaUnidosPodemos26J …'

%Comentario @agarzon
@relation hashtags
@attribute hashtag string
@attribute partido {1,2,3,4}

@data
'26J AVotar UnidosPodemos26J UnidosPodemos26J UnidosPodemos26J …'

%Comentario @InesArrimadas
@relation hashtags
@attribute hashtag string
@attribute partido {1,2,3,4}

@data
'CambioaMejor 26J L6elecciones L6elecciones CambioaMejor OrgulloNaranja …'

Bien, pues llegó la hora de la verdad. Vamos a hacer lo siguiente:

  1. En el menu Test options, seleccionamos Supplied test set 
  2. Pulsamos el botón “Set…”, justo al lado. 
  3. Nos aparecerá la ventana Test Instances, en ella pulsamos el botón Open File 
  4. Seleccionamos el conjunto de datos que queramos clasificar. 
  5. Ahora, nos vamos a Result list (right-click options) y haciendo clic con el botón derecho del ratón sobre nuestro modelo “meta.FilteredClassifier”. 
  6. Seleccionamos, “Re-evaluate model on current test set”



Y este es el resultado para cada una de las cuentas evaluadas.








Asoció cada conjunto de hashtags con el partido correcto, a excepción de los publicados por @sanchezcastejon. Interpretamos el valor en la celda (2,1) como que se clasifico como 1 = Partido Popular, pero el valor correcto es 2 = PSOE. Aunque bueno, según qué analista político igual podría ser un error revelador… o no. ¿Desvelará nuestro subconsciente información cuando decidimos que hashtags utilizar?, quien sabe.

Lo bueno de trabajar con la interface gráfica de Weka (Weka Explorer), es que a partir de este punto, haciendo  clic, podemos probar otros tipos de modelos, o cambiar el algoritmo de “tokenización” o modificar la configuración del entrenamiento. Las opciones son numerosas y dan mucho juego. El cambio de modelo, en este punto, es algo al alcance de  pocos clics y podría resultar divertido para el lector ver hacia donde oscila/falla la clasificación de la cuenta de Twitter @sanchezcastejon, o si hay otra cuenta que nos pueda sorprender.

Todo parecido con la realidad… y algunas opiniones personales del autor

Bien, lo primero que tenemos que resaltar es que debemos ser responsables con lo que aquí mostramos. El ejemplo funciona muy bien y es simple, pero esto es así porque detrás hay un trasfondo de experiencia en la aplicación de técnicas de aprendizaje automático a conjuntos de datos. Dicho de otra manera, desde antes del primer clic sabíamos que para ese tipo y volumen de datos, con lo representativos que son los datos de entrenamiento, la asociación tan fuerte entre estos y los de los test, el filtrado utilizado y eligiendo un modelo probabilístico bayesiano, iba a funcionar sin problema alguno hasta con los valores por defecto de la configuración.

En la práctica, cuando trabajamos con  conjuntos de información, la experiencia pasada nos ofrece cierta intuición de qué filtrado, modelo y configuración del entrenamiento es la más indicada.

El preprocesado es una etapa fundamental cuando trabajamos con text minning  y puede complicarse. A veces el texto puede ser el perteneciente a un protocolo de red basado en texto: cambiarán los separadores y las stopswords empleadas, la entropía, la tasa de ruido introducido por palabras ambiguas o incluso podemos enfrentarnos a problemas de “sobre ajuste” (“overfitting”) si hay demasiada información repetida. El preprocesado de los datos puede variar las tasas de acierto con márgenes superiores al 20%. Esto es, el entrenamiento de un modelo para text minning es sumamente sensible a las características del texto-conjunto con el que lo entrenamos. Además, en esta etapa también se recurre a normalización de frecuencias y asignación de pesos a los tokens entre otras técnicas, lo que influirá decisivamente en el entrenamiento.

El entrenamiento es otro apartado fundamental,  no hay una solución única (modelo mejor que los demás por sí mismo) y  la correcta configuración de este repercutirá de manera significativa en la calidad del modelo obtenido. La parametrización exige encontrar un equilibrio entre discriminar información repetida/ruidosa o poco descriptiva (métodos de reducción dimensional), o arriesgarnos al “sobre ajuste”, lo que se manifestará en forma de tasas considerables de error en la evaluación aislada de subconjuntos, ligeramente modificados, tomados a partir del conjunto de entrenamiento. Además, es una etapa crítica en cuanto a los recursos de que se dispongan (tiempo, potencia de computo, almacenamiento persistente, etc.).

Crear, entrenar y aplicar modelos, es fácil, sencillo y para toda la familia, que podríamos decir. Hacer que funcionen con tasas de acierto superiores al 75% requiere de mucho trabajo, la intuición también nos vale, afinar por encima del 90%-95% es todo un reto y en ocasiones resulta imposible. Aquí está la justificación del rol del “analista de datos”, que comprenda la naturaleza de los datos y el comportamiento de los modelos en distintos escenarios/problemas, ajustándose a unos recursos limitados.

Siendo honestos, es solo marketing y publicidad deshonesta cuando oímos hablar de: “inteligencia artificial aplicada a la ciberseguridad”  (combo x2 del sensacionalismo y el modismo). En investigación, investigadores (que no ciber-investigadores) llevan trabajando desde hace décadas, en el análisis de la información. Lo correcto es referirse a investigadores/analistas de datos (más corporativo/empresa), que aplican técnicas de aprendizaje automático a conjuntos de datos procedentes de todos los campos, entre ellos la seguridad informática (sin necesidad de “ciber”).

Resulta curioso ver como hoy en día, fuera de círculos de investigación, se ignora que el gran reto actual, no es “el hacer que funcione”, sino como conseguir de la manera más óptima: la configuración, la selección de características, la selección de recursos, etc., que haga que nuestro entrenamiento dé como resultado el modelo más eficaz dentro de sus límites teóricos y prácticos. Por ejemplo, aplicando algoritmos genéticos como proponen compañeros de la Universidad de Granada pertenecientes al grupo de investigación Geneura [4][5].

Conclusión
En este artículo las conclusiones las tiene que extraer el lector por sí mismo. Qué experiencia saca de “jugar” con el experimento que hemos mostrado.

A título personal creo que lo que más desluce el artículo, es en sí mismo su principal aliciente, el uso de una interface gráfica. Es difícil explicar por escrito, algo que realmente a base de clics es muy simple. Por ello queda para un próximo artículo como darle un enfoque más avanzado, mostrar cómo desarrollar con Weka desde Java y de esta manera dotar a nuestros desarrollos de capacidad de aprendizaje automático.

Referencias

[1] http://www.cs.waikato.ac.nz/~ml/weka/
[2] http://www.isecauditors.com/sites/default/files/files/tinfoleak-1.5.tar.gz
[3] http://www.vicenteaguileradiaz.com/
[4] http://geneura.ugr.es/NEW/www/index.html
[5] https://geneura.wordpress.com/members/


Autor: Juan Luis Martín
Departamento Auditoría

Internet Security Auditors patrocinador platino del X Owasp Chapter Meeting

El próximo 17 de noviembre en La Salle (Barcelona) se celebra en el X Owasp Spain Chapter Meeting, dónde se imparten una serie de conferencias, abiertas y gratuitas que reúnen, desde 2006 a los profesionales del sector de la seguridad de nuestro país y que se han consolidado como un evento de referencia.

Este año el evento contará nuevamente con la sesión formativa impartida por Fabio Cerullo y que se realizará el miércoles 16 de noviembre. El temario de la formación será el siguiente:
  • Introducción a la Seguridad de Aplicaciones Web.
  • Tecnología usada en aplicaciones web.
  • Áreas críticas en una aplicación web.
  • Inyección.
  • Cross Site Scripting (XSS).
  • Broken Authentication and Session Management.
  • Insecure Direct Object References.
  • Cross Site Request Forgery.
  • Security Misconfiguration.
  • Insecure Cryptographic Storage.
  • Failure to restrict URL Access.
  • Insufficient Transport Layer Protection.
  • Unvalidated Redirects and Forwards.
  • Secure Software Development Lifecycle (SSDLC).

Y como viene siendo tradición desde sus inicios, este año también patrocinamos esta nueva edición.

El programa se publicará en los próximos días en:
https://www.owasp.org/index.php/Spain/Chapter_Meeting

¡Nos presentamos de nuevo a los Premios Bitácoras como Mejor Blog de Seguridad Informática!

Desde 2003, la red social para bloggers Bitacoras.com entrega los Premios Bitácoras a los mejores blogs en español, y después del éxito conseguido en la edición del año pasado, este 2016 queremos volver a participar en la categoría de Mejor Blog de Seguridad Informática.

Si quieres ayudar a difundir los artículos que publicamos solo tienes que votar! Puedes hacerlo a través del siguiente enlace con tu usuario de Bitacoras.com (si tienes) o a través de tu cuenta de Facebook o Twitter:

Votar en los Premios Bitacoras.com

Internet Security Auditors organiza junto con la Cámara de Colombiana de Comercio Electrónico en unas jornadas sobre Protección de Datos

El próximo 13 de octubre se celebra en Bogotá una conferencia sobre Protección de Datos.

Internet Security Auditors tiene la oportunidad de colaborar en esta jornada junto con la Cámara de Colombiana de Comercio Electrónico. En el evento se tratarán diferentes temas, todos relacionados con la privacidad de los datos.

A continuación, el programa:
7:30 AM: Registro
8:00 - 9:00 AM: 'Aprendiendo de las Sanciones'.
9:00 - 9:45 AM: 'Habeas Data, más que una ley: la Seguridad TIC en la protección de datos'.
10:00 – 11:00 AM: 'Errores comunes en la identificación y declaración de BBDD en el RNBD.  Recomendaciones'.
11:15 AM: Cierre

Ponentes:
  • Esteban Jaramillo Aramburo
  • Daniel Fernández Bleda
  • Javier R. Amaya Madrid

Más información:
http://ccce.org.co/eventos/conferencia-sobre-proteccion-de-datos