Medir Para Decidir.

¿Cuál es el objetivo de las métricas de seguridad? Medir a un control de seguridad. Ya sé, es obvio. Mejor: las métricas intentan asignar valores alrededor de actividades orientadas a proteger los recursos de información. Por ahí dicen que “las métricas de seguridad son sirvientes de la administración del riesgo, y la administración del riesgo es acerca de tomar decisiones”.

Por lo tanto: “las únicas métricas de seguridad que nos deben de interesar son aquéllas que soportan la toma de decisiones respecto al riesgo con el propósito de manejarlo o administrarlo”.

Las métricas de seguridad son un tema relativamente nuevo e inmaduro (sobre todo comparado con otros indicadores como los que genera el sector financiero, por ejemplo); es una cuestión poco explorada y escasamente dominada como bien nos dice Andrew Jaquith en su libro “Security Metrics”. Que por cierto y como podrán intuir, este post se basa en la lectura que hice de algunos capítulos del mismo (en concreto, el 2: “Defining Security Metrics”).

Las métricas de seguridad intentan medir el nivel de seguridad (o un aspecto de ella) en una corporación y por cierto el estándar ISO/IEC 27001 las exige en el sentido de contar con métricas (indicadores) para medir la eficacia de los controles de seguridad que tenemos en la organización (no todos los controles, sino aquéllos que estén dentro del alcance establecido en el sistema de gestión que propone el 27001).

Ejemplifiquemos con el control contra código malicioso (antivirus).

Una métrica podría ser “cantidad de código malicioso detectado” o “número de actualizaciones de firmas mensuales”. Ambas, aunque indican algo, realmente no arrojan un valor con valor; nos quedamos más con cara de “so what?” Aquí viene al rescate Jaquith que nos dice las 5 características que toda métrica debería de tener:

a).- Obtenidas consistentemente. Si en un momento dado se obtienen valores diferentes debido al método usado para generarlas, no estoy haciéndolo consistentemente. “Días para aplicarle un parche crítico al 50% de los servidores”: si tú generas un reporte y obtienes 13 y yo 21 días, estamos fritos. Personas diferentes deberían de seguir un mismo procedimiento para arrojar resultados idénticos.

b).- Recolectadas sin esfuerzo. Tal vez el indicador sea muy relevante y útil, pero si tienes que invertir 20 minutos durante 30 días para obtener el indicador mensual, olvídalo. Deberíamos tratar de que la obtención de la métrica sea lo más automatizada posible a través de una herramienta. Es muy importante mantener en mente que se debe de invertir mucho más tiempo en analizar las métricas y sus tendencias que en generarlas.

c).- Expresadas con un número o porcentaje. Olvidémonos del rojo, amarillo y verde. O del muy alto, alto, medio, bajo, muy bajo. Las métricas deben de ser expresadas con números cardinales, es decir, que cuenten cuánto hay de algo “Minutos sin servicio no planeados”, “Porcentaje de avance en la aplicación de X parche”.

d).- Expresadas con al menos una unidad de medida. “Bugs presentes en las aplicaciones” tiene una unidad de medida: los bugs. De hecho, si consideramos “Bugs presentes por cada 1,000 líneas de código”, vemos que tiene dos unidades: bugs y líneas de código; es decir, la hemos enriquecido.

e).- Relevantes. La prueba del fuego para una métrica es cuando pasa el test del “so what?”. Es decir: “Cantidad de troyanos detectados por mes” tal vez cumpla con el resto de características antes mencionadas, pero y luego qué? ¿Qué significa?

En enero se detectaron 12,567 troyanos, en febrero 2,456 y en marzo 7,569. ¿Se puede tomar una decisión u acción? No, esos números cuentan troyanos y la variación de cada mes se podrá deber a factores como cantidad de USB insertados, archivos bajados, periodo vacacional del personal, etc.

¿Nos dice por ejemplo qué tan bien trabaja el antivirus? No, porque me dice cuántos detectó y eso no es un buen indicador de eficacia.

Cambiemos la métrica a “Cantidad de troyanos no detectados”. Es una métrica que nos hablaría de su eficacia: si es cero o tiende a cero significa que está haciendo su labor eficazmente. Valores más altos nos dirán que no está haciendo bien su labor y podríamos tomar una decisión luego de un análisis: comprar otro antivirus, prohibir los dispositivos USB o comparar un filtrado de contenido perimetral. Ese es el poder de esta métrica: que podemos tomar decisiones en base a los valores arrojados.

