Divulgación Coordinada de Vulnerabilidades

Colaboración de David Bonilla

David Bonilla es un emprendedor español del mundo del software que ha sabido construir una comunidad alrededor suya a quienes inspira y deleita semanalmente desde hace años con un boletín semanal al que podéis suscribiros haciendo click en el enlace de la awesómica Bonilista.

No contento con esto, organiza una CONF espectacular (a la que es muy difícil asistir) llamada tarugoconf (no perdemos la esperanza de poder ir un año de estos) y hoy, en la Bonilista ha tocado un tema que tocábamos hace poco en el blog, el Bug bounty, y que está de más actualidad que nunca con el escándalo de Lexnet.

Nos ha encantado el artículo que ha escrito hoy, y le hemos pedido permiso para reproducirlo en nuestro blog. Con todos ustedes, el magnífico artículo de David Bonilla:

 

Don’t look Don’t tell

Hace un par de semanas, intentamos reconstruir la cadena de responsabilidades que llevó a la concepción y desarrollo de LexNet -un software que nunca debió existir- sólo para llegar a la conclusión de que el actual ministro de Justicia no era, ni mucho menos, el principal culpable.

De lo que sí es responsable es de la pésima gestión posterior, por parte de la Administración que dirige, de la divulgación de la vulnerabilidad del sistema. Especialmente, cuando un estudiante de 20 años descubrió un servidor del ministerio, público y sin ninguna restricción de acceso, que contenía miles documentos relacionados con el proyecto y permitía acceder con permisos de administrador al panel de monitorización de LexNet. Una cagada tan grande que avergonzaría hasta a un comercial de consultora informática cárnica.

El chaval les avisó del agujero de seguridad por Twitter, pero poco después borró los mensajes para que la vulnerabilidad no se hiciera viral. Dio igual, la reacción del Ministerio fue termonuclear: en vez de reconocer el error, declararon que lo que había ocurrido no era ningún fallo sino un delito y, el 1 de agosto, presentaron una denuncia ante la Brigada de Investigación Tecnológica de la Policía Nacional en la Comisaría de Canillas en Madrid.

What?

Esta anécdota nos recuerda que la gestión de vulnerabilidades informáticas en nuestra Administración está anticuada desde hace más 15 años, algo que puede parecernos hasta normal, pero que sorprendentemente también ocurre en el 99% de las empresas tecnológicas de este país.

Para intentar explicar por qué, debemos remontarnos unos 20 años en la historia de la informática. En aquel lejano 1997, si reportabas un fallo de seguridad en el mejor de los casos te ignoraban y, en el peor, te demandaban.

Amparadas por la opacidad y la falta de información del gran público, las compañías solían negar la existencia de esos fallos y no hacían un gran esfuerzo por solventarlos. Sólo se ocupaban de ella cuando los chicos malos aprovechaban la vulnerabilidad y su inacción para intentar obtener un beneficio económico o, simplemente, hacer daño. Entonces, los portavoces de esas grandes corporaciones convocaban a los medios para pedir disculpas, anunciaban un parche para tapar el agujero y echaban la culpa de todos los males de los usuarios a «los malvados hackers”. La seguridad informática no se veía como un problema de software sino de relaciones públicas.

Los chicos buenos llegaron a la conclusión de que la única forma de conseguir que esas grandes corporaciones se tomaran en serio los fallos de seguridad que afectaban a sus usuarios era causarles un GRAN problema de relaciones públicas. Así nació el full disclosure o divulgación completa de vulnerabilidades, consistente en publicar no sólo la existencia de un problema de seguridad sino todos los detalles del mismo.

A partir de ese momento, cada vulnerabilidad se convirtió en una carrera entre los departamentos de seguridad de las empresas y los crackers para ver que llegaba primero, el parche que la solucionaba o el exploit que la aprovechaba. El problema es que, a pesar de contar con muchos menos recursos, en demasiadas ocasiones eran los segundos –los chicos malos– los que ganaban.

