Desarrollar un sistema para evaluar qué tan en serio la comunidad de desarrollo de software debe tomar las vulnerabilidades es un desafío, por decirlo suavemente. El código está escrito por humanos y siempre tendrá errores. Entonces, la pregunta, asumiendo que nada será perfecto, es ¿cómo podemos clasificar mejor los componentes de acuerdo con su riesgo de una manera que nos permita continuar trabajando productivamente?
Solo los hechos
Aunque hay muchos enfoques diferentes que se pueden tomar para 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, utilizar un enfoque cuantitativo para juzgar la gravedad de una vulnerabilidad puede ser útil porque es más objetivo y medible, basándose únicamente en factores relacionados con la propia vulnerabilidad.
Esta metodología analiza qué tipo de daño podría ocurrir si se explotara la vulnerabilidad, teniendo en cuenta qué tan ampliamente utilizado es el componente, biblioteca o proyecto en la industria del software, así como factores como el tipo de acceso que podría proporcionar a un atacante. causar estragos si lo usan para violar su objetivo. Factores como la minería ligera potencial pueden jugar un papel importante aquí al afectar el puntaje. (Para obtener más información sobre seguridad, consulte Ciberseguridad: cómo los nuevos avances generan nuevas amenazas y viceversa).
Si queremos ver el nivel macro, la perspectiva cuantitativa analiza cómo una vulnerabilidad podría dañar al rebaño, enfocándose menos en el daño que podría recaer sobre las empresas que realmente se ven afectadas.
La Base de datos nacional de vulnerabilidades (NVD), probablemente la base de datos de vulnerabilidades más conocida, adopta este enfoque para las versiones 2 y 3 del Sistema de puntuación de vulnerabilidad común (CVSS). En su página que explica sus métricas para la evaluación de vulnerabilidades, escriben sobre su método que:
Su modelo cuantitativo garantiza una medición precisa y repetible al mismo tiempo que permite a los usuarios ver las características de vulnerabilidad que se utilizaron para generar las puntuaciones. Por lo tanto, CVSS es adecuado como sistema de medición estándar para industrias, organizaciones y gobiernos que necesitan puntajes de impacto de vulnerabilidad precisos y consistentes.
En función de los factores cuantitativos en juego, NVD puede generar una puntuación de gravedad, tanto un número en su escala, del 1 al 10, siendo 10 el más grave, y categorías de BAJO, MEDIO y ALTO.
¿Contabilidad de impacto?
Sin embargo, NVD parece estar haciendo un esfuerzo por mantenerse alejado de lo que podemos llamar una medida más cualitativa de una vulnerabilidad basada en el impacto que tuvo un exploit en particular al causar daño. Para ser justos, incorporan el impacto a medida que miden el impacto de la vulnerabilidad en el sistema, teniendo en cuenta los factores de confidencialidad, integridad y disponibilidad. Todos estos son elementos importantes a considerar, como un vector de acceso más fácil de medir, la complejidad del acceso y la autenticación, pero no se sienten capaces de informar el impacto en el mundo real cuando una vulnerabilidad causa una pérdida real a una organización.
Tomemos, por ejemplo, la violación de Equifax que expuso la información de identificación personal de alrededor de 145 millones de personas, incluidos los detalles de la licencia de conducir, números de seguro social y otros bits que podrían ser utilizados por personajes sin escrúpulos para llevar a cabo transacciones masivas de fraude.
La vulnerabilidad (CVE-2017-5638) que se descubrió en el proyecto Apache Struts 2 que Equifax usó en su aplicación web fue lo que permitió a los atacantes entrar por la puerta principal y finalmente salir con los brazos llenos de jugosa información personal. .
Si bien NVD le otorgó correctamente un puntaje de gravedad de 10 y ALTO, su decisión se debió a su evaluación cuantitativa de los daños potenciales y no se vio afectada por los daños extensos que ocurrieron más tarde cuando la violación de Equifax se hizo pública.
Esto no es un descuido por parte de NVD, sino parte de su política declarada.
NVD proporciona «puntuaciones básicas» de CVSS que representan las características innatas de cada vulnerabilidad. Actualmente no ofrecemos «puntuaciones temporales» (puntuaciones que cambian con el tiempo debido a eventos externos a la vulnerabilidad) o «puntuaciones ambientales» (puntuaciones personalizadas para reflejar el impacto de la vulnerabilidad en su organización).
Para los formuladores de políticas, el sistema de medición cuantitativa debería importar menos a medida que analizan las posibilidades de que propague el daño a toda la industria. Si usted es el CSO de un banco, debería preocuparse por el impacto cualitativo que puede tener un exploit si se utiliza para desviar el dinero de sus clientes, o peor aún, su dinero. (Obtenga información sobre los diferentes tipos de vulnerabilidades en Las 5 amenazas tecnológicas más aterradoras).
¿Es hora de cambiar el sistema?
Entonces, la vulnerabilidad en Apache Trusts 2 que se usó en el caso de Equifax debería obtener una clasificación más alta a la luz de cuán extenso resultó ser el daño, o haría que el cambio fuera demasiado subjetivo para un sistema como NVD. ¿Mantenga?
Admitimos que obtener los datos necesarios para obtener una «puntuación ambiental» o una «puntuación temporal» como la describe NVD sería extremadamente difícil, lo que expondría a los administradores de equipos gratuitos de CVSS a críticas interminables y mucho trabajo. para NVD y otros para actualizar las bases de datos a medida que se dispone de nueva información.
Está, por supuesto, la cuestión de cómo se compilaría tal puntaje, ya que es probable que muy pocas organizaciones proporcionen los datos necesarios sobre el impacto de una infracción a menos que lo exija la ley de divulgación. Hemos visto en el caso de Uber que las empresas están dispuestas a hacerlo paga rapido con la esperanza de evitar que la información sobre una violación llegue a los medios de comunicación para que no enfrente una reacción negativa del público.
Quizás lo que se necesita es un nuevo sistema que incorpore los buenos esfuerzos de las bases de datos de vulnerabilidades y agregue su propia puntuación adicional a medida que la información esté disponible.
¿Por qué instigar esta capa adicional de puntuación cuando la anterior parece haber hecho el trabajo lo suficientemente bien todos estos años?
Francamente, todo se reduce a la responsabilidad de las organizaciones de asumir la responsabilidad de sus aplicaciones. En un mundo ideal, todos verificarían las puntuaciones 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. .
Tal vez 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 verse atrapadas por componentes de riesgo. Como mínimo, podrían tomar medidas para hacer un inventario real de las bibliotecas de código abierto que ya tienen.
Después Equifax fiasco, varios ejecutivos de nivel C probablemente estaban luchando para asegurarse de que no tuvieran la versión vulnerable de Struts en sus productos. Es desafortunado que haya sido necesario un incidente de esta magnitud para empujar a la industria a tomar en serio la seguridad de código abierto.
Esperamos que la lección de que las vulnerabilidades en los componentes de código abierto de sus aplicaciones pueden tener consecuencias muy reales afectará la forma en que los tomadores de decisiones priorizan la seguridad, eligiendo las herramientas adecuadas para mantener seguros sus productos y los datos de los clientes.
