Blockchain, por sí mismo, no es más que una implementación moderna del concepto “cadena de hashes”, autodenominada cadena de bloques. Consiste en algo tan sencillo como obtener un hash o función criptográfica resumen de un conjunto de eventos (normalmente transaccionales), de tal modo que el receptor de la transacción puede ver si los hashes concuerdan en destino y origen y, por tanto, se mantiene la integridad de la transacción. En otras palabras “que nadie ha metido mano en el proceso”.

Como supongo que os imaginareis, garantizar la integridad es realmente en muchas aplicaciones que requieren de asegurar cada paso. El mejor ejemplo serían las transacciones bancarias y, de hecho, es donde más se aplica. El problema viene cuando supuestos expertos en ciberseguridad en jornadas, desayunos empresariales, y en definitiva cualquier evento y/o “sarao” relacionado hablan y hablan de las bondades de esta “nueva” tecnología revolucionaria tiene para cualquier negocio, desde una PYME tecnológica hasta, si me apurais, una panadería.

Ante la pregunta, ¿necesito blockchain en mi negocio? La respuesta normal es un rotundo NO. No lo necesitas. Si tienes una empresa que fabrica tornillos y garantizar la integridad de tu BBDD es garantizar un excel enlazado de datos de producción recogidos a mano, es mejor que mejores tu captura de datos. Si tu BBDD está en local y no la tienes distribuidas por todo el globo, tampoco te hace falta. Y qué te igual esas supuestas bondades que “expertos” en foros están contando. No conocen ni tu negocio ni muy probablemente el concepto de cadena de hashes o alternativas – que se venían usando antes de este hype – como esquemas compartición de secretos (por cierto, inventado por un ganador del premio Turing, Adi Shamir, nada menos).

Así que ya sabéis, blockchain en bancos y procesos distribuidos críticos que necesiten una trazabilidad. Para todo lo demás, decid de primeras NO al blockchain. En algunos casos tendrán razón, pero en otros tantos no.

The post Blockchain. ¿Tecnología revolucionaria o hype? appeared first on S3lab.

Retomamos uno de los aspectos fundamentales de la vida científica: escribir contribuciones o

Como caso particular, en System Security es MUY habitual que los títulos de los artículos sigan la siguiente estructura Nombre de Broma o Referencia Pop: Nombre serio. No sé si es porque es una disciplina joven, pero es habitual encontrarse artículos con nombres de broma como Internet Jones & the Raiders of the Lost Trackers o How the ELF ruined Christmas. No es que sea algo obligatorio, pero si algo característico a mencionar.

Pero vayamos al grano, da igual lo gracioso que sea el título, si no es capaz de transmitir lo relevante de la contribución, el revisor se reirá una sola vez (o dos si es malvado). La clave para escribir bien un artículo es comenzar sabiendo cuál o cuáles son los aspectos más importantes de nuestra contribución. A partir de ahí haremos un outline de cada una de las secciones, a un nivel cada vez profundo. La premisa inicial, es que leyendo el paper se podría replicar completamente la investigación.

Después, es importante utilizar un lenguaje sencillo y con palabras sencillas: no estamos escribiendo una novela, estamos con un paper. Siendo así evitaremos frases largas y rebuscadas y siempre escogeremos la palabra más habitual para el significado que queramos. Tenemos que tener en cuenta que el Inglés es la lingua franca de la Ciencia, pero los lectores y revisores no tienen porqué ser duchos en él y menos nativos.

Por otro lado, es importante reseñar que si estamos hablando de una artículo para una top-tier conference, éstos son de mucha longitud, por lo que cuánto mayor número de apartados con títulos claros, mucho mejor para facilitar su lectura (los títulos se quedan antes en la cabeza). Además, de este modo, nos aseguramos que el revisor (que tendrá que revisar 20+ papers en dos semanas) se quede con la idea.

Por último, un aspecto importante, es que pese a que tengamos muchos datos, no hemos de volcarlos en el paper, sino extraer su relevancia y discutir sus implicaciones. Si no, volvemos loco al lector, con datos que no le interesan.

En resumen, tenemos que escribir no para nosotros, si no para los lectores del paper, teniendo claro que queremos transmitirles.

The post Investigación en seguridad (VIII) – Papers, Lenguaje appeared first on S3lab.

Pues sí, ya hemos hecho un trabajo que creemos que tiene nivel (y probablemente lo tenga) y nos llega un email con la fatídica frase “We are sorry to inform you”… Acompañada de los comentarios de los revisores.

