Cinco razones de por que asistir a Usenix Security

La semana pasada asistí a la 19ma versión de la conferencia USENIX Security. En la misma se presentaron 30 documentos de investigación (papers), se ofrecieron charlas de especialistas de la industria sobre seguridad y permitió que sus asistentes intercambiaran opiniones y comentarios sobre los problemas más actuales en seguridad informática. También una que otra oportunidad para disfrutar de una buena cerveza... :)

En mi opinión, esta es una de las mejores conferencias de seguridad informática que presenta el estado de arte en varios de los temas más actuales de seguridad informática, desde el punto de vista de un investigador y de la industria. En otras palabras, la conferencia está orientada a investigación aplicada. Además, la conferencia posee dos pistas simultáneas (double track). En una de las pistas se presentan los 30 papers que pasaron exitosamente el proceso de evaluación por terceros (peer review), mientras la otra pista contiene exclusivamente charlas de especialistas de la industria en seguridad informática. Esta última incluyó este año a expertos en seguridad de Microsoft (comparando la seguridad de Unix con Windows), Adobe (seguridad en Flash) , Google (seguridad de ChromeOS) y Mozilla (seguridad en Firefox). Durante mi asistencia a la conferencia, sentí que debía aprovechar cada minuto de la misma debido a la gran cantidad de temas interesantes y bien presentados, así como a la excelente oportunidad de conversar con expertos y colegas.

He aquí cinco razones por las que vale la pena asistir a la conferencia Usenix Security:

1. Oportunidad de conocer trabajos de investigación con potencial para convertirse en productos de ingeniería. UsenixSec es sobre investigación aplicada por lo que la validez de una idea e investigación depende de su aplicación en la industria. En la conferencia, expertos provenientes de industria y academia dieron su evaluación sobre el trabajo presentado e incluso realizaron comparaciones con otros trabajos/productos similares.
2. Si eres estudiante o profesor de primer año, oportunidad de conseguir fondos para asistir. Usenix ofrece becas para asistir a sus eventos, incluyendo a UsenixSec. El proceso para aplicar es fácil y se puede realizar en línea. Yo llené toda la información en cuestión de días (ya que debes hacer un ensayo, así que me tomé el tiempo para revisarlo y corregirlo). La beca que me otorgaron cubrió el 70% de mis gastos.
3. Participar en pista de charlas de la industria. Escuchar a los especialistas que están decidiendo e implementando los mecanismos de seguridad en los productos utilizados hasta por cientos de millones de personas, no tiene precio. En la conferencia de este año habló Crispin Cowan sobre los avances en seguridad de Unix y Windows en los últimos 10 años. Cowan es una de las pocas personas, en mi opinión, que puede hacer una comparación objetiva ya que ha desarrollado varios programas de seguridad para Unix para luego ingresar a Microsoft en 2008.
4. Oportunidad para conversar con verdaderos expertos de seguridad que asisten anualmente. Este año asistieron expertos como Steven Bellovin, Bill Cheswick, Simson Garfinkel, Farnam Jahanian, Chris Kruegel, Wenke Lee, Peter Neumann, Niels Provos, Avi Rubin, Chris Schuba y Robin Sommer. En cada una de las actividades sociales de la conferencia (breaks, sesiones de poster, cena, etc.) se tiene la oportunidad de conversar con ellos y debo añadir que la gran mayoría siempre está muy dispuesto a conversar. Por ejemplo, hablé con Bellovin sobre la mal ganada fama de los PKI (algo de lo que comentaré después aquí) y con Sommer sobre el futuro del sistema de detección de intrusos Bro. Las opiniones ofrecidas por cada uno, demuestran el conocimiento profundo que tienen en seguridad informática.
5. Oportunidad para conocer otros colegas de la seguridad informática y darte a conocer. Mientras se es estudiante de investigación (MSc y PhD), resulta muy interesante y divertido conversar y convivir con otras personas que están pasando por la misma experiencia y tienen intereses similares. Esta podría incluso ser la razón más importante por la que un estudiante debe asistir a conferencias como Usenix Security. Las primeras cuatro razones sólo mejoran la experiencia exponencialmente... :)