Por eso, en el año 2000, el hacker conocido como Rain Forest Puppy escribió una propuesta sobre cómo podría funcionar una política de divulgación coordinada de vulnerabilidades o responsible disclosure que, básicamente, proponía enviar primero todos los detalles de un fallo de seguridad a los desarrolladores del software y, después de un tiempo prudencial –al menos 30 días-, hacerlos públicos.

Desde entonces, hace 17 años, la divulgación coordinada de vulnerabilidades se convirtió en un estándar de la industria, apoyada por empresas como MicrosoftAdobe o Google que incluso tienen programas de bug bounty y recompensan económicamente a aquellos que descubran vulnerabilidades de seguridad en su software. La recompensa media en 2016 fue de 451 dólares, y llega hasta los 1.776 dólares cuando el fallo reportado es crítico. CACAHUETES, comparado con el coste reputacional y económico que podrían sufrir estas compañías si dichas vulnerabilidades fueran explotadas por los chicos malos.

Pero no hace falta ser una gran corporación para tener una política de divulgación coordinada: lo tiene desde una publicación independiente como The Atlantic hasta una startup española como Mailtrack. Incluso existe una plantilla open source en Git Hub, disponible para que cualquiera quiera adaptarla y usarla.
Suena bien
Por supuesto, aunque la divulgación coordinada de vulnerabilidades es un win-win para todas las partes implicadas, algunos prefieren vivir en el pasado más rancio, como por ejemplo nuestra Administración u Oracle. En 2015, Mary Ann Davidson -responsable de seguridad de la compañía- publicó un rant de 3.000 palabras en contra de los que usuarios que reportaban agujeros de seguridad, incluyendo sus propios clientes.

Según Davidson, la mayoría de fallos reportados no eran críticos o ya eran conocidos por su equipo y los usuarios que investigaban el comportamiento de su software para hayarlos estaban incumpliendo los términos de la licencia de uso de Oracle y les exigía que dejaran de hacerlo. Esos términos impedían no ya que revelaran cualquiera vulnerabilidad, sino que incluso probaran la seguridad e integridad de un software por el que habían pagado. Don’t look Don’t tell.

Pero si impides que los chicos buenos busquen vulnerabilidades en tu software, sólo lo harán los chicos malos. A un cracker checheno, la licencia de uso de Oracle o lo que piense Mary Ann Davidson le importa tanto como la frecuencia de autobuses entre Betanzos y Peteiro.

Poseer una política de divulgación coordinada de vulnerabilidades no hará nuestro software más seguro ni impedirá que los chicos malos intenten reventarlo en beneficio propio, pero en el caso de que los chicos buenos decidan ayudarnos, les explicará cómo hacerlo y les dará unas mínimas garantías de que nos les tratarás ni como gilipollas ni como delincuentes.

Una divulgación coordinada o responsable de vulnerabilidades sólo funcionará si hay un desarrollo de software coordinado y responsable. Teniendo en cuenta que es una iniciativa que no cuesta dinero sino que lo ahorra, es un dislate que una empresa privada no la tenga, pero en el caso de una Administración Pública es, sencillamente, inaceptable.

 

¿Te ha gustado este texto? Ayúdale a llegar a más gente:

Like Don't look Don't tell #Bonilista on Facebook share on Twitter Google Plus One Button
(Ilustración original cortesía del dibujolari Hugo Tobio)

¡Apoyar a la Bonilista es fácil! Sólo tienes que comer empanadas o gestionar tu wiki con software awesómico.

LinkedIn
Twitter
Facebook
WhatsApp
0 0 votos
Calificación del artículo
Suscribir
Notificar de
guest
0 Comentarios
Comentarios en línea
Ver todos los comentarios
Metafrase
Contacto

© 2024, Metafrase SLU

0
Me encantaría conocer tu opinión, por favor comenta.x
()
x