En algunos casos tendrán razón, pero en otros tantos no. Y nos enfadamos, pensamos en mandarlo a otro lado menos “top”, pero es un error si lo hacemos. En el ciclo de las 4 top de seguridad, es relativamente común que los rechazos se conviertan en mejoras para un envío a la siguiente porque las fechas cuadran perfectamente. En cierto modo, por eso se le llama ciclo de las 4.

No obstante, a nivel mental suele costar acostumbrarse al rechazo y sobre todo, a las malas reviews. Y no me refiero a las que critican, sino a las que no tienen sentido. Aquí tenemos que recordar, que en una top conference cada revisor tiene entre 20 y 30 papers que corregir, que muchas veces la selección del tema no es correcta, o que simplemente no le ha gustado por motivos poco objetivos (al fin y al cabo, somos personas).

Como recomendación general, si el paper tiene comentarios positivos y cambios razonables, la manera de proceder, es hacer esos cambios y enviar a la siguiente de la “rueda”. Si solo tenemos comentarios negativos y es nuestro primer rechazo, podemos seguir, pero si ya hemos mandado a varias y no hay comentarios positivos, es que probablemente no esté al nivel.

The post Investigación en seguridad (VII) – El rechazo appeared first on S3lab.

Que en los Estados Unidos de América se hace (por lo general) más y mejor investigación que en el resto del mundo no es ningún secreto. Pero, ¿a qué se debe? ¿qué ocurre en Computer Science y en System Security? Y lo más importante en ¿qué se diferencian España y Estados Unidos para que en España haya muy pocos grupos publicando en top-tier conferences?

• Financiación. Creo que la más evidente es el número y los mecanismo de financiación. En EE.UU. existen muchos organismos de financiación para pedir grants. En España la financiación es escasa y los fondos Europeos son complicados de conseguir y requieren de una serie de requisitos como número de socios etc. que no son tan estrictos en EE.UU.
• Vocación institucional por la investigación. En las universidades R1 (gran actividad investigadora) americanas, la prioridad de un faculty es investigar, montar un gran equipo y publicar en los venues más importantes del área. La docencia está literalmente en un segundo plano. Y ¿cómo se sostiene eso? El faculty cobra por dar clase y tiene un salario de 9 meses (lo que duran las clases). Para los tres meses que faltan, se los puede pagar de sus proyectos. De igual modo, puede negociar dar menos clases para investigar, pagándose lo que quede de sus proyectos. La carga docente suele ser de 3 o 4 asignaturas por año (4 sería lo normal en España), pero con la diferencia que contará con Teaching Assitants que le ayudarán a dar las clases, corregir, etc.
• Top-tier conferences. Tanto para la contratación de junior faculties como para la promoción interna, se tiene en cuenta sobre todo la producción científica pero en los venues adecuados para cada área. En System Security son las conferencias de alto nivel. En España, todavía nos regimos por JCR para todas las áreas.
• Calidad VS cantidad. Mientras que España miramos el número para evaluar a alguien, en EEUU (y similares) se centran en la calidad de los artículos, y es bastante habitual que pidan opiniones a expertos externos (en caso de no tenerlos) para que evalúen la trayectoria.
• Reputación y Salarios. Por último, se paga mucho más y eso, como es evidente, atrae a gente. Del mismo modo, los estudiantes que van a las R1, saben que van a tener mejores salarios tanto en industria como en investigación simplemente por la reputación de su escuela o director de tesis.

Pese a todo esto, es de reseñar que la presencia europea en las top-tier conferences ha aumentado estos últimos años, debido en primer lugar a colaboraciones y a que bastantes instituciones europeas están viendo estas diferencias y tratando de acortarlas.

The post Investigación en EE.UU y en España appeared first on S3lab.

La estructura de un artículo experimental clásico (como suelen ser habitual en nuestra área ) sigue una estructura que se llama IMRAD (Introduction, Materials and Methods, Results, And Discussion). Si bien esta estructura no se sigue al pie de la letra en System Security (aunque sí es común hacerlo en otras disciplinas), la estructura es similar y suele contener – de forma más flexible – los siguientes puntos:

• Abstract: Se resume el paper contextualizándolo. Es importante que sea atractivo.
• Introduction: Se realiza una introducción al problema o problemas que resolvemos de lo más general hasta las contribuciones más recientes, para posteriormente hablar de nuestra solución y enumerar las contribuciones que realiza sobre el estado de arte. Posteriormente se suele incluir (si entra por límites) un párrafo sobre de qué se habla en cada sección
• [Background]: Cuando el tema o el problema del que nos encargamos es muy específico y hace falta explicaciones que no pueden hacerse en otro sitio, incluimos esta sección. En función de lo que expliquemos también puede llamarse Problem Description o Preliminaries.
• Descripción del método: Con un nombre ad hoc para cada paper y en función del tipo de contribución técnica que tengamos (no es lo mismo un measurement paper que un contribución técnica pura) describiremos en detalles nuestro método, incluyendo para ello tantas subsecciones como haga falta.
• Evaluación o similar: En esta sección, describiremos cómo vamos a medir nuestra solución, los resultados obtenidos y que significan. Si el artículo es un measurement, detallaremos los obtenido en nuestras observaciones. Si existen casos muy específicos que queremos detallar más, incluiremos una sección Case Studies para ello.
• Discussion: Pese a que los resultados sean claros, si tenemos espacio es bueno incluir una sección que suba nuestros descubrimientos a nuevos retos de investigación.
• Related Work: Se describe el trabajo relacionado comparándolo con el nuestro.
• Conclusions: Simplemente cerramos la contribución enumerando de nuevo lo más relevante de la contribución (si no hemos hecho discussion, podemos incluir aquí una versión más reducida de la misma).

Y esa es (no hay que tomársela más que como una guía) un tipo de estructura muy utilizada. El orden de escritura suele ser primero las secciones de meat (método y evaluación) y acabar con introducción, conclusiones y abstract, porque pueden variar. En el siguiente entrega hablaremos sobre cómo escribir desde el punto de vista del tipo de lenguaje.

The post Investigación en seguridad (VI) – Papers, Estructura appeared first on S3lab.

1. Elegir un tema que no nos atrae demasiado. El mayor error que podemos cometer en una investigación (doctoral o no), es elegir un área y un tema que no nos guste. La investigación no es un trabajo (o no debería serlo) de 9 a 5, es algo que nos tiene que obsesionar y apasionar hasta el punto de perder la noción del tiempo. Si elegimos de antemano un tema del que lo más que pensamos está por debajo o igual de la expresión “No está mal”, hemos cometido un gravísimo error. Puede que, si somos estudiantes de doctorado, acabemos la tesis doctoral, pero no haremos investigación de primer nivel porque requiere un nivel de compromiso que sólo se puede obtener si hay vocación. Los motivos para hacer esto son variados y el más común es el de disponibilidad y no querer mudarse y hay que evitarlos.
2. No hablar/discutir/pelear con el director de tesis/supervisor. Como ya comentamos en la primera entrega, nuestro director de tesis tiene que reunir unas ciertas características que garanticen que se implique en nuestra investigación. Ahora bien, como doctorandos tenemos la obligación de tratar de aprovechar su experiencia y eso pasa por discutir y hablar todos los aspectos de nuestra investigación en curso. Y, desde luego, si en algo no estamos de acuerdo, no simplemente aceptarlo, explicar motivos y discutir. De esas discusiones van a surgir nuevas ideas, del silencio y la servidumbre, no.
3. No querer escribir. Es bastante común en Computer Science, que nos encante la parte más técnica, pero que odiemos las tareas de escritura. Sin embargo, como científicos, vamos a tener que escribir para comunicar nuestros resultado. De hecho, si en nuestra carrera conseguimos un puesto de faculty con un grupo, vamos a tener que escribir aún más: apuntes para clase, research grants, informes varios, etc.. Por esta razón, es importante que, desde el principio vayamos cogiendo soltura en la escritura y, quien sabe, hasta nos comience a gustar (o al menos no la odiemos). Suelo dar el consejo de que leer muchos artículos científico de nivel, pensando como un revisor porque así podemos ver aciertos y errores en la escritura que hacen que nos guste o no el artículo y, así, sepamos valorar una escritura clara y ordenada.
4. No llevar registro de lo que se está haciendo. Cuando estamos realizando una contribución de primer nivel, es normal realizar una gran cantidad de pasos y selecciones que luego en nuestro artículo científico tienen que estar justificados. Como, en ocasiones nos llevará mas de 8 meses de esfuerzo, es muy normal, que lo que nos parecía tan obvio hace 3 meses, ya no recordemos por qué lo hicimos. Por eso, hay que llevar registro de todo lo que se hace y la razón por la que se hace. Pese a todo, es probable que, aún llevando registro, alguna cosa se nos pase y tengamos que volver atrás.

Existen más errores que podemos cometer, pero éstos son los que nos llevarán al fracaso absoluto. En la siguiente entrega hablaremos de cómo escribir una contribución y de su estructura.

The post Investigación en seguridad (V) – 4 errores, 1 fracaso appeared first on S3lab.