La lista no es exclusiva y existen razones adicionales que uno podría también mencionar. Por ejemplo, conocer la ciudad de la conferencia y participar en los workshops que ocurren antes y después de la conferencia. Este año el evento fue en Washington, DC, EEUU, una ciudad con un sistema de metro muy fácil y conveniente de utilizar. Una de las estaciones del metro estaba a lado del hotel de la conferencia. Además, Washington posee un sin numero de museos y lugares a visitar, la mayoría de los cuales son gratuitos. Por otro lado, se realizaron siete workshops en Usenix Security. Incluían temas como voto electrónico, experimentación en seguridad y tecnologias ofensivas. En varios de los workshops, los estudiantes podían también aplicar a becas que cubren parcialmente los costos.

Si no estás convencido del potencial y ventajas que ofrece Usenix Security, es porque no trabajas en seguridad o yo hice un mal trabajo en vender la conferencia. Es una de las mejores conferencias de seguridad a las que he asistido. De seguro la mantendré en mi radar para no perder la oportunidad de asistir en próximos años.

Cómo evaluar/medir las vulnerabilidades y a cuáles debo prestarles atención primero?

Ningún software está libre de fallas o vulnerabilidades de seguridad, es una realidad de la que nadie que administre computadoras se escapa. Recientemente se publicó el documento científico"Beyond Heuristics: Learning to Classify Vulnerabilities and Predict Exploits" en la conferencia KDD 2010 y cuyo autor principal es Mehran Bozorgi. El documento presenta el uso de una técnica de aprendizaje de máquinas llamada Linear SVM para determinar la posibilidad que una vulnerabilidad de seguridad sea implementada (lo que se conoce como crear un exploit). Esta técnica busca ayudar a los administradores de sistemas, quienes tienen que decidir a cuales vulnerabilidades prestarles atención primero debido a la gran cantidad de anuncios que aparecen a diario sobre fallas de seguridad. En los últimos 8 años se han publicado en promedio más de 140 vulnerabilidades por semana. Aun cuando no todas aplican a un sistema informático en particular, el número de publicaciones que debe revisar un administrador de sistema sigue siendo alto debido a la naturaleza heterogénea del sistema (está compuesto de distintos programas, cada uno con sus propias vulnerabilidades).

El documento apunta a una pregunta que ataca a todo profesional de seguridad informática: cuán importante es la experiencia para resolver problemas de seguridad, especialmente en esta área que carece de principios de diseño y modelos matemáticos robustos y que demuestra estar en sus primeras fases de desarrollo? El área de aprendizaje de máquinas por el contrario se basa principalmente en realizar análisis estadístico sobre conjuntos de datos (datasets) que permitan dar respuestas, sin necesidad de depender en la opinión de "expertos" (aunque también existen métodos estadísticos que aprovechan esta información). Los resultados presentados por Bozorgi y sus compañeros son promisorios, comparando su técnica con un método heurístico y popular en la comunidad de seguridad: el métrico CVSS.

En el año 2004, como miembro del equipo de seguridad informática de la Autoridad del Canal de Panama (ACP), nos enfrentamos al tema de como manejar la creciente ola de reportes de vulnerabilidades que recibíamos semanalmente. Nuestra solución fue completamente heurística, basándose en un sistema de puntaje similar al CVSS (antes de que ellos hicieran lo mismo :). Aunque no tan elegante como CVSS, nuestra solución era de fácil implementación y uso.

La parte medular del sistema de ACP era el cuestionario utilizado para evaluar cada nueva vulnerabilidad. Por cada respuesta afirmativa, se asignaba un puntaje a la vulnerabilidad. El puntaje oscilaba entre 0 y 10 puntos y dependiendo del puntaje total se clasificaba la vulnerabilidad como critica (7 a 10 puntos), alta (5 a 6), moderada (3 a 4) y baja (0 a 2). Dependiendo de esta clasificación, se determinaba si debíamos informar a los administradores de sistemas o no. He aquí el cuestionario y puntaje por pregunta afirmativa:

