Implementación del DNSSEC y algunas expectativas falsas sobre el PKI

El 15 de julio pasado se llevó a cabo la ceremonia para implementar las extensiones de seguridad al protocolo DNS, conocidas como DNSSEC, en los servidores . (punto) del Internet. DNSSEC utiliza una infraestructura de llave pública (PKI) para su implementación y operación. El impacto y beneficio de DNSSEC es mundial, lo que también demuestra el valor que posee la tecnología PKI. La razón por la que menciono el rol de esta tecnología es que como profesional de la seguridad informática he participado en proyectos que han utilizado PKIs y observado al mismo tiempo como se ha mal ganado una reputación negativa en el camino. La implementación de DNSSEC es evidencia de como PKI puede ser una excelente solución, siempre que se haya identificado apropiadamente el problema para el cual funcionará.

DNSSEC es un conjunto de especificaciones que ayudan a mejorar la seguridad del protocolo DNS, utilizado para traducir los nombres que escribimos en nuestros navegadores web a las direcciones utilizadas por las computadoras (por ejemplo, www.utp.ac.pa debe ser traducido a 168.77.99.19 para que un navegador web visite el sitio de la Universidad Tecnológica de Panamá o UTP). Esta traducción ocurre luego que el navegador hace la consulta a otros servidores de DNS. El problema es que esta consulta se hace sin ser autenticada, lo que podría resultar en la falsificación de resultados y la eventual visita del navegador a un sitio equivocado (siguiendo el mismo ejemplo, visitar un sitio falso en lugar de la UTP. Imagínese lo que esto significaría para los estudiantes que van a pagar su matrícula en la UTP y terminan enviando el dinero a un sitio falso). Aquí es donde DNSSEC viene al rescate. DNSSEC permite autenticar la fuente de las traducciones de nombres a direcciones (y viceversa) antes de visitar cualquier sitio. Si una fuente no es legítima, de acuerdo al PKI utilizado por DNSSEC, se previene que el navegador visite el sitio malicioso (o no autenticado).

La tecnología PKI ha sufrido de una mal ganada fama durante más de una década, al punto que varias personas cuestionan su utilidad. En lo personal creo que la implementación de DNSSEC es un excelente ejemplo de porque el PKI es un valioso recurso para mejorar la seguridad de los sistemas informáticos, cuando es bien implementado y se tiene una clara imagen del problema a resolver (y por ende del rol del PKI).

La mala fama de la tecnología PKI proviene principalmente de la época de la revolución del .COM. En aquellos tiempos se pensaba que el PKI (o los certificados digitales generados por estos) era todo lo que se necesitaba para garantizar la seguridad de los sitios web. Otra razón de la mala fama es que se pensó que los PKI podían resolver todos los problemas (algo parecido al concepto de "un sólo tamaño para todos" o "one size fits all").

Al reventar la burbuja del .COM también reventó la confianza que se tenía en la tecnología PKI. Realmente no había mucho que se pudiera hacer, excepto darle tiempo al tiempo, ante las altísimas expectativas que habían por la revolución del .COM y consecuentemente por la tecnología PKI. Por otro lado, la idea de utilizar el PKI como una solución"one size fits all" todavía persiste, aunque no tan insistente como hace algunos años. Hace casi una década atrás, existieron leyes sobre el tema en países como Panama y Colombia, que decretaban instituciones a nivel nacional para manejar de forma exclusiva el tema de los certificados digitales (y por ende, de los PKIs). Hoy en ambos países ya se han derogado estas leyes, pero en algunos casos todavía persiste la idea de implementar PKIs nacionales utilizando mecanismos legales inferiores.

Entre 2003 y 2004, tuve la oportunidad de participar en la implementación del primer PKI en la Autoridad del Canal de Panamá (ACP), en el proyecto de recolección de datos para tránsito de naves. El PKI implementado fue diseñado para suplir necesidades específicas de este proyecto, firmar documentos electrónicos y establecer una red de confianza entre todos los participantes del sistema de recolección de datos. Aunque su diseño también incluyó su posible rol como autoridad certificadora raíz para otros proyectos, se mantuvo el diseño e implementación original. Luego de más de seis años, el PKI ha cumplido con su rol inicial y es para mi una muestra del uso de la tecnología para resolver apropiadamente un problema para el cual estaba diseñado y respondiendo a una institución (bajo la misma administración, facilitando su implementación).

Aunque en una ceremonia mucho más modesta que la realizada para la implementación de DNSSEC, la generación de la llave para proteger el servidor raíz fue realizada por el personal de Seguridad Informática de la ACP (Juan Chong, Eduardo Thomas y yo), el consultor del proyecto Tan Chee Young, y los ingenieros Francisco Loaiza y Edwin Reina (director y sub-director del Departamento de Informatica en aquel momento). Abajos unas fotos del momento (histórico?):

Figura 1. Generación de la llave privada para el servidor raíz del PKI utilizado en ACP, el 15 de enero de 2004. De izquierda a derecha: el autor, Francisco Loaiza, Edwin Reina, Juan Chong, Tan Chee Young y Eduardo Thomas.

Figura 2. Entrega de los "tokens" con parte de la llave privada del servidor raíz, entregadas al director
y sub-director de informática (pero almacenadas en un lugar seguro y secreto :)

El proyecto DNSSEC apenas ha comenzado y junto al PKI utilizado no están libre de dificultades, al igual que el PKI de la ACP. Pero ambos casos (cada uno en su justa dimensión) permiten demostrar claramente los beneficios que ofrece la tecnología PKI.

Hay mucha más información sobre el tema de seguridad en DNS y DNSSEC. Si deseas conocer sobre ataques de seguridad a los protocolos DNS, estos son conocidos como "DNS cache poisoning". Detalles sobre la implementación de DNSSEC y el PKI correspondiente están disponibles en: (1) registro completo (con videos) del proceso de firma de los servidores raiz, (2) arquitectura utilizada en DNSSEC para la generación y protección de llaves criptográficas, (3) compendio de documentos sobre el tema, (4) como participar en el proyecto y (5) el rol en el proyecto DNSSEC del Registro de Direcciones de Internet para América Latina y el Caribe, LACNIC. La antigua y actual leyes sobre PKIs de la República de Panamá están disponibles aquí: Ley 43 de 31 de julio de 2001 y Ley 51 del 22 de julio de 2008. Más información sobre el esfuerzo del Gobierno de Panamá de promover el uso de PKIs y certificados digitales está disponible en el sitio de la Dirección de Comercio Electrónico del Ministerio de Comercio e Industrias.

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.