“Imposible me ha sido rehusarme a las repetidas instancias que el Caballero Trelawney, el Doctor Livesey y otros muchos señores me han hecho para que escribiese la historia circunstanciada y completa de la Isla del Tesoro. Voy, pues, a poner manos a la obra contándolo todo, desde el alfa hasta el omega, sin dejarme cosa alguna en el tintero (…)

La Isla del Tesoro (1901) Robert Louis Stevenson.

Capítulo I: De piratas, corsarios y hombres

Seguramente desde que el hombre es hombre, han existido modalidades o mecanismos de supervivencia basados en la explotación de las vulnerabilidades ajenas, por decirlo de la manera más aséptica y eufemística posible. La versión más organizada y regulada de esas iniciativas se conocen hoy en día como Bug Bounty Programs o programas de recompensa por errores en software.

Pero la ficción y la historia -a partes iguales- presentan abundantes ejemplos de personas que hicieron carrera y fama siendo amigos de lo ajeno. Sin embargo, debemos reconocer que no todas las historias son iguales. ¡Comencemos!

Capítulo II: Autorizaciones, patentes de corso y bulas 

La primera Ordenanza regulando y fomentando la actividad corsaria fue promovida por el rey Felipe IV en 1621 debido a la incesante actividad corsaria y pirata de ingleses, holandeses, franceses, argelinos y turcos, que asolaban el comercio español, tanto en las Indias como en el Mediterráneo. 

De esta forma, los comerciantes, en tiempo de guerra y con consentimiento real, podían invertir su papel de “presa” por el de cazador.

Debido al éxito de las patentes de corso, se publicaron otras Ordenanzas que ampliaban los cometidos del corsario, normalmente cuando el país se encontraba en guerra. Por ejemplo, destacan  las ordenanzas de 1674, 1702, 1718 (que explícitamente decían “contra turcos, moros y otros enemigos de la Corona”), las de 1762, 1779, 1794 (contra intereses franceses principalmente), la de 1796 esta vez en lucha contra los ingleses y la de 1801 nuevamente contra los británicos.

El Tratado de Utrecht de 1713 intentó terminar con las patentes de corso, al declararlas prohibidas, pero el fenómeno continuó durante el siglo XVIII y no fue declarado prohibido hasta el Tratado de París de 1856, que puso fin a la guerra de Crimea.

“(…)Los católicos que se han ceñido con la cruz para el exterminio de los herejes, disfrutarán de las indulgencias y privilegios otorgados a quienes van en defensa de Tierra Santa.”

Bula papal emitida el 4 de noviembre de 1184 e incorporada como Canon III del Cuarto Concilio de Letrán de 1215 

Capítulo III: Sistemas organizados de recompensas y crowdsourcing

“¡El Señor Zorro está rescatando a los prisioneros!” él chilló. ¡El bandolero vuelve a estar entre nosotros! ¡A caballo, soldados y después de él! Hay una recompensa …”

La maldición de Capistrano  (1919)  Johnston McCulley

Tras los años de los corsarios, empezaron a surgir prácticas consistentes en incentivar y premiar a los delatores así como servirse de ciudadanos ajenos a la administración para  capturar delincuentes o buscados por la justicia.

Estos sistemas organizados de recompensas, tienen fuertes raíces en la cultura anglosajona. 

Así por ejemplo, en Estados Unidos, una de las primeras normativas que mencionó las recompensas fue la False Claims Act de 1863, firmada por el presidente Lincoln durante la guerra civil americana para combatir la especulación. Esta Ley en síntesis prometía un porcentaje del dinero recuperado por el Gobierno y se ofrecía protección frente a posibles represalias laborales. A raíz de aquello se aprobaron otras normativas similares para sectores críticos como el energético, medioambiente o el de la aviación.

En nuestros tiempos, destaca por ejemplo la iniciativa vigente desde 2006 de la Hacienda estadounidense que cuenta con un sistema de recompensas que permite premiar a los delatores hasta con el 30% de lo que el fisco pueda recobrar. 

Y sobre todo desde 2010, la famosa Ley Dodd-Frank aprobada por Obama y que creó un programa de recompensas para denunciantes en relación a la Ley de Intercambio de Valores y que permite a la SEC pagar premios a personas que proporcionen información original sobre violaciones de valores.

Igualmente son ampliamente conocidos programas de colaboración para la búsqueda y detención de delincuentes de distintos cuerpos de seguridad:

• Guardia Civil
• Europol
• Interpol
• FBI