Sé lo qué están pensando. “¿Cómo diablos se puede obtener una métrica de troyanos no detectados y que por lo tanto se lograron colar?” Efectivamente, ningún antivirus te va a decir ese valor. A mi gusto, es una excelente métrica relevante para medir la eficacia, pero desgraciadamente su obtención es complicada e imprecisa por decir lo menos (se podría sacar en base a avisos de los usuarios donde la evidencia haya arrojado que el antivirus no logró detener esa infección).

Otras métricas relevantes del antivirus (y que sí se puedan generar con facilidad) sería la cobertura del control (% de equipos con antivirus), o el porcentaje de equipos que cuentan con la última firma de antivirus, entre otras.

Ya por último, algunas citas célebres en torno a este tema.

Fred Cohen: “The vast majority of information security-related measurement measures what is trivial to measure and not what will help the enterprise make sensible risk management decisions”

Andrew Jaquith: “Technical security metrics should not simply be “fun facts” that tell the CSO what a great job the security team is doing. They should reveal more interesting insights such as gaps in coverage, environmental stability or problems with change controls”.

¡No Quiero Características!

¿Quién rechazaría más características en su programa favorito? Después de todo, esa es La diferencia entre las versiones antiguas y las actuales. Sin embargo, no todas las características son realmente útiles e inclusive pueden acarrear problemas de seguridad; entonces deberíamos quererlas?

Ejemplifiquemos esto de las “características” con un programa muy querido por todos nosotros: Adobe Reader. También es mi favorito pero por otra razón: su seguridad deja tanto que desear que siempre me es útil para ejemplos de inseguridad. En fin, basta de divagar. Continuemos. Adobe Reader es un programa para ver archivos PDF, pero que también es capaz de ejecutar código JavaScript.

Se preguntarán para qué un lector de archivos querría ejecutar dentro de sí mismo un programa. Lo que queremos es leer documentos con texto e imágenes, no ejecutar código con un lenguaje de programación (algo parecido a la dupla macro-Word).

Aunque lo anterior pueda sonar lógico, nuestros amigos de Adobe no pensaron igual. Y le incrustaron una característica: JavaScript. Mala idea, creo yo. Muchas de las vulnerabilidades se cuelan al Reader por conducto de JavaScript. Hagan el ejercicio de googlear lo siguiente: “disable javascript adobe security”. Habrá N referencias para deshabilitarlo precisamente porque al hacerlo le damos vuelta a las debilidades asociadas a JavaScript en el Reader (que son bastantes).

Yo empecé un ejercicio hace un mes: deshabilité JavaScript en Adobe Reader (Edición-> Preferencias-> JavaScript-> Activar JavaScript para Acrobat). ¿Y saben? Ni lo he extrañado.

Y es más, intrigado por esta situación, me di a la tarea de buscar explícitamente un PDF que necesitara de JavaScript porque se me hizo sospechoso que ningún archivo me lo exigiera. Luego de un rato buscando, encontré una calculadora dentro de un PDF. ¿Y para este tipo de cosas quiero tener JavaScript en Adobe Reader?

Aclaremos. Habrá gente que sí requiera JavaScript en el Reader para realizar su trabajo (otros como yo se tienen que dar a la tarea de buscar explícitamente un PDF que así lo demande). Pero puedo asegurar que tanto dentro de un corporativo o en los equipos de casa, esta es una característica que la mayoría NO necesita. ¿No me creen? Hagan la prueba en su equipo ahora mismo. Y luego propongan la medida a su área de TI para que bajo un esquema pausado se deshabilite. El usuario que proteste es aquel que lo necesitará y nadie más.

En otro ejemplo, uno que está lleno de “características” de este tipo es Windows. De ahí que haya hasta libros dedicados a quitarle lo delicado y bonito para volverlo fuerte y feo, por decirlo así.

El software comercial vende a través del ofrecimiento de nuevas características en sus más recientes versiones. De otro modo, los usuarios no se verán decididos a gastar su dinero y eso no es bueno para el fabricante.

