Todos sabemos la importancia de identificar y administrar las vulnerabilidades en nuestros sistemas, así como de parchearlas tan pronto como podamos, teniendo en cuenta la necesidad de probar los parches críticos del sistema antes de la implementación completa.
Sin embargo, la generación de parches y la priorización de las vulnerabilidades que deben abordarse se basa en la divulgación responsable y la gestión de esas vulnerabilidades, incluida la provisión de información sobre la vulnerabilidad.
Los investigadores de vulnerabilidades son una parte importante de este ecosistema y los desarrolladores de software deben alentar y recompensar la divulgación. Por lo tanto, la mayoría tendrá un proceso claro de divulgación de vulnerabilidades publicado, como se establece en ISO / IEC 29147: 2018, para ser utilizado por investigadores de vulnerabilidades y otros que identifican vulnerabilidades y las informan al desarrollador.
Los desarrolladores, por su parte, siempre deben reconocer el contacto rápidamente y decirles a los investigadores de vulnerabilidades cómo y en qué plazo abordarán el informe, dándoles en última instancia la confianza de que se abordará el problema. Los desarrolladores deben tener la responsabilidad de desarrollar y distribuir un parche que elimine la vulnerabilidad de manera oportuna (por lo general, 90 días).
En consecuencia, el informe debe incluir escalas de tiempo en las que se reconocerá y abordará, así como información sobre cualquier incentivo para el investigador de vulnerabilidades que informa.
Además, el proceso de informe del desarrollador de software debe estar en línea e incluir una dirección de correo electrónico dedicada para informar, junto con un mecanismo para cifrar el informe (normalmente una clave pública PGP o equivalente).
Asimismo, quienes informan sobre la vulnerabilidad deben actuar de manera responsable y no divulgarla públicamente hasta que el desarrollador haya podido desarrollar un parche. En la mayoría de los casos, si el desarrollador no ha respondido y / o producido un parche dentro de un tiempo razonable, el investigador de vulnerabilidades puede optar por publicar, pero debe actuar de manera responsable y mantener un diálogo con el desarrollador.
Sin embargo, en algunas jurisdicciones, existen consideraciones legales cuando se trata de divulgar vulnerabilidades, donde seguir el proceso de divulgación puede proteger al investigador de vulnerabilidades.
En el caso de las grandes empresas con un historial de actualización inmediata de su software, generalmente hay una razón para la demora, y un recordatorio de que la divulgación inmediata puede no ser el mejor curso de acción. Revelar públicamente una vulnerabilidad es un gran paso que debe dar un investigador de vulnerabilidades mientras no haya un parche disponible, y al menos debe dejar en claro su intención y darle al desarrollador una última oportunidad de responder antes de revelarla.
Sin embargo, si un desarrollador claramente se está demorando y hay pocas posibilidades de que se implemente un parche, la divulgación limitada puede estar justificada. Después de todo, si un investigador puede encontrar una vulnerabilidad, es solo cuestión de tiempo antes de que un actor malintencionado la descubra y la explote sin previo aviso. Si bien la divulgación pública permitirá a los atacantes generar exploits para la vulnerabilidad, al menos los usuarios del software serán conscientes del riesgo y podrán desarrollar mitigaciones.
En algunos casos, normalmente con empresas tecnológicas más grandes, el desarrollador y el investigador de vulnerabilidades serán parte de la misma organización, pero el proceso básico debería ser el mismo. Sin embargo, el incentivo para actuar puede no ser tan fuerte.
Como parte del proceso de divulgación y parcheo, se producirá una exposición de vulnerabilidad común (CVE), generalmente iniciada por el investigador de vulnerabilidades. La información contenida en el CVE es una parte importante de la gestión de vulnerabilidades en un sistema.
Los sistemas de gestión de vulnerabilidades que escanean y notifican vulnerabilidades se basan en la información de CVE para detectar parches faltantes e informar la gravedad de una vulnerabilidad existente. Además, cuando se requieren pruebas exhaustivas de un parche, la información sobre la vulnerabilidad a menudo se puede utilizar para mitigar el riesgo de explotación mediante el uso de reglas del sistema de detección de intrusos o firewall mientras se prueba el parche.
La creación de CVE es una parte importante de este proceso, particularmente para vulnerabilidades críticas. Si bien el CVE es en sí mismo una revelación de la vulnerabilidad, debemos recordar que la emisión de un parche permite que un atacante realice ingeniería inversa del parche e identifique tanto el código que se está reemplazando como la vulnerabilidad que se está parcheando. Esto se puede hacer en cuestión de minutos y a veces se desarrolla un exploit en cuestión de horas.
Por lo tanto, si se parchean las vulnerabilidades críticas como parte de una actualización de software de rutina sin que se emita un CVE, los usuarios no serán conscientes del riesgo y no podrán mitigarlo mientras se prueba el parche para su entorno. Además, una vez que se ha emitido un parche, los investigadores de vulnerabilidades pueden sentir que pueden publicitar o demostrar la explotación de la vulnerabilidad para mejorar su perfil.
En última instancia, el proceso de divulgación de vulnerabilidades no se puede hacer cumplir legalmente y se basa exclusivamente en la confianza en las personas para hacer lo correcto, incentivada por el beneficio mutuo y la necesidad de evitar la publicidad inevitable cuando las cosas van mal. En general, la divulgación responsable funciona bastante bien, sin embargo, como con todo en la vida, siempre hay margen de mejora en todos los aspectos.
