Medida de responsabilidad

La cuantificación de medidas cualitativas siempre es un problema en cualquier métrica. Nos enfrentamos a él cuando estuvimos trabajando en la creación de una métrica de seguridad para usuarios conectados a una red WiFi. En ese proceso fuimos pasando por todos los estados posibles, que si el método Delphi, que si sistemas de scoring tipo CVSS, que si sistemas de valoración tipo DREAD, etc… Es complejo, pero… había que pringarse y elegir alguna forma de medir algo que a priori es difícil por ser un valor cualitativo.

En el tema de la publicación de vulnerabilidades se eligió el término de “responsable” para indicar cuando una vulnerabilidad se había hecho pública de forma “responsable” según los fabricantes de software. Como en muchos casos, la palabra tiene implícito un tizne tramposo en ella, pues parece que sólo hay una forma responsable de liberar una vulnerabilidad y es a través del fabricante de software.

Sin embargo, ¿Cuándo hace un fabricante de software una corrección responsable? Estas cosas ya venían rondando mucho el debate público de los investigadores de seguridad y todos los que en alguna vez nos hemos encontrado en una tesitura similar nos hemos topado con algún comportamiento pasota. ¿En esos casos es o no responsable publicar la vulnerabilidad? ¿Quién es responsable?

Muchos fabricantes, como Spectra, criticados por el uso del calificativo de “responsable” han empezado a hablar de “coordinación” entre el investigador de seguridad y la solución. Así, en muchas conferencias se libera la vulnerabilidad al tiempo que la compañía pone a disposición de los clientes un parche, una artículo con workarounds o similares.

Pero la cosa se ha revolucionado con el anuncio de TippingPoint, empresa que se dedica a la compra de vulnerabilidades a través de Zero Day Inititative, de poner un plazo para la liberación coordinada - o responsable - de vulnerabilidades de 6 meses. Ese es el tiempo que, según ellos, marca la diferencia entre parcheo responsable por parte de un fabricante y pasotismo constatado.

Sé que hay entornos que son muy complicados de parchear, pero también entiendo que 6 meses es un tiempo muy largo para que no haya una filtración de algún tipo y la vulnerabilidad llegue a oídos de “gente equivocada” creciendo el riesgo de los usuarios.

Personalmente creo que el establecimiento de algún plazo con sentido común aceptado por toda la industria, como pueden ser esos meses, haría que este debate sobre la liberación de vulnerabilidades se normalizase y que las empresas de software se tomen un poco más serio su trabajo. El establecimiento de periodos de tiempos más cortos puede ser poco realista a día de hoy, pero tal vez se debería aplicar un sistema en progresión e intentar, en un tiempo, reducir esos 6 meses de plazo poco a poco. La seguridad de los sistemas es muy importante como para que los fabricantes de software no le dediquen todo el esfuerzo que puedan.

¿Y tú qué opinas?

Saludos Malignos!