Coordinated vulnerability disclosureNCSC.nl
1. Introducción
La sociedad se digitaliza cada vez más. Hoy en día, casi todos los procesos implican el uso de ordenadores en algún momento, desde los teléfonos móviles hasta el software especializado. Aunque esta evolución crea muchas oportunidades nuevas, las vulnerabilidades de los sistemas informáticos pueden tener un gran impacto. Por ello, el conocimiento sobre estas vulnerabilidades debe gestionarse con eficacia.
A principios de 2013, varias organizaciones empezaron a publicar políticas sobre cómo notificar vulnerabilidades. Tras consultar con estas partes, el Centro Nacional de Ciberseguridad (National Cyber Security Centre, NCSC) resumió la evolución en forma de «Directrices para lograr una práctica de divulgación responsable» («Leidraad om te komen tot een praktijk van Responsible Disclosure»; las «Directrices»). Mediante esta política, las empresas indican que están abiertas a recibir notificaciones externas de vulnerabilidades, describen sus condiciones previas y asumen compromisos. Este proceso creó claridad y un entorno algo seguro para que las partes notificantes investiguen y notifiquen vulnerabilidades sin cometer directamente un delito. En la reunión de alto nivel de la UE sobre ciberseguridad de 2016, 29 organizaciones reafirmaron la importancia de una política para tratar las vulnerabilidades al firmar el Manifiesto de divulgación coordinada de vulnerabilidades¹, impulsado por el CIO Platform Netherlands y Rabobank en cooperación con el NCSC.
La divulgación coordinada de vulnerabilidades (Coordinated Vulnerability Disclosure, CVD) ha demostrado ser de gran importancia para las partes públicas y privadas. Estas dependen enormemente del funcionamiento sin interrupciones de los sistemas de información en la práctica diaria. Las notificaciones de vulnerabilidades en sus sistemas han ayudado en los últimos años a mejorar la seguridad y la continuidad de los sistemas, por un lado subsanando vulnerabilidades y por otro contribuyendo a la concienciación general de las empresas neerlandesas sobre la seguridad informática.
En los últimos años ha quedado claro que las partes notificantes están dispuestas a trabajar dentro de las condiciones de la política de CVD elaborada por las organizaciones. Las partes notificantes envían las notificaciones directa o indirectamente a las organizaciones. La práctica de la divulgación responsable ha demostrado que las partes notificantes bienintencionadas y las organizaciones vulnerables han logrado cooperar y dar así el siguiente paso para aumentar la seguridad de las redes y los sistemas de información.
Para esta revisión, hemos vuelto a hablar con un grupo amplio y diverso de partes notificantes, partes privadas y públicas, así como con el Ministerio Fiscal y la Policía Nacional. Estas conversaciones han confirmado la práctica actual y han dado lugar a adiciones y mejoras. El nuevo punto de atención más importante es la comunicación entre quien notifica la vulnerabilidad y la organización, así como con otras partes después de que se haya subsanado una vulnerabilidad.
Los capítulos siguientes tratan la definición de CVD, los elementos básicos de una política de CVD y el proceso de comunicación.
Nota aparte: las Directrices anteriores utilizaban el término «divulgación responsable», que era el término habitual para esta práctica en aquel momento. Entretanto ha quedado claro que este término pone demasiado énfasis en la responsabilidad de la parte notificante, cuando el principio básico es que la parte notificante y la organización potencialmente vulnerable deben ser socios en igualdad de condiciones en el diálogo. Este sentir se recoge mejor en el término habitual actual «divulgación coordinada de vulnerabilidades» (CVD), que es también el nombre utilizado en las normas ISO 29147 y 30111 sobre este proceso.
2. Vulnerabilidad coordinada
Durante los últimos 30 años se han utilizado diversos métodos para concienciar sobre las vulnerabilidades de los sistemas informáticos. Algunos ejemplos son:
«Divulgación completa» (Full Disclosure), hacer pública por completo una vulnerabilidad;
«No divulgación» (Non-disclosure), vender o utilizar uno mismo una vulnerabilidad;
«Divulgación coordinada de vulnerabilidades» (Coordinated Vulnerability Disclosure, CVD), la divulgación coordinada de una vulnerabilidad.
Esta última práctica es expresamente la preferida.
La comunidad informática ha mostrado una gran disposición a compartir conocimientos y experiencia. Por lo tanto, buscar la cooperación con esta comunidad puede ayudar a mejorar la seguridad general de los sistemas.
El objetivo de la divulgación coordinada de vulnerabilidades
El objetivo de la CVD es contribuir a la seguridad de los sistemas informáticos compartiendo conocimientos sobre las vulnerabilidades. En la CVD, el conocimiento se comparte con una o más organizaciones potencialmente vulnerables para llegar a una solución conjunta de la vulnerabilidad encontrada en colaboración con la parte notificante. Es importante que las organizaciones afectadas dispongan de tiempo suficiente para subsanar las vulnerabilidades o proteger los sistemas con el fin de limitar o evitar en la medida de lo posible las pérdidas o los daños. La piedra angular del proceso es la divulgación del conocimiento sobre las vulnerabilidades tras la subsanación.
En la CVD es esencial que todas las partes cumplan los acuerdos sobre cómo notificar una vulnerabilidad y cómo tratarla. Ayuda que una organización publique de antemano las condiciones previas, como qué sistemas están dentro del alcance y qué tipo de investigación puede realizarse. Un principio importante para estas condiciones previas es que la organización, en principio, no denunciará a la parte notificante ni adoptará otras medidas legales si la investigación y la notificación se realizan dentro de las condiciones establecidas. Estas Directrices ofrecen a las organizaciones orientación para elaborar su propia política que plasme los principios de la CVD.
Como indica el nombre, lo central en la CVD es que la organización y la parte notificante se coordinen entre sí. A este respecto, debe haber el menor número posible de eslabones entre la persona que notifica la vulnerabilidad y la persona de la organización responsable de resolver el problema.
Puede ser importante informar a varias partes al mismo tiempo si una vulnerabilidad afecta a muchos sistemas. En ese caso, el NCSC u otras partes de la comunidad de seguridad pueden apoyar el proceso de CVD desde una función de coordinación.
3. Ámbitos de responsabilidad
El objetivo de seguir una política de CVD es que las partes notificantes y la organización trabajen juntas para reducir las vulnerabilidades de los sistemas informáticos. La aplicación de esta política debe considerarse un complemento de las medidas existentes en materia de seguridad de la información. Los distintos actores tienen cada uno su propio papel y sus propias responsabilidades. Se explican con más detalle a continuación.
La organización que posee/gestiona un sistema
La organización que posee/gestiona o suministra un sistema es la principal responsable de la seguridad de este sistema. En otras palabras, la organización es también responsable de dar seguimiento a una notificación de vulnerabilidad.
La organización puede optar por elaborar su propia política de CVD utilizando estas Directrices y comunicar esta política a las posibles partes notificantes. Al publicar una política de CVD, las organizaciones muestran su disposición a recibir información sobre vulnerabilidades.
Una parte que establece una política de CVD puede comprometerse con el principio de que no presentará una denuncia ante la policía si se respetan las normas que se aplican a la política.
Una vez que una parte notificante ha notificado una vulnerabilidad, la responsabilidad recae en la organización. Es importante tener presente que la parte notificante suele ser alguien ajeno a la organización. Esta parte no tiene una visión directa de los procesos internos que pueden activarse tras notificar una vulnerabilidad. Por ello, las partes notificantes agradecerán que se les informe de los avances en la resolución de la vulnerabilidad. Esta comunicación continua es también importante para crear las expectativas adecuadas sobre el seguimiento y la puntualidad de la solución.
La parte que notifica una vulnerabilidad
De un modo u otro, la parte notificante ha podido identificar una vulnerabilidad y quiere contribuir a la seguridad de los sistemas informáticos haciendo que se subsane esta vulnerabilidad y, posiblemente, que se haga pública en una fase posterior. La parte notificante puede haber descubierto algo mediante observación pasiva o probando activamente el sistema informático. Por supuesto, esta parte es responsable de sus propias acciones y de la forma en que descubrió la vulnerabilidad. Es responsabilidad de la propia parte notificante conocer las condiciones establecidas por una organización en su política de CVD. La mayoría de los gobiernos y empresas han publicado sus políticas de CVD en sus sitios web.
No obstante, encontrar vulnerabilidades puede implicar infringir la ley. En el contexto de la CVD, la organización y la parte notificante pueden acordar no presentar denuncia por ningún acto delictivo. A este respecto, la política de CVD publicada por la organización es el principio rector. Las partes también pueden acordar que no se emprenderán acciones civiles.
Si se sospecha que la parte notificante ha infringido la ley, una política de CVD puede ayudar, en primer lugar, a evitar que se denuncie a quien notificó ante las autoridades. Este procedimiento depende totalmente de las condiciones previas de la política que una organización exige cumplir a una parte notificante y de si se ha logrado este cumplimiento, posiblemente con la correspondiente promesa de no presentar denuncia penal mientras la parte actúe dentro de las condiciones de la política. Si se presenta una denuncia policial, la existencia de una política de CVD y su cumplimiento es una circunstancia relevante en los Países Bajos, que el fiscal tendrá en cuenta al decidir si inicia una investigación penal y/o procesa. En principio, la policía y el Ministerio Fiscal (OM) no iniciarán una investigación penal si la parte notificante ha cumplido claramente las normas de la política de CVD de la organización en cuestión. Sin embargo, el Ministerio Fiscal y la policía pueden seguir investigando el caso si hay indicios de que la parte notificante, consciente o inconscientemente, ha ido demasiado lejos en sus acciones y/o no ha cumplido la política de CVD. Con base en esta investigación, el Ministerio Fiscal puede decidir si procesa.
El Ministerio Fiscal ha publicado una carta de política en la que trata de forma más específica los aspectos importantes para llegar a una decisión de investigar y/o procesar. Por ejemplo, si las acciones de la parte notificante servían a un interés público importante, si la parte actuó de forma desproporcionada y si podría haber actuado de otra manera menos drástica. La carta de política pertinente desarrolla más estos aspectos.² La jurisprudencia pertinente desde 2013³ muestra que estos aspectos también se tienen en cuenta ante los tribunales si una organización no tiene una política de CVD.
4. Elementos básicos del proceso de divulgación coordinada de vulnerabilidades
A continuación se ofrecen los elementos básicos para configurar el proceso de CVD para la organización, quien notifica y el NCSC.
La organización
Promover la CVD empieza por una organización que posee sistemas informáticos o que suministra un producto/sistema informático. Después de todo, esta organización es la principal responsable de la seguridad de la información de estos sistemas informáticos. Para trabajar con eficacia con diversas partes en la resolución de vulnerabilidades, una organización puede decidir elaborar y publicar una política de CVD. Elaborar su propia política de CVD permite a la organización demostrar cómo trata las notificaciones de vulnerabilidades. De este modo, una organización también puede dar forma a la manera en que desea recibir las notificaciones. Un proceso de este tipo puede organizarse de la siguiente manera:
La organización establece y publica una política de CVD.
En esta política, la organización proporciona normas claras para la investigación que pueden llevar a cabo las partes notificantes, como qué técnicas están permitidas y qué sistemas están dentro o fuera del alcance.
La organización facilita a la parte notificante la realización de una notificación. Una opción es el uso de un método de notificación estandarizado; por ejemplo, una dirección de correo electrónico específica o un formulario en línea. Además, la organización puede decidir si acepta notificaciones anónimas.
La organización reserva capacidad interna y establece un proceso para responder adecuadamente a las notificaciones. Es aconsejable establecer un proceso con el que cualquier vulnerabilidad encontrada pueda subsanarse adecuadamente. A este respecto, el origen de la notificación es irrelevante. La vulnerabilidad también puede haber sido identificada, por ejemplo, por un empleado interno o durante una prueba.
La experiencia práctica muestra que habrá un mayor interés en notificar vulnerabilidades a la organización tras la publicación inicial de una política de CVD. La organización debe tenerlo en cuenta al planificar la capacidad (adicional).
Cuando la organización recibe la notificación de la vulnerabilidad, se asegura de que llegue lo antes posible al departamento más adecuado para evaluarla y tratarla.
La organización envía un acuse de recibo de la notificación a la parte notificante, preferiblemente firmado digitalmente para subrayar la prioridad.
A continuación, la organización consultará con la parte notificante para determinar el plazo en el que se realizará cualquier publicación. Este plazo dependerá en gran medida de la naturaleza de la vulnerabilidad y del tipo de sistema.
Como pauta, para las vulnerabilidades de software se suele utilizar un plazo de unos 60 días. Subsanar las vulnerabilidades de hardware es más difícil; puede utilizarse una pauta de 6 meses.
Puede ser deseable ampliar o acortar este plazo de mutuo acuerdo en función de cuántos o cuán pocos sistemas informáticos dependan del sistema para el que se notificó la vulnerabilidad o de si la vulnerabilidad es más fácil o más difícil de resolver.
Una vulnerabilidad puede resultar difícil o imposible de resolver, o su resolución puede conllevar costes elevados. En tales casos, la organización puede acordar considerar la vulnerabilidad como un riesgo aceptado y no subsanarla, posiblemente en consulta con la parte notificante.
La organización mantendrá informada a la parte notificante sobre la evolución del proceso.
Además, la organización puede ofrecer que se reconozca públicamente a la parte notificante por publicar la vulnerabilidad. También es posible optar por una divulgación conjunta al exterior.
Es preferible recompensar a la parte notificante por notificar vulnerabilidades en sistemas si la parte ha cumplido las normas de la política de CVD. El importe de la recompensa puede depender de la calidad de la notificación. Recompensar a la parte notificante puede crear una mejor relación entre esa parte y la organización, además de aumentar la disposición de las personas a hacer nuevas notificaciones de acuerdo con la política de CVD.
En consulta con la parte notificante, la organización puede acordar informar a la comunidad informática en general sobre la vulnerabilidad si es plausible que la vulnerabilidad esté presente también en otros lugares.
En su política de CVD, la organización puede comprometerse con el principio de que no presentará una denuncia ante la policía si la parte notificante ha cumplido las normas expuestas en la política.
La parte notificante
La parte notificante es la clave de un proceso de CVD exitoso. De un modo u otro, esta parte ha podido identificar una vulnerabilidad y quiere contribuir a la seguridad de los sistemas informáticos haciendo que una organización subsane esta vulnerabilidad y que se haga pública. Al hacerlo, las partes notificantes reconocen que pueden hacer una contribución importante a la sociedad revelando vulnerabilidades de forma coordinada. Para lograr un proceso de CVD exitoso, los siguientes elementos básicos son importantes para la parte notificante:
La parte notificante es responsable de sus propias acciones y debe respetar los principios de proporcionalidad y de subsidiariedad al investigar y notificar vulnerabilidades. En otras palabras, la parte notificante no debe hacer más de lo necesario para demostrar la vulnerabilidad y debe notificar siempre la vulnerabilidad primero al propietario del sistema/de la información.
La parte notificante debe notificar el problema lo antes posible para evitar que partes maliciosas descubran la vulnerabilidad y se aprovechen de ella.
La parte notificante debe hacer la notificación a la organización de forma confidencial para evitar que otras personas accedan a esta información.
La parte notificante no puede condicionar la presentación de una notificación ni el suministro posterior de información a la recompensa. La iniciativa de conceder una recompensa en caso de notificación corresponde a la organización receptora, que puede establecer condiciones previas en su política publicada.
La parte notificante y la organización establecen acuerdos claros sobre la divulgación de la vulnerabilidad. Si hay más de una organización implicada, el principio básico es que las vulnerabilidades solo pueden publicarse si todas las organizaciones están de acuerdo. Es aconsejable establecer estos acuerdos en una fase temprana.
La parte notificante y la organización implicada pueden establecer acuerdos sobre cómo informar a la comunidad informática en general. Por ejemplo, esta situación puede darse con una vulnerabilidad (ya conocida o no) que se sabe que está presente en más de un lugar. El Centro Nacional de Ciberseguridad (NCSC) puede participar en este proceso para apoyar a los grupos destinatarios de la administración central y de las infraestructuras críticas o para informar a varias partes en caso de una vulnerabilidad que afecte a muchos sistemas.
El NCSC
El proceso de CVD es principalmente un asunto de las organizaciones y las partes notificantes. No obstante, el NCSC fomentará el uso de un proceso de CVD. En consulta con la parte notificante y la organización, el NCSC también puede participar en el intercambio de información sobre la vulnerabilidad con su comunidad de usuarios para limitar nuevos riesgos de seguridad derivados de la vulnerabilidad.
Si la notificación de la vulnerabilidad no transcurre como la parte notificante espera, o si prefiere no notificar la vulnerabilidad directamente a la organización, puede ponerse en contacto con el NCSC.⁴ En este caso, el NCSC puede actuar como intermediario cuando sea necesario.
El propietario del sistema informático es en todo momento responsable de la seguridad del sistema. El NCSC no puede obligar al propietario del sistema a subsanar una vulnerabilidad ni puede garantizar que el propietario no emprenderá acciones legales contra la parte notificante. Por ello, la parte notificante debe tener en cuenta los elementos básicos mencionados para organizaciones y partes notificantes al buscar y notificar una vulnerabilidad. Una parte notificante puede esperar que el NCSC haga todo lo posible para que se subsane la vulnerabilidad y trate la notificación de forma confidencial. El NCSC no comparte ningún dato personal salvo que esté legalmente obligado a ello.
Si es posible, el NCSC utilizará la información obtenida sobre vulnerabilidades, en consulta con las organizaciones y las partes notificantes, para seguir compartiendo el conocimiento con la comunidad informática. Por ejemplo, puede hacerlo publicando parte de la información, redactando o actualizando una ficha informativa o un libro blanco, o informando a organizaciones específicas.
Según la organización afectada y la naturaleza de la vulnerabilidad detectada, el NCSC se esforzará por poner la vulnerabilidad en conocimiento de la organización afectada. No obstante, el propietario del sistema informático en cuestión sigue siendo responsable del sistema.
Cuando sea posible y necesario, el NCSC asesorará a la organización afectada sobre cómo subsanar la vulnerabilidad.
El NCSC tratará las notificaciones de forma confidencial y no compartirá los datos personales de las partes notificantes ni de la organización receptora sin consentimiento, salvo que se derive de una obligación legal.
Siempre que sea posible, el NCSC mantendrá informada a la parte notificante de la evolución del contacto con la organización y de la subsanación de la vulnerabilidad.
En los casos en que se haga una notificación al NCSC, este intentará poner en contacto entre sí a la parte notificante o potencial parte notificante y a la organización.
Si una parte notificante ha encontrado una vulnerabilidad en un producto de software o una vulnerabilidad que afecta a muchos sistemas diferentes, por ejemplo, la parte notificante puede pedir al NCSC que coordine la subsanación y la divulgación de la vulnerabilidad.
Junto con la parte notificante, los socios, los desarrolladores y/o los desarrolladores de software y otros equipos de seguridad, el NCSC ayudará a analizar, subsanar o hacer que se subsane, coordinar y divulgar la vulnerabilidad de forma controlada. Todo este proceso se desarrolla en estrecha consulta con la parte notificante que encontró la vulnerabilidad.
Una política de CVD intenta lograr un equilibrio entre la importancia de divulgar las vulnerabilidades lo antes posible para que puedan tomarse medidas y la importancia de que los desarrolladores y los proveedores dispongan de tiempo suficiente para subsanar la vulnerabilidad. Para este proceso, el NCSC utiliza un plazo estándar de 60 días entre la notificación y la divulgación pública. No obstante, puede haber circunstancias en las que se decida ampliar o acortar este plazo.
El NCSC solo compartirá información sobre la vulnerabilidad con terceros tras consultar con la parte notificante. En este contexto es esencial que el NCSC coopere y, por tanto, comparta información sobre la vulnerabilidad con las partes interesadas para divulgar una vulnerabilidad de forma coordinada. Al hacerlo, el NCSC se asegurará de que las partes adecuadas puedan trabajar en la subsanación de la vulnerabilidad, ayudará a limitar cualquier pérdida o daño y ayudará a llamar la atención sobre la vulnerabilidad encontrada.
5. Comunicación y proceso de divulgación
Cinco años de práctica han demostrado que una comunicación clara es la piedra angular de un proceso de CVD exitoso. Hay puntos de atención antes, durante y después del proceso de CVD.
Comunicación sobre el proceso de divulgación
Publicar una política de CVD es un primer paso en la comunicación sobre el proceso. Al publicar una política de forma pública, se invita a las partes notificantes a informar a la organización de cualquier vulnerabilidad encontrada.
Por un lado, la organización puede establecer condiciones para la investigación que se realiza para descubrir vulnerabilidades y para la manera en que se busca el contacto. Por otro, la organización puede comprometerse con el principio de que no presentará una denuncia ante la policía si se respetan las normas de la política. Este enfoque protege la posición de la parte notificante.
Una política de CVD puede modificarse o actualizarse más adelante. Es importante ser claro sobre los cambios a este respecto. Las partes notificantes tienen interés en saber qué se ha cambiado y cuándo. Por ejemplo, los cambios pueden aclararse incluyendo una fecha de publicación al principio de la política de CVD, describiendo un resumen de los cambios debajo de la política de CVD o manteniendo un archivo con versiones antiguas de la política de CVD.
La política de CVD puede ofrecer pautas sobre cómo comunicarse durante el proceso, por ejemplo indicando actualizaciones periódicas por correo electrónico o por un portal web. Además, la política de CVD puede describir cómo se puede reconocer a quien notifica, mencionándolo en una actualización, incluyéndolo en un salón de la fama o mediante cualquier otra forma de recompensa.
Comunicación durante el proceso de divulgación
Una parte notificante inicia un proceso de CVD enviando un mensaje a la organización. En este mensaje, la parte notificante da una descripción clara de la vulnerabilidad descubierta. Elementos importantes son la dirección IP o la URL del sistema afectado y los pasos necesarios para reproducir la vulnerabilidad.
Es importante que la organización se comunique con claridad con la parte notificante para que las expectativas sobre el proceso estén claras.
Puede hacerlo ya enviando un acuse de recibo (automático o de otro tipo) que contenga una indicación del plazo en el que se enviará una respuesta sustantiva inicial o posterior.
También es posible dejar este plazo abierto y dar una primera indicación del plazo tras evaluar el contenido de la notificación. Es aconsejable aclarar lo antes posible el plazo en el que se puede lograr una solución. De este modo, quien notifica sabe cuándo puede esperar un resultado.
En algunos casos puede ocurrir que la parte notificante ya tenga clara una fecha de publicación; por ejemplo, por una presentación en una conferencia o porque la propia parte notificante ha fijado su plazo. En este caso, sigue siendo importante que la parte notificante comunique esta línea temporal con claridad, la indique lo antes posible y sea clara sobre la posibilidad o imposibilidad de aplazar esta fecha.
Una parte notificante suele ser alguien ajeno a la organización, que no tiene ninguna visión de los procesos internos que puede desencadenar una notificación. Las organizaciones pueden mantener informada a la parte notificante sobre la evolución del proceso mediante actualizaciones periódicas. Este enfoque deja claro a la parte notificante que se está trabajando en una solución. Cuando sea necesario, una organización puede solicitar aclaraciones o probar una solución durante el proceso.
Si una organización no puede cumplir el plazo de resolución inicial, puede hablarse con quien notifica para aplazarlo. Una comunicación periódica puede dejar clara esta situación a quien notifica en una fase más temprana.
La intención principal de la CVD es mitigar la vulnerabilidad, pero la «divulgación completa» de la vulnerabilidad es siempre una opción para una parte notificante si considera que el proceso va a tardar demasiado. Esta medida es el proverbial «gran garrote» a disposición de la parte notificante. Naturalmente, esta situación debe evitarse en la medida de lo posible.
Comunicación después del proceso de divulgación
Existen muchos motivos posibles por los que una parte notificante puede buscar vulnerabilidades y luego notificarlas a las organizaciones mediante el proceso de CVD. Para un gran número de partes notificantes, un incentivo importante es el reconocimiento (público).
Las partes notificantes reciben reconocimiento público mediante un agradecimiento en una actualización o la inclusión en un salón de la fama. Sin embargo, la necesidad de reconocimiento público no se aplica a todas las partes notificantes; de hecho, algunas no quieren que el público las conozca. Por ello, en caso de comunicación por parte de la organización, es aconsejable obtener el consentimiento de la parte notificante para nombrarla.
Además, las partes notificantes también pueden decidir comunicar una notificación una vez finalizado el proceso de CVD. Por ejemplo, la parte notificante puede describir el proceso de descubrimiento o advertir a otros sobre la vulnerabilidad. Quien notifica puede decidir enviar la publicación a una organización a título informativo. Como el proceso de CVD queda en principio completado tras la eliminación de la vulnerabilidad, la parte notificante es libre posteriormente de comunicarlo, salvo que se hayan acordado condiciones adicionales en la política o durante el proceso.
Lista
Comunicación sobre el proceso de divulgación
Publicación de la política de CVD en el sitio web
Ser claro sobre las restricciones (véase el capítulo 6 para los distintos enfoques)
Restricciones en los métodos de investigación
Pautas sobre la comunicación
Pautas sobre posibles recompensas: salón de la fama, recompensa económica, camiseta, etc.
Ser claro sobre cualquier actualización de la política de CVD, incluida la fecha de los cambios
Comunicación durante el proceso de divulgación
Quien notifica se pone en contacto con la organización sobre una vulnerabilidad descubierta.
La organización gestiona las expectativas, como el tiempo de respuesta para una primera respuesta técnica
La organización y quien notifica se aclaran mutuamente el plazo de resolución previsto
La organización proporciona con frecuencia una actualización (del proceso)
Cuando sea necesario, quien notifica y la organización hablan de contactar con otras organizaciones pertinentes
Comunicación después del proceso de divulgación
Hablar del reconocimiento (público) y de la recompensa de quien notifica
Acordar cómo se publicará la información sobre la vulnerabilidad, como la fase de investigación o la información a otras organizaciones
6. Ejemplos de política de divulgación coordinada de vulnerabilidades
Existen muchas formas diferentes de textos de política sobre divulgación coordinada de vulnerabilidades. Como la política de CVD publicada actúa como señal para las posibles partes notificantes, asegúrese de que la forma de esta política esté en consonancia con la política y la estrategia de la organización.
Los siguientes elementos son importantes en una política de CVD:
método de contacto para una comunicación segura;
condiciones previas para las partes notificantes;
expectativas claras sobre el tratamiento de una notificación;
método de recompensa de una notificación;
número de versión y fecha de la última revisión.
A continuación se ofrecen tres ejemplos: muchas organizaciones de los Países Bajos se han basado en el ejemplo básico de ResponsibleDisclosure.nl. Otras organizaciones incluyen condiciones previas adicionales; véase la política de Fox IT. Otras organizaciones más aplican un formato más libre para adaptarse a su público objetivo; véase la política de Bits of Freedom.
Ejemplo: ResponsibleDisclosure.nl
Este texto ha sido escrito por Floor Terra y se publica bajo una licencia Creative Commons Attribution 3.0 Unported.
En Acme Corporation consideramos que la seguridad de nuestros sistemas es una prioridad máxima. Pero por mucho esfuerzo que dediquemos a la seguridad de los sistemas, aún puede haber vulnerabilidades.
Si descubre una vulnerabilidad, nos gustaría saberlo para poder tomar medidas y abordarla lo antes posible.
Le pedimos que nos ayude a proteger mejor a nuestros clientes y nuestros sistemas.
Por favor, haga lo siguiente:
Envíe sus hallazgos por correo electrónico a cert@example.com. Cifre sus hallazgos con nuestra clave PGP para evitar que esta información crítica caiga en manos equivocadas,
No se aproveche de la vulnerabilidad o el problema que haya descubierto, por ejemplo descargando más datos de los necesarios para demostrar la vulnerabilidad o eliminando o modificando datos de otras personas,
No revele el problema a otras personas hasta que se haya resuelto,
No utilice ataques a la seguridad física, ingeniería social, denegación de servicio distribuida, spam ni aplicaciones de terceros, y
Facilite información suficiente para reproducir el problema, de modo que podamos resolverlo lo antes posible. Normalmente, la dirección IP o la URL del sistema afectado y una descripción de la vulnerabilidad serán suficientes, pero las vulnerabilidades complejas pueden requerir más explicaciones.
Lo que prometemos:
Responderemos a su informe en un plazo de 3 días hábiles con nuestra evaluación del informe y una fecha prevista de resolución,
Si ha seguido las instrucciones anteriores, no emprenderemos ninguna acción legal contra usted en relación con el informe,
Trataremos su informe con estricta confidencialidad y no transmitiremos sus datos personales a terceros sin su permiso,
Le mantendremos informado de los avances hacia la resolución del problema,
En la información pública sobre el problema notificado, indicaremos su nombre como descubridor del problema (salvo que desee otra cosa), y
Como muestra de nuestro agradecimiento por su ayuda, ofrecemos una recompensa por cada informe de un problema de seguridad que aún no conociéramos. El importe de la recompensa se determinará en función de la gravedad de la fuga y de la calidad del informe. La recompensa mínima será un cheque regalo de 50 €.
Nos esforzamos por resolver todos los problemas lo antes posible y nos gustaría desempeñar un papel activo en la publicación final sobre el problema una vez resuelto.
Ejemplo: Fox-IT
En Fox-IT consideramos que la seguridad de nuestros sistemas, nuestra red y nuestros productos es de suma importancia. A pesar del gran cuidado que ponemos en la seguridad, aún pueden quedar puntos débiles. Si ha encontrado un punto débil de este tipo, nos gustaría saberlo lo antes posible para poder tomar las medidas adecuadas cuanto antes.
Los puntos débiles pueden descubrirse de dos maneras: puede toparse con algo por casualidad durante el uso normal de un entorno digital, o puede esforzarse explícitamente por encontrarlos.
Nuestra política de divulgación responsable no es una invitación a escanear activamente nuestra red empresarial para descubrir puntos débiles. Nosotros mismos supervisamos nuestra red empresarial. Esto significa que hay muchas probabilidades de que se detecte un escaneo y de que nuestro Centro de Operaciones de Seguridad (SOC) realice una investigación, lo que podría generar costes innecesarios. Sin embargo, le invitamos a buscar activamente vulnerabilidades en nuestros productos en un entorno sin conexión que no sea de producción y a notificarnos sus hallazgos. Nuestra responsabilidad hacia nuestros clientes implica que no pretendemos fomentar intentos de piratería en su infraestructura; no obstante, nos gustaría saber de usted lo antes posible si se encuentran vulnerabilidades, para poder resolverlas adecuadamente.
Nos gustaría trabajar con usted para poder proteger mejor a nuestros clientes y nuestros sistemas.
Le pedimos que:
Envíe sus hallazgos por correo electrónico lo antes posible a security-alert@fox-it.com.
No abuse de la vulnerabilidad; por ejemplo, descargando, editando o eliminando datos. Siempre nos tomaremos en serio su informe e investigaremos cualquier sospecha de vulnerabilidad, incluso sin pruebas.
No comparta el problema con otras personas hasta que se haya resuelto.
No utilice ataques a la seguridad física, ingeniería social ni herramientas de piratería, como escáneres de vulnerabilidades.
Proporcione información suficiente para reproducir el problema para que podamos resolverlo lo antes posible. Normalmente, la dirección IP o la URL del sistema afectado y una descripción de la vulnerabilidad bastan, aunque puede ser necesaria más información para vulnerabilidades más complejas.
Lo que prometemos:
Responderemos a su informe en un plazo de tres días hábiles, con nuestra evaluación del informe y una fecha prevista de resolución.
Trataremos su informe de forma confidencial y no compartiremos su información personal con terceros sin su permiso. Se exceptúan la policía y el poder judicial en caso de procesamiento o si se exige la información.
Le mantendremos informado del avance de la solución al problema.
En la comunicación sobre el problema notificado, indicaremos su nombre como la parte que descubrió el problema, si así lo desea.
Lamentablemente, no es posible garantizar de antemano que no se emprenderán acciones legales contra usted. Esperamos poder considerar cada situación individualmente. Nos consideramos moralmente obligados a denunciarle si sospechamos que se está abusando del punto débil o de los datos, o que ha compartido con otros el conocimiento del punto débil. Puede estar tranquilo: un descubrimiento accidental en nuestro entorno en línea no dará lugar a un procesamiento.
Como agradecimiento por su ayuda, ofrecemos una recompensa por cada informe de un problema de seguridad que no conozcamos. Determinamos el valor de la recompensa en función de la gravedad de la brecha y de la calidad del informe.
Nos esforzamos por resolver todos los problemas lo antes posible, por mantener informadas a todas las partes implicadas y nos gustaría participar en cualquier publicación sobre el problema una vez resuelto.
Ejemplo: Bits of Freedom
Nuestra dependencia de la infraestructura digital no deja de crecer. Esto se aplica a la sociedad en su conjunto, pero también a nosotros mismos. Por ello, opinamos que los gobiernos y las organizaciones (incluida la nuestra) deberían comprometerse firmemente con la protección de nuestra infraestructura digital. Somos conscientes de que, a pesar de nuestras mejores intenciones y de nuestro mayor cuidado, pueden existir vulnerabilidades en nuestros sistemas. Si llega a encontrar alguna de estas debilidades, nos encantaría saber de usted para poder resolver el problema.
Lo que esperamos de usted
Cuando investigue uno de nuestros sistemas, tenga en cuenta la proporcionalidad del ataque. No es necesario demostrar que, si somete nuestro sitio web al mayor ataque DDoS de la historia de internet, el sitio puede quedar inaccesible. Ya lo sabemos. También entendemos que, si mete una excavadora en nuestra oficina, probablemente podrá llevarse uno de nuestros portátiles.
Este principio de proporcionalidad también es relevante al demostrar la propia vulnerabilidad. No debe inspeccionar ni modificar más datos de los estrictamente necesarios para confirmar la validez de su hallazgo. Por ejemplo, si puede modificar nuestra página de inicio, añada una sola palabra no polémica en lugar de apoderarse de toda la página. Si puede obtener acceso a una base de datos, basta con mostrarnos una lista de las tablas que contiene, o quizá el primer registro de una de ellas.
Una vulnerabilidad en uno de nuestros sistemas debe notificarse lo antes posible enviando un correo electrónico a security@bof.nl. Preferiblemente, cifre su mensaje con OpenPGP. Proporcione información suficiente para que podamos reproducir e investigar el problema.
La clave pública OpenPGP de security@bof.nl
No compartirá su conocimiento de la vulnerabilidad con otras partes mientras no hayamos abordado el problema y sigamos dentro de un plazo razonable desde que lo notificó.
Eliminará toda la información confidencial que haya obtenido durante su investigación en cuanto hayamos resuelto la vulnerabilidad.
Lo que puede esperar de nosotros
Responderemos a su informe en un plazo de tres días de manera detallada. Incluiremos una estimación del tiempo que necesitaremos para abordar el problema. Por supuesto, le mantendremos informado periódicamente de nuestros avances.
Resolveremos la vulnerabilidad lo antes posible. También aquí es importante la proporcionalidad: el tiempo necesario para corregir una vulnerabilidad depende de varios factores, entre ellos la gravedad y la complejidad del problema en cuestión.
Si sigue las directrices aquí expuestas, no emprenderemos acciones legales contra usted en relación con su informe.
Para nosotros es importante reconocer lo que hizo, si así lo desea. Mencionaremos su nombre en una publicación sobre la vulnerabilidad solo si usted está de acuerdo.
Como agradecimiento por ayudarnos a proteger mejor nuestros sistemas, nos gustaría recompensar cada informe de una vulnerabilidad que desconociéramos en ese momento. La recompensa dependerá de la gravedad de la vulnerabilidad y de la calidad del informe.
Si encuentra una vulnerabilidad en software de terceros que utilizamos y esa vulnerabilidad está cubierta por un programa de recompensas por errores, no intentaremos reclamar esa recompensa; debería hacerlo usted.