Desgraciadamente, entre todas estas “nuevas y mejores” características, cuántas son realmente necesarias y útiles para un porcentaje alto de usuarios (pero inseguras)? ¿Cuántas son del estilo de JavaScript en Adobe Reader? ¿Podríamos vivir sin el autorun en los USB que es usado sin lugar a dudas para distribuir malware? ¿Qué tal JavaScript en los navegadores, podríamos sobrevivir sin él? ¿Vivir sin Flash? La respuesta la tienes tú para poder llegar a un balance entre funcionalidad y seguridad.

Full Disclosure

¿Publicar una debilidad de día cero o no? Ahí está la cuestión. El pasado 5 de junio, el investigador de seguridad Tavis Ormandy notificó a Microsoft de una debilidad en su sistema operativo XP.

Recordemos que una debilidad de día cero es aquella para la cual no existe un parche (solución) del fabricante. En fin, siguiendo con la historia, cinco días después de dar notificación, el investigador decide publicar en Internet detalles de la vulnerabilidad y además escribe código de concepto (el paso previo al código de explotación que sirve para atacar a un sistema).

Algunos puntos a considerar.

El investigador Tavis trabaja para Google. Él afirmó que su investigación es independiente de su empleador y que es un trabajo personal. Sin embargo suena raro, sobre todo después de que Google anunciara hace apenas unas semanas que dejaría de usar Windows; a raíz de la declaración hubo roces entre las dos compañías. Si las dos empresas traen “pique”, realmente es una investigación independiente? Si lo es, Tavis escogió un pésimo momento.

El señor Ormandy publicó su vulnerabilidad de día cero el jueves 10 de junio en Internet. Microsoft liberó una serie de parches el 8 de junio. En el mundo underground, esto se ha llevado a cabo para maximizar el tiempo de solución: se libera una debilidad de día cero días después del segundo martes del mes para tener un mes sin parche (si los ataques son limitados, es probable que no se emita una solución de emergencia). Extraño que Ormandy siga la misma estrategia del undergr0und.

Como mencionamos, Ormandy avisó a Microsoft de la debilidad el sábado 5 de junio y recibe notificación de recibido; el 10 sube los detalles a Internet. Darle cinco días a un fabricante para que libere un parche es francamente irreal y a mi entender no había urgencia para hacerlo. Además Ormandy afirma que tuvo que sacar código de concepto, de otra manera Microsoft hubiera ignorado su trabajo. Amigo Ormandy, ese argumento no me lo trago.

Google predica la revelación responsable (responsible disclosure) y lo expresa así públicamente. Tons, “mi no entender”. La empresa tiene una postura para cuando un investigador descubre una debilidad en su software pero no aplica para sus propios empleados? Google dice de la revelación responsable: “Permite a compañías como Google mantener a sus usuarios seguros mediante la solución de vulnerabilidades y la resolución de problemas de seguridad antes de que llamen la atención de algunas personas con intenciones poco honestas. Animamos vehementemente a todos los interesados en búsqueda y notificación de problemas de seguridad a observar los sencillos protocolos y normas de la revelación responsable”.

Todo este asunto trae a discusión el tema del full disclosure, que se refiere a publicar las debilidades y sus detalles a la comunidad para presionar a los fabricantes de software con el fin de que se apuren a desarrollar sus parches. Se dice que sólo así los fabricantes se ponen las pilas y que de otro modo se tardan muchísimo tiempo para dar solución. Esto sin olvidar que durante el tiempo que tarda la solución (parche), el software permanece vulnerable.

¿Qué hacer? Si uno es un investigador y descubre una debilidad, cuál es el camino a seguir? ¿Publicar la vulnerabilidad, esperar, avisar al fabricante, vender el bug en el underground o usarla uno mismo? Es una pregunta que no tiene una respuesta tajante y absoluta, como dicen por ahí: depende del cristal con que se mire.

En mi opinión personal, pienso que no hay que ser absolutos: ni publicar la debilidad con detalles sin darle tiempo al fabricante para responder, pero tampoco esperar pacientemente meses o años hasta que el fabricante reaccione y publique la solución. Yo seguiría este camino en general:

A).- Descubro una debilidad.

B).- Notifico al fabricante y le informo que en un mes publicaré en Internet información de la debilidad sin detalles y en dos meses daré dichos detalles acompañados de código de concepto.

