Responsible full disclosure... por ambas partes
/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Tabla normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}
We take these reports seriously and will respond swiftly to fix verifiable security issues. [...] Any Cisco Meraki web service that handles reasonably sensitive user data is intended to be in scope. This includes virtually all the content under *.meraki.com. [...] It is difficult to provide a definitive list of bugs that will qualify for a reward: any bug that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program.
La revelación de información se les notificó a principios de noviembre. Dos días después la respuesta de Meraki fue peor de lo esperado:
I have looked into your report and, unfortunately, this was first reported to us on 9/23/13, with a resolution still pending from our engineers.
Esto implica qu e se alegaba que un tercero lo había descubierto previamente y lo que es peor, que el problema les era conocido desde hacía al menos cinco semanas y aún no lo habían (y no lo han) resuelto. Simplemente se trata eliminar una página de un servidor o protegerla con contraseña.
Otros problemas y vulnerabilidades descubiertos por nuestro equipo, bastante más complejos, han sido resueltos en mucho menos tiempo. Los problemas que se pueden zanjar eliminando una página, prácticamente suelen solucionarse en el mismo día que se detectan.
Salvando absolutamente todas las distancias, otros usuarios que han participado en los "bounty programs" de Facebook, PayPal ( especialmente torpe con su programa) o Google, se quejan de que han recibido, en "demasiadas" ocasiones, la respuesta de que ya alguien les había alertado previamente. Incluso afirma que al pedirle a PayPal pruebas de que alguien se les había adelantado, nunca contestaron. Es incluso más común oír que los fabricantes tardan demasiado en corregir cualquier error cuando se alerta de ellos de forma privada.
Antecedentes
Al margen de la anécdota introductoria, la "divulgación responsable" es un viejo debate, y existen muchos ejemplos con los que periódicamente se ha reabierto. En resumen: al divulgar una vulnerabilidad, en cierta manera, se ataca directamente al crimen en la red donde más le duele, devaluando un valor muy apreciado. También, hacer público cualquier error hace que su prevención y detección sea mucho más generalizada y por tanto, previene futuros ataques. Incluso, podría llegar a "detener" ataques que hipotéticamente se estuviesen realizando aprovechando un fallo antes de que el investigador lo hiciese público.
En la parte negativa, cuando se hace público, otros atacantes lo incorporan a su arsenal y pueden aprovechar esa vulnerabilidad para lanzar nuevos ataques. Aunque a su vez, ataques de difusión masiva siempre van acompañados de defensas mucho más variadas y asequibles. Por último también es cierto que el hecho de hacer públicos los fallos acelera el proceso de corrección en el fabricante.
El "full disclosure" en realidad, no elimina el impacto de una vulnerabilidad sino que lo transforma: desde un hipotético uso exclusivo del fallo en el mercado negro, inadvertido y muy peligroso, con objetivos muy concretos y valiosos donde pocos ataques dan un alto beneficio; hasta ataques indiscriminados aunque cazados en mayor medida por los sistemas de detección.
Otras responsabilidades
Ahora que están de moda los programas de recompensa, son muchas las compañías que han intentado motivar la revelación responsable premiando económicamente a los que descubren vulnerabilidades y problemas de seguridad. Pero es necesario recordar que desde la posición del afectado, también se crean nuevas responsabilidades. Es muy habitual que se hable de que, por ejemplo, el descubrimiento se atribuirá al primero que escribe al equipo de seguridad. Pero, ¿cómo se demuestra esto? ¿Cómo podría acreditar alguien que ha enviado un correo describiendo un fallo o vulnerabilidad antes que nadie? Los fabricantes podrían obligar a utilizar PGP firmado con timestamp o incluso servicios gratuitos como eGarante para alertar y garantizar los avisos, pero no parece que ninguno recomiende explícitamente su uso. Las empresas que ofrecen recompensas, sugieren en el mejor de los casos el cifrado en las comunicaciones, pero por confidencialidad, más que por la demostración de autoría.
También debemos atender a la responsabilidad de arreglar en un tiempo razonable una vulnerabilidad o fallo. ¿Cuánto tiempo es aceptable? En agosto de 2010 Zero Day Initiative de TippingPoint, harto de vulnerabildiades que se eternizaban, impuso una nueva regla destinada a presionar a los fabricantes de software para que solucionen lo antes posible sus errores: si pasados seis meses desde que se les avise de un fallo de seguridad de forma privada, no lo han corregido, lo harían público. Para fallos web triviales, como el caso de la anécdota, deberían darse menos tiempo, incluso. Lo que añade un nuevo problema: ¿existe alguna forma "justa" o responsable de evaluar la gravedad de un problema y por tanto, su valor económico a la hora de recompensarlo? En el caso de las compañías que hacen de intermediarias, el precio suele estar más o menos fijado, pero en los bounty programs "privados" de cada empresa, este puede ser un valor muy subjetivo.
Los programas de recompensa pretenden premiar a los investigadores, motivarlos para que las vulnerabilidades salgan del circuito del mercado negro, y además obtener una "auditoría" avanzada a un precio que consideren justo. También pretenden ofrecer una imagen de compañía responsable y que premia el trabajo de los profesionales de la seguridad... pero deben estar preparados para responder diligentemente y actuar de forma tan profesional y responsable como exigen a los investgadores, para mantener esa imagen que se pretende proyectar. Si no, que se lo digan a Yahoo!, que a mediados de año, fue ridiculizada tras ofrecer 12.50 dólares (canjeables en productos de la propia Yahoo!) a una compañía que descubrió serios problemas de seguridad en su red.