Tengo una debilidad

Existe un debate acerca dela conveniencia de publicar vulnerabilidades. Para algunos, esta publicaciónsólo sirve a los cracker, y no mejorala seguridad de forma significativa. Su posición se ve reforzada por el granaumento de ataques que suele haber poco después de la publicación de unavulnerabilidad. Para otros, la publicación es el único medio de conseguirresolver el problema, y lo que para el descubridor del fallo es muy importante,obtener reconocimiento por ello.

El concepto devulnerabilidad se define de forma ligeramente distinta según el glosario queelijamos. Una definición frecuente considera la vulnerabilidad como laprobabilidad de sufrir un determinado ataque en un plazo de tiempo dado. Paraconocer la probabilidad matemáticamente es necesario conocer el número de casosfavorables y el número de casos posibles. Faltando esta información no esposible calcular la probabilidad, con lo que la vulnerabilidad serádesconocida.

Este no es el único defectopráctico del concepto de vulnerabilidad, dado que para que una probabilidadconocida tenga capacidad predictiva, es necesario que las condiciones nocambien y disponer de una cantidad suficientemente grande de casos. Ante laescasez de información y dadas la complejidad de comportamiento de losatacantes y de las organizaciones que utilizan sistemas de información, esaventurado suponer las condiciones como constantes.

Como hemos visto, cuandodecimos vulnerabilidad en realidad queremos decir debilidad, que es laposibilidad, cualesquiera sea la probabilidad, de un ataque. Dado que eltérmino debilidad apenas se utiliza, usaremos vulnerabilidad como si fuera susinónimo.

Cuando se publica unavulnerabilidad, aumenta el número de potenciales atacantes con conocimiento,medios y motivación para traducirla en ataques. A corto plazo esto lleva a unaumento de los ataques relacionados. Cuando se publica su corrección, el númerode posibles objetivos va disminuyendo según se aplica esta. Gracias a lapublicación de la corrección, llega un momento en que el número de sistemasvulnerables es cero, y se cierra la ventana de oportunidad. Sin embargo, cuandouna vulnerabilidad no se publica, la duración de la ventana de oportunidadpuede ser tanta larga como quiera el descubridor. Si bien el número de ataquesa corto plazo es inferior, a largo plazo la ventana de oportunidad no secierra, y todos los sistemas vulnerables continúan teniendo una puerta traseraabierta para el círculo conocedor de la vulnerabilidad. La seguridad poroscuridad lleva a largo plazo a que no podamos prepararnos para detectar ycontrarrestar los ataques contra nuestros sistemas.

El descubridor del defectopuede ser, bien un auditor de sistemas de información contratado, bien un hacker que busca el defecto, o bienalguien que lo descubre por casualidad. A menos que seamos un auditorcontratado, la actitud más segura actualmente es no hacer nada, de este modoevitaremos ser acusados de cualquier delito. Hay que recordar que si no hemossido contratados, no es asunto nuestro. Si un vecino nos dejara una nota allado de la foto de nuestra familia diciendo: “He estado probando tu sistema dealarma, y la verdad es que es penoso”, seguramente sentiremos más ira queagradecimiento. Debido a esto, a menos que conozcamos la actitud de unaorganización ante el descubrimiento de fallos en sus sistemas mediante suadhesión a un proceso estándar, no es buena idea ponernos en contacto directocon ellos. Si queremos avisar de todos modos, es mejor hacerlo de formaanónima.

Y aquí llegamos al dilema desiempre: hemos descubierto un problema en un producto, sabemos que sería deinterés general corregir el problema, y además nos gustaría ser admirados pornuestro descubrimiento. Pero si el fabricante nos ignora, va contra nosotros, oincluso intenta silenciarnos la situación puede ir a peor, especialmente paranosotros. Luego hay que elegir: Avisamos anónimamente, les damos un tiempo paracorregirlo, y por último lo revelamos, o bien contactamos directamente conellos y nos arriesgamos a que nos echen a los leones.

La carencia de un proceso depublicación de vulnerabilidades ha llevado a dificultades tanto para losadministradores de sistemas, como a los fabricantes, como a los hacker que descubren vulnerabilidades.Una asociación de fabricantes, la Organization for Internet Safety ha propuestorecientemente un proceso formal que pretende resolver esta carencia, evitarconflictos y proteger los intereses de todos los participantes.

Si bien es un procesoorientado a la publicación de vulnerabilidades en productos, es fácilmenteadaptable a las vulnerabilidades de sistemas.

El proceso sigue lossiguientes pasos:

·Descubrimiento: el descubridor encuentrauna posible vulnerabilidad.

·Notificación: el descubridor contacta conel fabricante, se acuerda el procedimiento de resolución.

·Investigación: el fabricante colabora conel descubridor.

·Resolución: se acuerda una corrección losplazos de publicación.

·Publicación: eldescubridor y el fabricante publican conjuntamente la vulnerabilidad, junto consu corrección.

Una vez que se llega alacuerdo del uso de este proceso preestablecido, el proceso contempla laresolución de los conflictos que puedan surgir.

Como hemos visto lasvulnerabilidades deberían hacerse públicas, en beneficio de todos. La mejorsolución para que esta publicación se haga con el mínimo riesgo para los afectados,para los descubridores, y para los administradores y fabricantes sería queestos últimos hicieran pública su postura acerca del descubrimiento devulnerabilidades en productos o sistemas, sea esta «me adhiero a talprocedimiento», «no quiero saberlo», o «como me entere, tela cargas».

Con todos los problemas que a veces conlleva,gracias a la publicación de vulnerabilidades, cuando nos sistemas nos cantan:“Tengo una debilidad”, como en el cha-cha-cha, tenemos la oportunidad de correra corregirla. Y ya estamos metidos en el infierno del parcheo. Pero eso esobjeto de otro artículo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *