Coordinated vulnerability disclosure

Divulgación coordinada de vulnerabilidades (CVD)

Cómo informar, recibir y coordinar vulnerabilidades de seguridad, con políticas de ejemplo.

La divulgación coordinada de vulnerabilidades (coordinated vulnerability disclosure, CVD) es un término de seguridad informática. Describe cómo las personas pueden compartir informes sobre problemas de seguridad. Algunos ejemplos son informes de errores, riesgos de intrusión, alertas de piratería, filtraciones de datos, vulneraciones de sitios web, etc.

Traducciones: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

Contenido:

Políticas:

Introducción

Este documento explica la divulgación coordinada de vulnerabilidades de maneras que pueden ayudar a las personas a trabajar juntas.

Objetivos del documento:

  1. Ayudar a las personas que descubren problemas de seguridad y quieren informar de ellos.

  2. Ayudar a los representantes de las empresas a comprender las necesidades, los objetivos, las prácticas y los casos especiales de la divulgación responsable.

  3. Incluir ejemplos de políticas de divulgación coordinada de vulnerabilidades en la carpeta del repositorio.

Agradecemos las solicitudes de incorporación de cambios (pull requests), las incidencias de GitHub o los correos electrónicos a security@joelparkerhenderson.com.

¿Qué es la divulgación coordinada de vulnerabilidades?

La divulgación coordinada de vulnerabilidades describe tres pasos cuando alguien descubre un problema de seguridad (como un error de software) y quiere informar de él al productor (como la empresa que fabrica el software).

Pasos:

  1. La persona que lo descubre informa del problema en privado y de buena fe al productor.

  2. El productor intenta proteger a los usuarios de buena fe e intenta resolver el problema.

  3. Transcurrido un tiempo determinado, el problema de seguridad se hace público.

Paso 1: Informar del problema

El paso 1 corresponde a quien descubre el problema: informar de él en privado y de buena fe.

  • Bien: quien lo descubre envía la información pertinente al productor, por ejemplo por correo electrónico a la dirección de seguridad del productor (normalmente "security@example.com") o mediante un formulario web en el sitio web del productor (normalmente "https://www.example.com/security").

  • Mal: publicar el informe en un blog público, avisar a los medios de comunicación, amenazar o intentar vender el problema de seguridad a piratas informáticos, etc.

  • Consejo: quien lo descubre puede optar por permanecer en el anonimato; el productor también puede optar por permanecer en el anonimato.

Si lo desea, siga pendiente del problema.

  • Bien: abrir líneas de comunicación, aportar información de seguimiento o vigilar la situación.

  • Mal: olvidarse del problema.

  • Consejo: quien lo descubre puede decidir si ayuda o no, si mantiene la comunicación o no, y también puede cambiar lo acordado si cambian las circunstancias.

Si lo desea, divulgue el problema a otras personas.

  • Bien: esperar el tiempo especificado y luego hacerlo público, por ejemplo publicando la información pertinente en un sitio de noticias de seguridad, poniéndose en contacto con investigadores de seguridad externos pertinentes o anunciando el problema en cualquier red social pública, etc.

  • Mal: no divulgar el problema a otras personas, salvo que considere que supondría un riesgo mayor del comparable para usted o para otros.

  • Consejo: si cambian las circunstancias, por ejemplo si se descubre un riesgo mayor o un exploit activo en circulación, quien lo descubre puede divulgar el problema a otras personas antes.

Paso 2: Garantizar los contactos

El paso 2 corresponde al productor: garantizar que los contactos sean viables.

  • Bien: el productor publica una dirección de correo electrónico de contacto de seguridad (por convención "security@example.com") y, idealmente, una clave de cifrado de correo seguro.

  • Bien: el productor publica una página web de contacto de seguridad (por convención "https://www.example.com/security") e, idealmente, hace que la página sea fácil de encontrar, por ejemplo mediante el pie de página del sitio web, el mapa del sitio y la búsqueda.

  • Mal: el productor no proporciona una dirección de correo electrónico ni una página web, o no los hace fáciles de encontrar.

Garantice las capacidades del personal.

  • Bien: el productor forma al personal de soporte sobre qué hacer si recibe una consulta de seguridad, por ejemplo cómo responder con información de contacto o cómo reenviar la consulta al equipo interno adecuado.

  • Bien: el productor verifica periódicamente que las capacidades del personal funcionan.

  • Mal: el productor no forma al personal o no lo verifica.

Responda a quien lo descubrió dentro del plazo.

  • Si quien lo descubrió no especifica un plazo, utilice un día hábil, porque es el estándar del sector y la mejor práctica actual del sector.

  • Si quien lo descubrió hace preguntas, respóndalas. Esto es especialmente importante si pide permiso para hacer pruebas. Asegúrese de que todas las respuestas sean claras y directas.

Responda a quien lo descubrió a través de un contacto de seguridad autorizado y/o de un proceso de seguridad autorizado.

  • Bien: una respuesta desde una dirección de correo electrónico específica de seguridad, como "security@example.com".

  • Por ejemplo, esto está mal: una respuesta desde una dirección de correo electrónico de uso general, como "help@example.com", o de cualquier persona que no sea un profesional de la seguridad autorizado.

Confirme a quien lo descubrió que el problema se reconoce como un informe de seguridad.

  • Bien: una redacción específica de seguridad, como "Nuestro equipo de seguridad ha recibido su informe de divulgación responsable", o "Nuestro proceso de seguridad tiene estos pasos siguientes", o "Su información consta ahora en nuestro sistema de seguimiento de seguridad con el número de identificación XYZ", etc.

  • Mal: una redacción de uso general, como "Agradecemos su confianza", o "Nos tomamos la seguridad muy en serio", o una redacción que traslada la responsabilidad, como "Hemos enviado su correo electrónico a otro departamento", etc.

Paso 3: Trabajar de buena fe

El paso 3 corresponde conjuntamente a quien lo descubrió y al productor: trabajar de buena fe.

Entienda que la divulgación coordinada de vulnerabilidades describe un proceso de buena fe.

  • El objetivo n.º 1 es la buena fe para ayudar a los usuarios a protegerse de los riesgos de seguridad.

  • El objetivo n.º 2 es la buena fe para resolver el problema de seguridad.

  • Quien lo descubrió y/o el productor pueden optar de buena fe por involucrar a otras personas de seguridad, como ponerse en contacto con otros investigadores de seguridad pertinentes para que ayuden con el problema.

Entienda que la divulgación coordinada de vulnerabilidades no crea ninguna obligación.

  • Quien lo descubrió y/o el productor pueden retirarse en cualquier momento, por cualquier motivo, con o sin previo aviso. Es cortés mantener informadas y al día a todas las personas pertinentes, pero esto no siempre es posible, práctico ni deseable.

  • La divulgación coordinada de vulnerabilidades no crea ningún acuerdo legal. Si quien lo descubrió y el productor ya tienen un acuerdo legal, le sugerimos que todas las personas involucradas consulten a los abogados adecuados; no utilice este documento como asesoramiento jurídico.

Entienda que la divulgación coordinada de vulnerabilidades pretende utilizar una buena comunicación y rechazar las amenazas.

  • La divulgación coordinada de vulnerabilidades funciona mejor cuando todas las personas involucradas entienden que el objetivo n.º 1 es ayudar a los usuarios a protegerse de los riesgos de seguridad y el objetivo n.º 2 es resolver el problema de seguridad.

  • La divulgación coordinada de vulnerabilidades rechaza cualquier tipo de amenaza de represalia, intimidación, suspensión, revocación, extorsión, carga de seguimiento o culpabilización de la víctima.

Entienda que la divulgación coordinada de vulnerabilidades puede significar cosas distintas para personas distintas.

  • Quien lo descubrió y el productor pueden tener una comprensión diferente de la divulgación coordinada de vulnerabilidades. Estas comprensiones pueden no coincidir entre sí. La buena fe incluye que todas las personas involucradas lo entiendan.

  • Algunos productores publican políticas de divulgación coordinada de vulnerabilidades. Estas pueden ser una orientación útil. Si quien lo descubrió opta por otro tipo de divulgación coordinada de vulnerabilidades, o tiene una comprensión diferente de la divulgación responsable, es absolutamente aceptable.

Entienda que, normalmente, quien lo descubrió le está haciendo un favor al editor.

  • Normalmente quien lo descubrió no necesita el permiso de nadie para publicar vulnerabilidades.

  • Normalmente la información de quien lo descubrió ayuda al editor.

Verificar el éxito

Una vez resuelto el problema, el productor debe verificar el éxito.

  • ¿Todas las personas y procesos gestionaron con éxito la divulgación? Si es así, bien. Si no, considere realizar una investigación posterior, como un análisis de causa raíz (RCA), informes posteriores al incidente, diagramas de Ishikawa o un análisis causal basado en la teoría de sistemas (CAST).

  • ¿Los problemas pendientes están clasificados y se les hace seguimiento?

  • ¿El productor y quien lo descubrió entienden ambos qué hacer en los pasos siguientes? Esto es especialmente importante para que salga bien en caso de que haya posteriores divulgaciones coordinadas de vulnerabilidades.

Orientación

La orientación sobre la divulgación coordinada de vulnerabilidades puede provenir de muchos ámbitos, como expertos en ética, defensores legales, las expectativas razonables del público en general, etc.

Si busca orientación, puede que le interesen estos tres ámbitos, todos descritos a continuación.

  • Buen samaritano

  • Deber de socorro

  • Deber de diligencia

Buen samaritano

Wikipedia: Ley del buen samaritano

Las leyes del buen samaritano ofrecen protección legal a las personas que prestan una ayuda razonable a quienes están, o creen que están, heridos, enfermos, en peligro o incapacitados de otro modo. La protección pretende reducir la vacilación de los transeúntes a la hora de ayudar por miedo a ser demandados o procesados.

Deber de socorro

Wikipedia: Deber de socorro

El deber de socorro es un concepto que describe una circunstancia en la que una parte puede ser considerada responsable por no acudir al rescate de otra parte en peligro. Un deber de socorro puede tener ámbitos morales y/o jurídicos.

Deber de diligencia

Wikipedia: Deber de diligencia

El deber de diligencia es la obligación de ajustarse a un estándar de cuidado razonable al realizar cualquier acto que pueda perjudicar previsiblemente a otros. Un deber de diligencia puede tener ámbitos morales y/o jurídicos. Algunos aspectos que considerar son: la previsibilidad del daño o la lesión, la posible magnitud del daño o la lesión potencial, la importancia o el valor social de la actividad en la que participa el demandado, la utilidad de la conducta para el demandado, la viabilidad de una conducta alternativa, los costes y cargas asociados a la conducta alternativa, la utilidad relativa de la conducta alternativa y la seguridad relativa de la conducta alternativa.

Casos especiales

Nuestros equipos de seguridad han visto una amplia gama de casos especiales.

Los describimos aquí para ayudar a las personas a comprender dónde existe una amplia gama de opiniones sobre lo que puede estar bien y lo que puede no estarlo. Recomendamos que todas las personas involucradas se comuniquen de buena fe sobre estos casos.

Acceso a la información de otros usuarios

Ejemplo: descubre que una URL contiene su identificador de usuario y revela un error, y cree que puede editar la URL para cambiar su identificador de usuario por el de otro usuario.

  • ¿Está bien que quien lo descubrió haga esto, por ejemplo con el único objetivo de averiguar si también afecta a otros usuarios?

  • ¿Es más importante comprender rápidamente la amplitud del riesgo para todos los usuarios que proteger a un par de usuarios cuya información ya puede ser visible para los piratas informáticos?

  • ¿Está bien que quien lo descubrió lo haga con tantos usuarios como quiera?

  • ¿Está bien que quien lo descubrió intente ponerse en contacto con los usuarios para informarles de que están afectados? ¿Está bien ofrecer sugerencias de mitigación?

Denegación de servicio

Ejemplo: descubre un error que suspende accidentalmente su cuenta, como activar un bloqueo de contraseña.

  • ¿Se considera esto un ataque de denegación de servicio?

Correo electrónico no solicitado

Ejemplo: intenta informar de un problema de seguridad a personas de la empresa que cree pertinentes, y a las que descubre investigando en LinkedIn, Facebook, etc., o utilizando convenciones de nomenclatura como "webmaster@example.com" o "security@example.com".

  • ¿Está esto bien?

  • ¿Se considera esto correo electrónico no solicitado?

  • ¿Se considera esto correo electrónico no autorizado?

Grupos excluidos

Ejemplo: pertenece a un grupo excluido, como ser menor de edad, figurar en una lista de sanciones o estar en un país de una lista de sanciones.

  • ¿Está bien que usted haga un informe?

  • ¿Está bien informar de forma anónima?

  • ¿Está bien cambiar deliberadamente información potencialmente identificativa, por ejemplo para escapar del grupo excluido y con el objetivo de ayudar a que la divulgación llegue a las personas adecuadas?

Terceros

Ejemplo: descubre que el software de una empresa tiene un error que involucra a un tercero, como una integración con otro software u otro sitio web.

  • ¿Está bien que informe de toda la información que encuentre a ambas partes?

  • ¿Es necesario hacer dos divulgaciones responsables distintas, como un informe a una empresa y otro distinto a la empresa tercera, con el objetivo de limitar la información enviada a cada empresa?

  • ¿Está bien que quien lo descubrió ponga en contacto a las empresas entre sí?

Software perjudicial

Ejemplo: tiene la habilidad suficiente para escribir un virus que cree que probablemente ayudará a los usuarios a protegerse del riesgo de seguridad, a identificar si están en riesgo o a corregir el riesgo de seguridad.

  • ¿Está bien?

  • ¿Está bien que quien lo descubrió dirija a los usuarios a software como este y/o a guías o tutoriales que describan cómo crear este tipo de software?

Divulgación coordinada de vulnerabilidades frente a divulgación responsable

La divulgación coordinada de vulnerabilidades es el término preferido.

  • El aspecto más importante es la coordinación entre quien lo descubre y el productor.

La divulgación responsable es un término obsoleto.

  • Las personas tienen opiniones distintas sobre lo que significa ser responsable. Por ejemplo, algunas personas defienden que es responsable que quien lo descubre avise al público de inmediato, independientemente de cualquier interacción con el productor, e irresponsable hacer divulgación coordinada de vulnerabilidades porque oculta información al público.

Seguimiento