C).- Guardo la información intercambiada -con fechas- para tener evidencia de lo acordado. Por si el fabricante se quiere pasar de listo y evadir responsabilidad.

D).- Cumplo lo establecido en el punto “B”.

Con lo anterior, no se le da al fabricante un tiempo ilimitado para solucionar la falla, pero tampoco me veo radical y publico mis hallazgos a la brevedad.

Como dije hace unos párrafos, el full disclosure tiene puntos de vista diversos, como los de @taviso, los de Bruce Schneier o los de usted, amable lector.

GMarketing

La semana pasada, Google anunció que dejaría de usar el sistema operativo Windows por razones de seguridad. Y es que, recordarán, al colorido gigantón le metieron gol el año pasado supuestamente algunos infelices hackers chinos que precisamente se aprovecharon de una debilidad en el software de Microsoft para llevar a cabo sus fechorías. ¿Suena lógico quitar Windows o es puro GMarketing?

Para responder, recapitulemos. Las noticias indican que el ataque se produjo debido a que ciertos empleados usaban el navegador Internet Explorer versión 6 y que de ahí se lograron colar a otras partes sensibles de la empresa. ¿¿Versión 6 de IE?? Un verdadero queso gruyere tener ese navegador ya tan viejo e inseguro y con deadlines en su ciclo de soporte.

Luego entonces, el ataque se dirigió a Internet Explorer, no al operativo (¿tons pa’ qué quitar Windows?). Y no se aprovecharon de cualquier navegador, sino de uno muy viejo; por qué no estaban usando ya el navegador Google Chrome? Sólo Larry y Sergey lo saben.

¿Windows inseguro? Sí, al igual que Mac OS X y Linux. El secreto está en la configuración (tema tratado ya en el blog) que se le haga al sistema y en los hábitos del usuario entre otras cuestiones. Pero si hablamos de software con bugs (vulnerabilidades), el que esté libre de culpa que arroje el primer bit.

Y por favor, si se usa una aplicación de hace años (IE6), ya de entrada estamos en desventaja. Agreguemos usuarios que hacen click en cuanto link les llegue y tenemos un hueco de seguridad considerable.

Sin mencionar que según el blog del corporativo, la embestida se trató de un ataque dirigido, de los más difíciles de resistir. En un ataque dirigido, el atacante se concentra específicamente en encontrar un solo hueco en la seguridad (puede ser tecnológico, humano, etc.) el cual pueda explotar; basta uno solo.

En pocas palabras, independientemente del sistema operativo, se tendría que haber tenido al 100% tanto en actualizaciones como en configuraciones (junto con sus aplicaciones). Y aún así, otro recurso del atacante es explotar una debilidad de día cero (sin solución). En efecto, si ya nos tienen en la mira, se podrá llamar Windows 7, Ubuntu, IE8 o Google Chrome, pero la probabilidad de que el ataque sea exitoso es alto (la motivación y determinación del atacante es un factor clave). Y recordemos que las vulnerabilidades no sólo son tecnológicas (¿así o más difícil?).

Por otro lado, dejar de usar Windows (por “G” razón) podría haber pasado desapercibido (lo cambian y ya), pero no, lo dieron a conocer. ¿GMercadotecnia? Tal vez, así luego se filtrará probablemente que están usando el operativo y navegador Chrome porque es “más seguro” aún que OS X y Linux (con los cuales anunciaron sustituirían Windows). Por cierto, la respuesta de Microsoft a todo esto no se hizo esperar.

Y para no dejar el tema de Google así de desabrido, les comento que en su blog corporativo se anunció hace unas semanas que las búsquedas ya podrían ser cifradas con SSL, otra gran característica. Buscar con seguridad. ¡Grandioso!

Así si un ciudadano de un Estado totalitario hace búsquedas, las podrá hacer sin ser interceptado (nuestro buen amigo chino podrá buscar datos sobre la matanza de Tiananmen). Lástima que cuando le dé click a la liga a donde desea ir, se saldrá del Google cifrado con SSL y el Gran Hermano se dará cuenta de la falta. ¿Es realmente útil la característica de buscar con SSL? ¿GMarketing para relacionar a Google con “seguridad”? Ustedes díganme.