Capítulo IV: Vulnerabilidades y amenazas en el entorno ciber

“Usted y yo, todos los cazarrecompensas, nos alzamos entre los Nexus-6 y la humanidad como una barrera que los mantiene separados a ambos.”

¿Sueñan los androides con ovejas eléctricas? (1968)  Philip K. Dick

Con la evolución de la tecnología poco a poco empezaron otro tipo de riesgos que afectaban a los datos, información y comunicaciones. 

Así, se considera que el primer “hacker” de la historia fue el mago Nevil Maskelyne, que en 1903 logró interceptar la primera transmisión del telégrafo inalámbrico, mientras que como primer “ciberdelincuente” suele considerarse a John Draper, que modificando un silbato que se regalaba en las cajas de cereales “Cap’n Crunch” conseguió emitir un tono a 2600 Hz con el que se podía engañar a una centralita telefónica y realizar llamadas gratis.

Con el paso del tiempo este tipo de actividades se extendieron y perfeccionaron. Destaca por ejemplo la aparición de “Creeper” a principios de los años 70, un malware que accedía a los ordenadores a través de ARPANET, se autoejecutaba y comenzaba a mostrar el mensaje “I’m the Creeper, catch me if you can!” y el primer antivirus llamado Reaper diseñado única y exclusivamente para eliminar a Creeper.

Actualmente la cantidad de dispositivos y posibles vulnerabilidades es tan vasta que las soluciones -como es lógico- requieren de otra complejidad y no pueden diseñarse para perseguir a un único malware.

Así encontramos tanto herramientas de ciberseguridad basadas en inteligencia artificial como programas basados en inteligencia colectiva.

Capítulo V: Orígenes de los Bug Bounty Programs

Un “Bug Bounty Program” o programa de recompensa por errores es un mecanismo regulado, ofrecido por determinados sitios web, organizaciones y desarrolladores de software, mediante el cual cualquier persona puede recibir un reconocimiento o compensación por informar de errores relacionados con determinadas vulnerabilidades de ciberseguridad .

Estos programas están basados en la denominada “inteligencia colectiva”  (capacidad de razonar, aprender, crear, resolver problemas o tomar decisiones en grupo) y se están convirtiendo en un método cada vez más popular para encontrar errores de seguridad en Internet.

Capítulo VI: Estado actual

Hoy en día numerosas empresas de todos los tamaños, inspiradas en grandes compañías como Google o Facebook, cuentan con sus propios programas recompensas por errores en sus aplicaciones web. 

Así, la cantidad, el tamaño de las recompensas, la popularidad y la legitimidad de estos programas ha aumentado paulatinamente. 

Sirva de ejemplo que las recompensas de Google en 2016 ya eran cinco veces mayores que en 2010 e incluso han comenzado a ofrecer subvenciones especiales para alentar a los investigadores.

Sin embargo, su crecimiento no tiene que ver sólo con el dinero de las recompensas, sino también con el que puede ahorrar la compañía que lo impulsa. En este sentido, un estudio de los programas de recompensas de errores de la Universidad de Berkeley en California University of California, Berkeley ha concluido que:

• Los programas de recompensas son una solución económica eficiente para encontrar vulnerabilidades, con un costo / beneficio razonable (Secciones 4.1.1 y 4.1.6 del estudio).

• En particular, en función del programa y número de vulnerabilidades detectadas, demuestran ser entre 2 y 100 veces más rentables que contratar investigadores expertos en seguridad.

Estos datos hacen que incluso organizaciones gubernamentales favorezcan, legislen y promuevan sus propios programas. Destacando en sus inicios la labor realizada por EE.UU. desde 2014 con la creación de su  Unidad de Ciberseguridad o el Programa de Ciberseguridad de California, y actualmente con su “ Ley de equipos de respuesta a incidentes y caza cibernética del Departamento de Seguridad Nacional de 2019“.

Esta Ley obliga al Departamento de Seguridad Nacional (DHS) a mantener equipos permanentes de “caza cibernética y respuesta a incidentes” con los siguientes fines:

• Asistir a los propietarios y operadores de sitios críticos en la restauración de los servicios tras un incidente cibernético;
• Identificar posibles intrusiones cibernéticas y riesgos cibernéticos para los aliados;
• Desarrollar estrategias de mitigación para prevenir, disuadir y proteger contra las amenazas cibernéticas; y
• Proporcionar recomendaciones a los propietarios y operadores de sistemas para mejorar la seguridad de su red.

