Contenido
- Solo los hechos
- Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
- ¿Contabilidad para el impacto?
- ¿Hora de cambiar el sistema?
Fuente: BrianAJackson / iStockphoto
Para llevar:
Es hora de cambiar las cosas con la forma en que pensamos sobre la evaluación del riesgo para los componentes de código abierto.
Desarrollar un sistema para evaluar la seriedad con la que la comunidad de desarrollo de software debe tomar las vulnerabilidades es un desafío, para decirlo con ligereza. El código está escrito por humanos y siempre tendrá fallas. La pregunta, entonces, si suponemos que nada será perfecto, ¿cómo clasificamos mejor los componentes de acuerdo con su riesgo de una manera que nos permita continuar trabajando productivamente?
Solo los hechos
Si bien hay muchos enfoques diferentes que uno podría adoptar para abordar este problema, cada uno con su propia justificación válida, el método más común parece estar basado en un modelo cuantitativo.
Por un lado, el uso de un enfoque cuantitativo para juzgar la gravedad de una vulnerabilidad puede ser útil, ya que es más objetivo y medible, basado únicamente en los factores relacionados con la vulnerabilidad en sí.
Esta metodología analiza qué tipo de daño podría ocurrir si se explota la vulnerabilidad, teniendo en cuenta qué tan ampliamente utilizado se utiliza el componente, la biblioteca o el proyecto en toda la industria del software, así como factores como el tipo de acceso que podría darle a un atacante. causar estragos en caso de que lo usen para violar su objetivo. Factores como la fácil explotación potencial pueden desempeñar un papel importante aquí al afectar el puntaje. (Para obtener más información sobre seguridad, consulte Ciberseguridad: cómo los nuevos avances traen nuevas amenazas, y viceversa).
Si queremos mirar en un nivel macro, la perspectiva cuantitativa analiza cómo una vulnerabilidad podría dañar al rebaño, centrándose menos en el daño que podría caer sobre las compañías que realmente son golpeadas con el ataque.
La National Vulnerability Database (NVD), quizás la base de datos de vulnerabilidades más conocida, adopta este enfoque para las versiones 2 y 3 de su Sistema de puntuación de vulnerabilidad común (CVSS). En su página que explica sus métricas para evaluar vulnerabilidades, escriben sobre su método que:
Su modelo cuantitativo garantiza una medición precisa y repetible al tiempo que permite a los usuarios ver las características de vulnerabilidad subyacentes que se utilizaron para generar las puntuaciones. Por lo tanto, CVSS es muy adecuado como un sistema de medición estándar para industrias, organizaciones y gobiernos que necesitan puntajes de impacto de vulnerabilidad precisos y consistentes.
Basado en los factores cuantitativos en juego, el NVD puede llegar a un puntaje de severidad, ambos con un número en su escala, del 1 al 10, siendo 10 el más severo, así como categorías de BAJO, MEDIO y ALTO .
Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
No puede mejorar sus habilidades de programación cuando a nadie le importa la calidad del software.
¿Contabilidad para el impacto?
Sin embargo, el NVD parece estar haciendo un esfuerzo por mantenerse alejado de lo que podemos llamar más una medida cualitativa de una vulnerabilidad, en función de cuán impactante ha sido un determinado exploit en causar daños. Para ser justos, incorporan impacto en la medida en que miden el impacto de la vulnerabilidad en el sistema, observando los factores de confidencialidad, integridad y disponibilidad. Todos estos son elementos importantes a tener en cuenta, como con el vector de acceso, la complejidad del acceso y la autenticación más fáciles de medir, pero no están a la altura de la tarea de relacionar el impacto en el mundo real cuando una vulnerabilidad causa pérdidas reales en una organización.
Tomemos, por ejemplo, la violación de Equifax que expuso la información de identificación personal de unos 145 millones de personas, incluidos los detalles de su licencia de conducir, números de seguridad social y otros bits que podrían ser utilizados por personajes sin escrúpulos para llevar a cabo operaciones masivas de fraude.
Fue la vulnerabilidad (CVE-2017-5638) que se descubrió en el proyecto Apache Struts 2 que Equifax usó en su aplicación web lo que permitió a los atacantes entrar por la puerta principal y finalmente salir con los brazos llenos de información personal jugosa. .
Si bien el NVD le dio correctamente un puntaje de severidad de 10 y ALTO, su decisión se debió a su evaluación cuantitativa de su daño potencial y no se vio afectada por el daño extenso que ocurrió más tarde cuando la violación de Equifax se hizo pública.
Esto no es un descuido por parte del NVD, sino una parte de su política establecida.
El NVD proporciona "puntajes base" de CVSS que representan las características innatas de cada vulnerabilidad. Actualmente no proporcionamos "puntajes temporales" (métricas que cambian con el tiempo debido a eventos externos a la vulnerabilidad) o "puntajes ambientales" (puntajes personalizados para reflejar el impacto de la vulnerabilidad en su organización).
Para los tomadores de decisiones, el sistema de medición cuantitativa debería tener menos importancia, ya que está considerando las posibilidades de que se extienda el daño en toda la industria. Si usted es la OSC de un banco, debería preocuparse por el impacto cualitativo que puede tener un exploit si se utiliza para eliminar los datos de sus clientes, o peor aún, su dinero. (Obtenga información sobre los diferentes tipos de vulnerabilidades en Las 5 amenazas más aterradoras de la tecnología).
¿Hora de cambiar el sistema?
Entonces, si la vulnerabilidad en Apache Strusts 2 que se usó en el caso Equifax recibiera una clasificación más alta a la luz de cuán extenso resultó ser el daño, o hacer que el cambio sea demasiado subjetivo para un sistema como el NVD seguir adelante?
Concedemos que encontrar los datos necesarios para obtener un "puntaje ambiental" o "puntaje temporal" según lo descrito por el NVD sería extremadamente difícil, abriendo a los gerentes del equipo CVSS gratuito a críticas interminables y un montón de trabajo para el NVD y otros para actualizar sus bases de datos a medida que sale nueva información.
Existe, por supuesto, la pregunta sobre cómo se compilaría dicha puntuación, ya que muy pocas organizaciones pueden ofrecer los datos necesarios sobre el impacto de una violación a menos que una ley de divulgación lo exija. En el caso de Uber, hemos visto que las empresas están dispuestas a pagar rápidamente con la esperanza de evitar que la información sobre una violación llegue a la prensa para que no se enfrenten a una reacción pública.
Quizás lo que sea necesario sea un nuevo sistema que pueda incorporar los buenos esfuerzos de las bases de datos de vulnerabilidades y agregar su propio puntaje adicional cuando la información esté disponible.
¿Por qué instigar esta capa adicional de puntuación cuando la anterior parece haber hecho su trabajo lo suficientemente bien todos estos años?
Francamente, todo se reduce a la responsabilidad de que las organizaciones asuman la responsabilidad de sus aplicaciones. En un mundo ideal, todos verificarían los puntajes de los componentes que usan en sus productos antes de agregarlos a su inventario, recibirían alertas cuando se descubrieran nuevas vulnerabilidades en proyectos que antes se consideraban seguros e implementarían los parches necesarios por su cuenta. .
Quizás si hubiera una lista que mostrara cuán devastadoras podrían ser algunas de estas vulnerabilidades para una organización, entonces las organizaciones podrían sentir más presión para no quedar atrapadas con componentes riesgosos. Como mínimo, podrían tomar medidas para hacer un inventario real de las bibliotecas de código abierto que ya tienen.
Después del fiasco de Equifax, es probable que más de un ejecutivo de nivel C se esforzara por asegurarse de que no tenían la versión vulnerable de Struts en sus productos. Es lamentable que haya tenido un incidente de esta magnitud para empujar a la industria a tomar en serio su seguridad de código abierto.
Con suerte, la lección de que las vulnerabilidades en los componentes de código abierto de sus aplicaciones pueden tener consecuencias muy reales tendrá un impacto en cómo los tomadores de decisiones priorizan la seguridad, eligiendo las herramientas adecuadas para mantener seguros sus productos y los datos de sus clientes.