Saltar al contenido principal

Divulgación responsable - Reportar vulnerabilidades éticamente

Lectura de 2 min aprox.

La divulgación responsable (Responsible Disclosure) es un proceso en el que, al descubrir una vulnerabilidad en un software o servicio, quien la halla notifica primero al proveedor de forma privada y publica la información solo después de que se haya proporcionado un parche de corrección. Este marco, en el que el investigador y el proveedor cooperan para abordar la vulnerabilidad, es ampliamente aceptado en la comunidad de seguridad actual como un enfoque equilibrado que protege a los usuarios de los ataques y, al mismo tiempo, garantiza la transparencia de la investigación en seguridad.

La diferencia con la divulgación completa

Existen, en términos generales, tres posturas sobre la política de divulgación de vulnerabilidades, cada una basada en una filosofía diferente.

PolíticaResumenVentajaRiesgo
Divulgación responsableNotificar primero al proveedor y publicar tras la correcciónLa información se publica con los usuarios ya protegidosEl proveedor podría retrasar su respuesta
Divulgación completaPublicar toda la información inmediatamente tras el descubrimientoObliga al proveedor a responder con rapidezLos atacantes pueden explotarla antes de que exista un parche
No divulgaciónNotificar solo al proveedor y no publicarLa información nunca llega a los atacantesNo se puede verificar la respuesta del proveedor

El movimiento de divulgación completa de principios de la década de 2000 surgió como reacción al problema de que los proveedores ignoraban los informes de vulnerabilidades. Sin embargo, el riesgo de que se publique código de ataque mientras no hay un parche disponible es elevado, por lo que hoy en día la divulgación responsable es la corriente predominante. En 2010, Microsoft propuso el término «Coordinated Vulnerability Disclosure (CVD)», destacando la cooperación entre quienes hallan las vulnerabilidades y los proveedores.

Una cronología típica y la regla de los 90 días

Day 0
Vulnerabilidad descubierta
Day 1-7
Notificar al proveedor
Day 7-83
Desarrollar y verificar la corrección
Day 84-90
Parche publicado
Day 90+
Vulnerabilidad divulgada

La «regla de los 90 días» establecida por Google Project Zero en 2014 se ha consolidado como el plazo de divulgación estándar del sector. Es una política de publicar la información de la vulnerabilidad una vez transcurridos 90 días desde la notificación al proveedor, exista o no un parche. Este plazo reduce el incentivo de los proveedores para posponer su respuesta. De hecho, Google Project Zero ha divulgado vulnerabilidades de Microsoft y Apple tras vencer el plazo, lo que ha impulsado a los grandes proveedores a mejorar sus sistemas de gestión de parches.

La relación con los programas de recompensas por errores

Los programas de recompensas por errores son un mecanismo que incentiva económicamente la divulgación responsable. Cuando quien la halla informa de una vulnerabilidad al proveedor, se le paga una recompensa según su gravedad. Plataformas como HackerOne y Bugcrowd actúan como intermediarias y ofrecen plantillas de informes, ayuda para obtener números CVE y un marco de protección legal. También en las auditorías de seguridad de código abierto, la coordinación entre las recompensas por errores y la divulgación responsable es un tema importante.

Riesgo legal y puerto seguro

Descubrir e informar de vulnerabilidades conlleva un riesgo legal. Incluso un investigador bienintencionado puede infringir leyes como la Ley de Prohibición del Acceso No Autorizado (Japón), la CFAA (Estados Unidos) y la Computer Misuse Act (Reino Unido). Para mitigar este problema, muchas empresas incluyen una «cláusula de puerto seguro» en sus políticas de seguridad. La cláusula de puerto seguro establece explícitamente que no se emprenderán acciones legales contra los investigadores que informen de vulnerabilidades conforme a la política.

En Estados Unidos, en 2022 el Departamento de Justicia revisó su política de aplicación de la CFAA, indicando que la investigación de seguridad de buena fe quedaría excluida de la persecución penal. La Directiva NIS2 de la UE también exige a los Estados miembros que establezcan un marco para la divulgación coordinada de vulnerabilidades. En Japón, sin embargo, la legislación de un puerto seguro no ha avanzado, y el régimen de notificación de vulnerabilidades del IPA (Agencia de Promoción de la Tecnología de la Información) funciona como el canal de facto. La lista de verificación de seguridad para startups también presenta los pasos para redactar una política de divulgación.

Un error frecuente

La idea de que «hay que publicar una vulnerabilidad en las redes sociales en cuanto se encuentra» es peligrosa. Publicarla cuando no existe un parche da a los atacantes la oportunidad de explotarla. Además, el acto de investigar el sistema de un tercero sin autorización para una prueba de penetración puede ser ilegal en sí mismo. Como se comenta en el artículo sobre ataques a la cadena de suministro, manejar correctamente la información de vulnerabilidades también es importante para evitar una cadena de ataques.

libros relacionados con la seguridad (Amazon) también es un buen lugar donde buscar.

Términos relacionados

¿Te resultó útil este artículo?

XHatena