Destaca así mismo que esta Ley identifica un programa piloto de recompensas de errores para ayudar a identificar vulnerabilidades no descubiertas en los sistemas de información del Departamento de Seguridad Nacional. 

Del mismo modo, el Departamento de Defensa de EE. UU. patrocina su propio programa de recompensas de errores llamado ‘Hack the Pentagon’ para identificar vulnerabilidades de seguridad en ciertos sitios web del Departamento de Defensa e incluso la Fuerza Aérea participó en la Conferencia de hackers Defcon en Las Vegas en 2019 con un sistema de datos de aviones de combate F-15, para que fuera puesto a prueba  por los distintos investigadores y anunciaron que este año pondrían a disposición de los hackers un satélite en órbita.

Estos datos han propiciado el auge de un sector que empieza a consolidarse, surgiendo determinados operadores que actúan como intermediarios para gestionar la publicación de los programas, los términos del acuerdo, la revisión y validación de las vulnerabilidades declaradas. 

En ese sentido, destacan como plataformas de intermediación: HackerOne, BugCrowd, Yogosha o SynAck.

Quien quiera consultar la lista de programas activos* que hemos detectado durante la elaboración de este artículo, puede acceder a la misma en este enlace:

LISTA BUG BOUNTY PROGRAMS

* Dado que alguno de los programas de recompensas de errores tienen plazo de finalización, puede ser que en el momento de acceder al mismo éste ya no esté disponible o haya dejado de existir.

Capítulo VII: Fracasos y malas artes

A pesar de todas sus bonanzas, en realidad los programas de recompensas de errores no siempre han tenido el mismo éxito y en ocasiones han generado más de un problema por falta de claridad en sus condiciones, por reportes de vulnerabilidades inadecuados, por falta de pago de alguna recompensa o por usarse para enmascarar brechas de seguridad reales.

En cuanto a la adecuación de los reportes debemos tener en cuenta que no todos se corresponden con vulnerabilidades reales o sujetas al programa de recompensas.

Por ejemplo, viendo los datos del programa de Github durante 2015, podemos observar que menos de la mitad (869 de 1920) fueron aceptadas.

En otras ocasiones, existe falta de previsión (o de fondos) por parte de la compañía que lanza el programa, pudiendo “morir de éxito” ante la avalancha de informes que debe revisar y recompensar en su caso. Así por ejemplo, según nos cuentan desde peerlyst, un programa lanzado en 2014 con una recompensa mínima de 300€ de inicio, modificó dicha recompensa a 50€ tras unas pocas horas y al acabar el día cerró el programa.

También han existido (hace unos años) varias situaciones conflictivas con respecto a investigadores que descubren vulnerabilidades y empresas que no quieren que esas vulnerabilidades sean descubiertas. Son llamativos los casos de Cisco vs ISS, Metro vs de Boston estudiantes del MIT o la publicación de FireEye Labs en relación a los fallos de seguridad en los escáneres de huellas dactilares de teléfonos Android. 

Y finalmente deben destacarse casos en los que se ha tratado de enmascarar bajo un programa de vulnerabilidades creado al efecto una posible brecha de ciberseguridad. 

Destaca entre estos (por reciente) el de Uber, que se inició con una queja de la FTC quien entendía que determinados piratas informáticos descargaron maliciosamente una gran cantidad de información protegida y exigieron un pago como rescate a UBER quien buscó solventar el asunto pagándoles $ 100.000 a través de una plataforma de recompensas de errores y exigiendo que eliminaran los archivos y firmaran un NDA sin haber notificado a los afectados la vulnerabilidad.

Finalmente, el asunto se ha saldado (tras varias revisiones) con un acuerdo entre UBER y la FTC mediante el que Uber se obliga a:

• Notificar a la FTC incidentes futuros relacionados con el acceso no autorizado a la información del consumidor
• No tergiversar cómo monitorea el acceso interno a la información personal de los consumidores y hasta qué punto protege la privacidad, confidencialidad, seguridad e integridad de la información personal. 
• Implementar un programa de privacidad integral. 
• Obtener durante 20 años evaluaciones independientes bienales de terceros, que debe presentar a la Comisión, certificando que cuenta con un programa de privacidad que cumple o supera los requisitos de la orden de la FTC.

En el mismo sentido son interesantes, por cuanto pueden suponer una “invitación o recomendación a contar con un bounty program”, la penalización de la SEC a Craig Scott Capital o la FINRA a uno de sus miembros por conductas de “mero riesgo” sin tener procedimientos de supervisión de vulnerabilidades de seguridad. 

Al fin y al cabo, en palabras de la presidenta de la FTC en 2016,  “La falta irrazonable de una compañía para parchear vulnerabilidades que se sabe que son explotadas por ransomware podría violar la Ley FTC”. 

Capítulo VIII: Cuestiones legales y recomendaciones 

Vistos los posibles riesgos de una implementación deficiente de un Bug Bounty Program o programa de recompensa por errores, vamos a tratar una serie de cuestiones que deben tenerse en cuenta:

Paso 1: Diseño del programa

1.- A la hora de diseñar el programa es esencial establecer unas condiciones técnicas claras. Es decir, decidir qué componentes de nuestra red queremos incluir para que sean analizados, cuales queremos excluir y qué mecanismos de autoprotección queremos establecer. 

Para decidir la amplitud del programa debemos tener en cuenta: 

a) La sensibilidad de la información (por ejemplo, datos económicos, médicos, información personal de los clientes, entre otros). 

b) Los mecanismos de seguridad que ya tengamos para cifrar determinados subgrupos de datos.

c) Nuestra capacidad para segmentar la red o aislar la información sensible.

d) Restricciones legales o contractuales impuestas a la divulgación de determinada clase  de información.

e) Si alguno de los componentes o datos de nuestra red implica o afecta a intereses de terceros y, por lo tanto, si deben ser excluidos del programa por completo o requerir que la organización obtenga autorización adicional antes de incluirlos en el programa.

En este sentido, hay que considerar que si tenemos contratados servicios de almacenamiento cloud, los datos se encontrarán en servidores ajenos donde incluso pueden coexistir con datos pertenecientes a otras personas u organizaciones. 

Así, si no tenemos un acuerdo con el proveedor de servicios, puede que no tengamos capacidad para autorizar a otros a acceder al proveedor de servidores como parte del programa de divulgación de vulnerabilidades.

De hecho, si se ha firmado un un contrato de nivel de servicio (SLA) con el proveedor de servicios cloud, éste puede que directamente contenga o excluya la autorización para participar o establecer programas de detección de vulnerabilidades que afecten a los servidores del proveedor. 

Y para evitar consecuencias no deseadas hay que establecer mecanismos de protección en relación a la información especialmente sensible. En tal sentido debemos: 

• Imponer en las condiciones del programa determinadas restricciones que abarquen desde determinados accesos, hasta el copiado de información, su transferencia, almacenamiento, uso o retención.
• Establecer que la información sensible se trate solo en la extensión requerida para identificar una vulnerabilidad y comunicarla. 
• Considerar si el programa debe incluir la aceptación y firma de condiciones especiales para el tratamiento de información confidencial. 
• Determinar si existen restricciones a los métodos o técnicas autorizadas para descubrir vulnerabilidades.

En general, y según hemos podido comprobar, prácticamente la totalidad de los programas de detección de vulnerabilidades activos actualmente prohíben ataques de ingeniería social y de denegación de servicio porque pueden impactar negativamente en el normal funcionamiento de sus sistemas. 

De esta forma, todas aquellas herramientas o técnicas que sepamos que pueden afectar negativamente al funcionamiento de nuestros sistemas deben ser identificados y prohibidos en la política del programa.

2.- Diferenciar y especificar los tipos de vulnerabilidades que pueden ser objeto de ataque así como la calificación según gravedad que se les va a otorgar. 

En este apartado normalmente se opta por incluir los riesgos de seguridad más críticos para las aplicaciones web, normalmente basados en lo que se conoce como OWASP Top 10 y clasificarlos por gravedad según el Common Vulnerability Scoring System (CVSS).

A modo de ejemplo, el alcance de un programa de divulgación de vulnerabilidad podría incluir:

• Errores de software que pueden identificarse mediante exploits.
• Mala gestión de contraseñas que puede probarse mediante un software de descifrado
• Sistemas mal configurados que permiten el acceso no deseado a los sistemas e información 
• Sistemas de seguridad inadecuados que pueden revertirse mediante uso de ingeniería inversa.
• Uso de componentes con vulnerabilidades conocidas.

3.- Buscar asesoramiento externo y revisar recursos disponibles.  

Actualmente, las condiciones de los Bug Bounty Programs son bastante variables, así como los procesos de revisión y pago de recompensas. De este modo, siempre es recomendable disponer de asesoramiento e información actualizada. Por nuestra parte recomendamos:

• Para ver ejemplos de tipos de vulnerabilidad: 

• • https://nvd.nist.gov/vuln/categories

