Los empleados deciden en qué idioma publican sus entradas.
Puedes encontrar más contenidos seleccionando el idioma inglés en el enlace superior.

Full-disclosure vs responsible disclosure. Siguiente capítulo

1 Malo2 Mejorable3 Normal4 Bueno5 Excelente (Votos: 1. Media: 5,00/5)
Loading ... Loading ...

Autor: David Barroso

La eterna discusión entre full-disclosure vs responsible disclosure tiene un nuevo área relativamente reciente: la protección de infraestructuras críticas (CIP). Es bastante común, que cada cierto tiempo se vuelva a discutir la mejor forma de reportar una vulnerabilidad a un fabricante, puesto que a día de hoy, todavía no se ha institucionalizado un procedimiento que pueda satisfacer a ambas partes (la persona que encuentra la vulnerabilidad, y el fabricante).

Existe todo tipo de alternativas, sin ser ninguna más exitosa que otra: agradecer al investigador su ayuda (como por ejemplo Microsoft), pagarle una determinada cantidad de dinero (Google), o simplemente, utilizar alguna compañía que funciona como broker para pagar las vulnerabilidades (iDefense VCP o Tippingpoint ZDI por ejemplo). Pero la realidad es que el sistema no funciona, y ejemplos como el del año pasado de la vulnerabilidad descubierta por Tavis Ormandy en Windows, es el ejemplo perfecto que demuestra que es necesario tener algún procedimiento que contente a todas las partes.

A día de hoy lamentablemente algunos fabricantes no consideran que la seguridad es un elemento crítico para no poner en riesgo a sus usuarios (la lista de ZDI sobre las vulnerabilidades aún no parcheadas es bastante ilustrativa), y por el otro lado, algunos investigadores también piensan que los fabricantes deben cumplir con sus exigencias de forma inmediata, llegando incluso a extorsionar al fabricante. Si bien han existido siempre intentos de procedimentar el reporte de vulnerabilidades (desde el famoso procedimiento de RFP, pasando por un intento del IETF, Responsible Vulnerability Disclosure Process, que acabo siendo la base de un procedimiento de la Organization for Internet Safety, hasta la iniciativa de No More Free Bugs promovida por varios investigadores).

Si nos movemos en el campo de la protección de las infraestructuras críticas, recientemente estamos viendo lo mismo que ocurrió hace ya varios años: después de intentar hacer las cosas bien, al ver que a menudo no se obtiene ningún resultado, nos encontramos con posiciones como la de Digital Bond, donde su política de reporte de vulnerabilidades es tan simple como: haremos lo que nos de la gana; cansados de ver cómo los grandes fabricantes industriales, después de todos los ríos de tinta que han provocado incidentes como Stuxnet o las vulnerabilidades encontradas por Dillon Beresford, parece que no reaccionan, ni siquiera cuando se involucra al ICS-CERT (puede que incluso el fabricante desee denunciarte).

Al final del día, lo que importa es cómo cada fabricante se preocupa de manejar y coordinar estas incidencias (la comunicación con los investigadores y empresas), puesto que, si por fin nos hemos dado cuenta que ninguna de las políticas de reporte de vulnerabilidades globales funciona, es trabajo de cada fabricante organizar su propia política que sea de gusto de ambas partes. Por poner un ejemplo, Mozilla, Barracuda, Google, FaceBook o Twitter ya lo han hecho, y no todas ellas pagan por vulnerabilidad encontrada, sino que algunas simplemente reconocen la ayuda.

En definitiva, más vale prevenir que curar, y es necesario que todas las grandes empresas tengan en marcha una política clara y publicada sobre las vulnerabilidades que terceras personas encuentren sobre sus productos, servicios, o simplemente, sobre sus portales web, y que se reconozca también la labor de las personas anónimas o no, que, positivamente, colaboran en la mejora de la seguridad en la red.