1. Afecta a recursos de alto valor? 1 punto
2. Afecta la infraestructura de red (ej. conmutadores, murallas de fuego, DNS)? 1 punto
3. Afecta a un producto ampliamente usado o instalado en la ACP? 1 punto
4. Afecta instalaciones por defecto de un producto? 1 punto
5. Existe código disponible públicamente que aproveche la vulnerabilidad o está siendo ejecutada ampliamente en el Internet? (ej. virus) 1 punto
6. La vulnerabilidad se puede acceder remotamente? 1 punto
7. La vulnerabilidad se puede acceder sin credenciales? 1 punto
8. Se han publicado detalles técnicos de la vulnerabilidad? 0.5 punto
9. El resultado permite acceso administrativo o con privilegios? 1 punto
10. Se requiere de ingeniería social (ej. visitar un sitio, hacer clic sobre un enlace web) para aprovechar la vulnerabilidad? 0.5 punto
11. Existen registros de auditoria en la ACP que demuestran intentos o ataques utilizando la vulnerabilidad? 1 punto

Los resultados fueron alentadores. En el 2004, sólo enviamos 5 alertas de 54 vulnerabilidades reportadas en productos Microsoft y utilizados en la ACP. Sin embargo, los valores seleccionados para cada pregunta carecían de base científica y se basan exclusivamente en la opinión consensuada del grupo que desarrolló el documento. Además, el documento de Bozorgi sugiere que se pueden obtener mejores resultados si se utiliza técnicas de análisis estadístico.

El área de aprendizaje de máquinas sugiere implícitamente que una persona nunca puede vencer al mundo, en términos del conocimiento que cada uno puede aportar. En otras palabras, no importa cuan inteligente sea un ser humano para resolver un problema, el mundo real puede darnos una mejor solución. En el caso de las vulnerabilidades, las soluciones humanas son la de la ACP y CVSS, mientras que la solución basada en Linear SVM es la del mundo real. La razón por la que esta última es la del mundo real es que utiliza el registro de las características de cada vulnerabilidad reportada desde el anyo 2001 (un largo periodo) y realiza un análisis estadístico sobre este registro. O sea, toma una postura imparcial sobre los datos que se le presentan, a diferencia de la tabla de la ACP en donde a priori se le da mayor peso a cierto tipo de información (por ejemplo, la pregunta 1 tiene mayor valor que la pregunta 8).

Abajo aparece una tabla con algunos de los resultados presentados en el documento:

Fuente: Bozorgi, et al.

La primera columna indica el número de días (t) utilizados para determinar la factibilidad de que una vulnerabilidad sea explotada/implementada luego de t días. La segunda y tercera columna indican el número de casos positivos (|P|) y casos negativos (|P|) utilizados para entrenar el modelo. La cuarta y quinta columna indican los resultados de utilizar el método heurístico CVSS y de Linear SVM respectivamente, para determinar la factibilidad de implementación de la vulnerabilidad. Como puede observarse en cada renglón, los valores de la quinta columna son superiores a los de la cuarta.

Les recomiendo leer el documento de Bozorgi ya que es un excelente documento para aprender más de la técnica propuesta y también un buen ejemplo sobre como presentar resultados en una publicación científica. Al leerlo, uno puede determinar que la técnica propuesta posee limitaciones. Para comenzar, la técnica sólo busca determinar cuan rápido será implementada una vulnerabilidad. Mientras tanto, los métodos de ACP y CVSS buscan determinar cuan peligrosa es una vulnerabilidad (lo que no solo depende de si la vulnerabilidad ha sido implementada o no). Adicionalmente, en el sitio web del proyecto no está disponible (al momento de escribir este artículo) el dataset utilizado para calcular los valores presentados en el documento. Esto impide que uno mismo puede validar los resultados. Al final, los autores del documento sugieren que se utilicen técnicas estadísticas como complemento a las técnicas heurísticas. Esto será más viable a medida que continua nuestra uso y dependencia en sistemas informáticos, lo que generará más y mejores grupos de datos para ser analizados con técnicas como Linear SVM.