• El manual de la American Bar Association que aborda cuestiones deontológicas, éticas y prácticas sobre qué puede suceder en el curso de la divulgación de vulnerabilidades:

• • https://www.americanbar.org/products/inv/book/309654847/

• El manual de divulgación de vulnerabilidades “18F” de los Servicios de Transformación de Tecnología (TTS) de la Administración de Servicios Generales de EE.UU:

• • https://handbook.18f.gov/responding-to-public-disclosure-vulnerabilities/

• El trabajo desarrollado por la Administración Nacional de Telecomunicaciones e Información del Departamento de Comercio de los Estados Unidos (NTIA) en relación a vulnerabilidades y su divulgación:

• • https://www.ntia.doc.gov/other-publication/2016/multistakeholder-process-cybersecurity-vulnerabilities

• Las orientaciones de la ISO sobre divulgación de vulnerabilidades (ISO 29147):

• • http://standards.iso.org/ittf/PubliclyAvailableStandards/c045170_ISO_IEC_29147_2014.zip

• La taxonomía de calificación de vulnerabilidades de Bugcrowd (VRT) para proporcionar una escala de prioridad de vulnerabilidad de referencia para los cazadores de errores y las organizaciones:

• • https://github.com/bugcrowd/vulnerability-rating-taxonomy

• Guía para cazadores de recompensas de errores:

• • https://github.com/bobby-lin/bug-bounty-guide

Paso 2: Planificar la administración del programa 

1.- Determinar cómo se informarán las vulnerabilidades que se detecten

La forma en la que se informarán las vulnerabilidades resulta esencial para el buen funcionamiento del programa, tanto para facilitar la revisión y comprobación de las mismas como para garantizar la privacidad de la comunicación y exención de responsabilidades legales.

Habitualmente el canal diseñado para estas comunicaciones se denomina “puerto seguro” y trata de proporcionar un medio cifrado para salvaguardar la información. 

Por otro lado, siempre hay que describir cómo se debe proporcionar la prueba de una vulnerabilidad descubierta. 

Por ejemplo: 

• Configuración del sistema
• Descripción del código de explotación / ataque
• Captura de paquetes de muestra
• Prueba de concepto
• Pasos para reproducir el problema

2.- Asignar una persona o equipo de contacto dentro de la organización para recibir y verificar los informes

Los equipos de seguridad y respuesta a incidentes se encargan de coordinarse con otros equipos de la entidad para investigar la vulnerabilidad, reproducirla e identificar el plan de respuesta adecuado así como mantener la comunicación entre todas las partes involucradas, tanto internas como externas y son un componente clave para el buen funcionamiento del programa.  

3.- Política interna ante incidentes

Antes de lanzar un Bug Bounty Program o programa de recompensa de errores, toda organización debería tener un plan interno sobre cómo actuar en caso de violaciones accidentales de buena fe, divulgaciones no deseadas, intrusiones, vulneraciones intencionales o maliciosas, entre otros supuestos.

Paso 3: Redactar una política de divulgación de vulnerabilidades

Las políticas de estos programas deben ser siempre precisas y sin ambigüedades y además de los temas que hemos tratado antes con más detalle, es importante que contengan los siguientes puntos: 

• Las conductas autorizadas y no autorizadas en términos simples y fáciles de entender.
• Cualquier limitación que queramos incluir para acceder, copiar, usar o retener los datos de la organización en relación con las actividades del programa. 
• Una prohibición general contra cualquier conducta que elimine o altere los datos de los usuarios o que perjudique o  interrumpa los sistemas.
• Los sistemas o subconjunto de sistemas de la organización que se incluyen en el programa (listado blanco) o los sistemas específicamente excluidos (listado negro) .
• Restricciones de acceso a determinada información.
• Mecanismos para identificar la información que no está dentro del alcance del programa.
• Cómo almacenar y/o mantener la información.
• Las consecuencias de cumplir y no cumplir con la política.
• Las acciones legales pertinentes en caso de realizar conductas no autorizadas.
• Formas de contacto en caso de duda con lo contenido en las políticas.
• La elaboración y revisión del resto de documentación, desde el acuerdo de confidencialidad que quizá deba firmar el “cazador” si descubre algo inesperado, a efectos de minimizar el riesgo para la empresa, hasta la comprobación de otros acuerdos o condiciones que puedan afectar a usuarios finales o proveedores.
• Tener presente y al día la política de gestión y comunicación de brechas de seguridad a la Agencia Española de Protección de Datos, por si como consecuencia del programa de Bug Bounty se deriva una vulneración que afecte a la información personal de los usuarios de la empresa.
• Contacto con un centro nacional de respuestas como pueden ser INCIBE o CCN-CERT en el caso de España, para vulnerabilidades que puedan afectar a sistemas de más de una organización.

Paso 4: Implementar el Bug Bounty Program 

Una vez completadas las anteriores etapas ya solo queda decidir si toda la gestión y su publicidad se realizará de manera interna o si externalizamos parte del programa en alguna de las plataformas que existen para ello (HackerOne, BugCrowd, Yogosha, SynAck o la europea YesWeHack)

Episodio IX – The rise of  Bug Bounty Programs en España

En nuestro país los bug bounty programs todavía son una práctica muy poco extendida y son muy pocas las iniciativas públicas o privadas que cuenten con cierta trayectoria.

Debe destacarse aún así la labor de INCIBE que cuenta con mecanismos para reportar vulnerabilidades, aunque sin “capacidad para gratificar económicamente”, así comouna línea de ayudas, repositorios de vulnerabilidades,  avisos de seguridad y diversas y amplias iniciativas de difusión y concienciación.

Sin embargo, a pesar de no ser todavía habituales, pequeños movimientos durante el último año parecen indicar que nos encontramos ante un amanecer del sector. Así, la Universidad Rey Juan Carlos se ha convertido en la primera universidad española (y cuarta del mundo tras Stanford, Drexel y MIT) en crear un programa de bug bounty.

Del mismo modo, ElevenPaths, la división de ciberseguridad de Telefónica Tech, ha anunciado que prepara para 2020 una plataforma privada de bug bounty en nuestro país. 

Y existen ya algunas compañías especializadas en la materia como CazHack, que desde Barcelona quiere convertirse en un referente en el país. 

Por otro lado, parece que los proyectos europeos como ECHO, CONCORDIA, SPARTA o ejercicios como Locked Shields o el European Cyber ​​Security Challenge, que cuentan con representación española, favorecerán el desarrollo del sector.

Capítulo X: Conclusiones

• Los pagos realizados de conformidad con los programas de recompensas de errores son recompensas y NO rescates. 

• Un programa de recompensas es una colaboración, implicando una serie de interacciones basadas en distintos niveles de permisos.

• Si se decide lanzar un programa de recompensas por errores, se debe decidir si crear un programa ad hoc o contratar un proveedor de servicios externo.

• Se requiere de un equipo dedicado de empleados que estén calificados para evaluar cualquier problema descubierto y abonar la compensación que corresponda.

• La contratación externa puede proporcionar cierta comodidad, ya que ayuda al cliente a formular los objetivos del programa, se comunica con los investigadores, evalúa las vulnerabilidades y gestiona las recompensas.

• El conocimiento de una vulnerabilidad le permite a una empresa desarrollar la solución adecuada para el problema, en lugar de reaccionar tardíamente en un entorno lleno de presión tras un ataque.

• Un programa de recompensas de errores correctamente estructurado puede ser una excelente manera de probar la viabilidad de un nuevo concepto, desarrollo o plataforma. 

• El kit básico de documentación y previsiones legales para un programa de Bug Bounty sería: la política del programa de recompensas con los términos y condiciones que deben aceptarse, el acuerdo de confidencialidad ante el eventual descubrimiento de vulnerabilidades inesperadas, la revisión de contratos de proveedores e incluso usuarios finales, cómo el programa puede afectar la información personal de los clientes o usuarios de la empresa o la política de Puerto Seguro para dar seguridad jurídica a los investigadores que participan en el programa y que pueda derivarse de su actividad.

• Las vulnerabilidades existirán siempre y antes o después serán detectadas. 

• Sin un programa de recompensas o una política de divulgación clara, un investigador puede creer que solo tiene dos opciones para evitar responsabilidades:

– Divulgar sus hallazgos de manera pública y anónima (lo cual puede ser utilizado por otro actor malintencionado). 

– No hacer nada (y que acabe siendo descubierto por un actor malintencionado). 

“No hay mucha ley en el lugar de donde vengo. La lucha y las cicatrices forman parte de los gastos generales de un comerciante. Pero la lucha sólo es útil cuando hay dinero al final, y si puedo conseguirlo sin ella, es mucho más cómodo. ¿Encontraré aquí el dinero suficiente como para que valga la pena luchar?”

Fundación (1951)  Isaac Asimov

La entrada Aspectos legales de los Bug Bounty Programs: una historia de piratas se publicó primero en Términos y Condiciones.