viernes, agosto 06, 2010

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!

10 comentarios:

Txema Tools dijo...

HP se encontró con Tippingpoint en el paquete de 3COM, si esto es una muestra del apoyo a esta gran herramienta, una vez fagocitada por este diplodocus de la informática, bienvenida sea.

Ya entrando en el asunto, en tnato en cuanto no aparezca una acción coordinada con varios grandes, que arrastre por presión mediática a los demás, esto no tiene visos de prosperar. Mover a elefantes sin que estos quieran es algo improbable.

Seis meses es un periodo de tiempo muy razonable, considerando que hay bugs realmente difíciles de corregir, al forma parte de funcionalidades básicas de los SO o de las aplicaciones.

CentOS dijo...

uf fue leer tu post y venirseme a la cabeza palabrejas como magerit, cramp y todas esas metodologías turbias de estudio y gestión de riesgos en it,que casi me salen canas en su momento, dios me libre de esos tinglaos otra vez..

6 meses me parece demasiado tiempo, lo suyo es que haya consenso para ir bajándolo, pero también tenemos el problema de la gestión de los recursos (aka monos picacódigo) que no den abasto, al menos en mi empresa no siempre se puede hacer ni siquiera en 6 meses una correción severa de algún "problema/cagada" , ni contratando mas gente a precios de risa en países mas baratos.

Poco realista bajarlo? puede, pero necesario a todas luces, veremos como progresa todo, que las grandes no han movido ficha todavía..

Saludos!

Wi®

Anónimo dijo...

Pues depende. 6 meses puede ser mucho tiempo en casi todos los casos, o poquísimo en otros.

tmeto dijo...

Para fallos muy gordos que requieran de revisiones del sistema completo 6 meses esta bastante bien, pero para los cientomiles de fallos que salen todas las semanas, 6 meses creo que es una exageración. Habrá empresas que prefieran parchear en cuanto salga el fallo y tengan solución, otras 1 vez al mes en parches acomulativos y otras pues prefieran esperar a sacar nueva versión...por eso ponerse de acuerdo en plazos...jodido.

De todas en las empresas medianas o pequeñas que se dedican a desarrollar ....como dicen por aquí o se sub-sub-sub-subcontrata o se apaña el tema para apilando becarios uno encima de otro...así por lo menos se vive en mi empresa...aquí la seguridad es el que esta en la puerta del edificio.

fossie dijo...

Yo creo que seis meses es demasiado tiempo ya que como ya han comentado la gran mayoria de vulnerabilidades detectadas son "chorradillas" pero que pueden hacer mucho daño. Esta claro que si la modificación supone rehacer medio sistema operativo pues si que habra que esperar seis meses o más pero si se trata de una simple injección sql en una página web me parece una burrada de tiempo.

Por ejemplo, una tienda online sirve sus pedidos en plazos de 24/48 horas asi que tiene gente capaz de hacerlo ¿pero si se trata de "parchear" la tienda online hacen falta seis meses?

Creo que hay mucha burocracia en todo esto y hay tiendas online pequeñas pero con muchas ventas que realizan las correcciones en plazos más que razonables (una semana o dos) y otras que no es que pasen de solucionarlo pero van pasando la pelota de un "departamento" a otro y al final tardan más de la cuenta.

Hace poco me topé con un problema en una web de una comunidad autonoma, reporte el fallo y fué alucinante ver que en el email que me enviaron para informarme que lo solucionarian estaban todas las direcciones de email (y comentarios) de todas las personas por donde habia pasado mi email original. Hasta 6 personas pasaron la "patata caliente" hasta dar con el "picacodigo" que le toco solucionarlo.

Jaime Dominguez dijo...

No soy experto en seguridad pero opino que deberia crearse una metrica sencilla que puntua a las empresas.

Tiempo Maximo 6 meses? ok. Tenemos que 6 meses = 0 puntos de reputacion/carisma/whatever.

Parcheas en 1 mes? 5 puntos.
La vulnerabilidad era fastidiada? +10 puntos.

En cuanto haya un verdadero ranking de empresas que se preocupan y que empresas que pasan veremos lo que les pasa a sus cotizaciones en bolsa.

Yo creo que tocarles a los inversores de esta manera sera la unica manera en que las empresas se preocupen seriamente por este tema.

itilapesta dijo...

jaime quillo.. que son esto los pokemon? leete algo de novela, las metodologias serias de estas cosas llegan a un ratio de dificultad de implementación que te puede dejar tonto mirar para algun documento.. magerit, hypercube,etc.. que ponia @centos eran la pesadilla en su momento, pero seguro que la han actualizao o puesto otra que dupliqe la carga sobre los pobres sysadmins (or whatever it do)..

svoboda dijo...

Está claro que lo ideal sería que al encontrarse una vulnerabilidad, la empresa/entidad/gente a cargo de ella se volcará en su resolución con los recursos necesarios para su solución, y que el tiempo de solventarla sea mínimo. Ahora bien, esto sería la utopia.

Lo de los 6 meses, bueno, no está mal si es el principio de un intento de regularización que sigue adelante. Si no, meter todas las vulnerabilidades en un saco de 6 meses es demasiado genérico. Hay vulnerabilidades muy fáciles de arreglar y que pueden causar grandes problemas y a la inversa también.

Lo ideal, a grandes rasgos, sería que el tiempo máximo de reparación una vulnerabilidad salga de una relación más o menos directa entre la gravedad de esta y la cantidad de esfuerzo que se necesita para repararla, intentando tener un límite máximo (de 6 meses por ejemplo) excedible solo en contadas ocasiones.

Pero bueno, como principio, si es un principio, no está mal.

LeGNa dijo...

Tal como dice @svoboda, como principio no está mal pero me quedan dudas...
En vista de como trabajan los desarrolladores (todo a última hora), si el plazo máximo fuesen esos 6 meses, cuando se pondrían las empresas a intentar solucionarlo? a los 5 meses? :S

Anónimo dijo...

LeGNa, tu comentario me ha recordado la política de trabajo de una empresa en la que trabajé.

En esa empresa había dos procedimientos de trabajo: El Urgente y el Normal.

El Procediento Urgente consistía en hacer la cosas ya, a toda prisa, y con el mínimo trabajo para cubrir el expediente.

El Procedimiento Normal consistía en esperar a que fuera necesario aplicar el Procedimiento Urgente.

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares