Ocho siglas relacionadas con las vulnerabilidades (IV): CWSS

viernes, 23 de mayo de 2014

Como el resto de métricas que estamos observando en esta serie, CWSS (Common Weakness Scoring System) también es un sistema de valoración que se encarga de parametrizar la criticidad de las debilidades de software. También fue creado por el MITRE como parte del proyecto CWE.

CWSS ofrece un mecanismo estandarizado que permite evaluar (de manera objetiva y a nivel de desarrollo) las posibles debilidades típicas que puedan estar presentes en el software por su naturaleza y pudieran convertirse en una vulnerabilidad con posibilidades de ser explotada. Por ejemplo, si una aplicación web que almacene información en una base de datos SQL no gestionara correctamente las entradas recibidas por la aplicación (esta sería la debilidad) sería posible aprovechar algún tipo de inyección SQL (vulnerabilidad) para obtener información sensible. Al tratarse de una vulnerabilidad "típica" en este tipo de sistemas, conviene parametrizarla para poder darle una prioridad a su estudio y en resumen, una mejor gestión.

Basándose en este sistema de valoración se pretende ayudar a la toma de decisiones relacionadas con las prioridades de estas debilidades. En la práctica, esto puede ser utilizado para alertar a los consumidores y empresas creadoras de software acerca de los fallos más típicos y críticos que existen en la actualidad, permitiendo que sean capaces de tener una referencia en cuanto a los requerimientos que debe cumplir el software que contraten o desarrollen según sea el caso. También, priorizar el desarrollo interno en un grupo de programadores.

Una diferencia con respecto a las iniciativas ya comentadas en entradas anteriores, es que no existe una web, servicio o aplicación conocida que en realidad utilice este sistema para valorar las debilidades públicamente, tal y como se hace comúnmente con, por ejemplo, el CVSS.

En sus inicios, este sistema se solía promover a través de publicaciones (como por ejemplo los documentos desarrollados entre el MITRE y SANS Institute del tipo Top 25 Most Dangerous Software Errors), sin embargo, en la actualidad es difícil encontrar información reciente asociada a debilidades de software. Puede deberse a que hoy por hoy la lista CWE (Common Weakness Enumeration) se actualiza muy poco. Además, las empresas de desarrollo de software protegen el código de sus aplicaciones y su estudio, valoración y resolución se suele gestionar de manera privada sin compartir la información.

Objetivos y funciones

Está patrocinado por el Software Assurance program de la oficina de ciberseguridad y comunicaciones del U.S. Department of Homeland Security (DHS). En la web de este proyecto, definen una serie funciones que pueden cumplir el CWSS, entre las que destacan:
  • Proporcionar un estándar que puede ser utilizado para priorizar errores descubiertos en el software que afecten a la seguridad de estos, y utilizados por desarrolladores para priorizar las soluciones que deben implementarse según la criticidad de estos fallos.
  • Proporcionar una medida cuantitativa de las debilidades no solucionadas que pueden encontrarse en el software.
  • Puede ser utilizado por los consumidores para identificar las debilidades más importantes que afectan a sus dominios de negocio, e informar acerca de las actividades de protección necesarios para garantizar la calidad del software que estos necesitan. 
Al igual que el CVSS, este sistema de valoración agrupa en tres grupos de métricas los distintos factores que estudia relacionados a las debilidades del software. En este caso son 18 factores los que se encargan de definir el valor de estas métricas.

Base Finding


Se encarga de estudiar el riesgo inherente a la debilidad, la fiabilidad del descubrimiento y fortaleza de los controles.

Como puede observarse en la imagen anterior, los factores en esta métrica van relacionados directamente con las características de la debilidad encontrada. Entre estas características se encuentran:
  • Technical Impact: Este es el posible impacto que pueda generar la debilidad en caso de que pueda ser aprovechada para explotar una vulnerabilidad. Al igual que en el CVSS estas se evalúan en base a cómo puede verse afectado el software en cuanto a confidencialidad, integridad y la disponibilidad se refiere.
  • Acquired Privilege: Este se refiere al tipo de privilegios que puede obtener un atacante que logre explotar la debilidad.
  • Acquired Privilege Layer: Se encarga de definir el entorno al que pudiera tener acceso un atacante en caso explotar la debilidad y de obtener los privilegios mencionados en el factor anterior.
  • Internal Control Effectiveness: Hace referencia a los posibles mecanismos de protección o mitigación implementados de forma explícita en el código para evitar que sea vulnerado el software a través de esta debilidad. Con esta característica se busca medir la efectividad que tienen estos mecanismos de controlar la debilidad para que un atacante no pueda explotarla.
  • Finding Confidence: Este determina el nivel de certidumbre que se tiene acerca de que lo reportado es una debilidad explotable, y si de verdad el atacante puede aprovecharla para explotar una vulnerabilidad. 

Attack Surface 

Como puede observarse en la imagen anterior, los factores de esta métrica guardan relación con las barreras que un atacante necesite atravesar para poder aprovechar el fallo y explotar una vulnerabilidad. Entre estas características se encuentran:
  • Required Privilege: Identifica el tipo de privilegio necesario que se debe tener para poder acceder a la funcionalidad que contiene la debilidad (usuario regular, invitado, ninguno, administrador, privilegios especiales, etc.).
  • Required Privilege Layer: Detalla la capa de operaciones (sistema, aplicación, red, etc.) que se debe acceder en caso de que la debilidad pueda ser explotada.
  • Access Vector (AV): Reseña el canal (Internet, Intranet, acceso local, etc.) a través del que se puede alcanzar la debilidad.
  • Authentication Strength: Este mide la fortaleza (alta, moderada, baja, ninguna, etc.) de la rutina de autenticación que protege la funcionalidad que contiene la debilidad.
  • Authentication Instances: Establece el número de autenticaciones que deben hacerse antes de poder acceder a la debilidad.
  • Level of Interaction: Determina el nivel de interacciones necesarias por parte de la víctima para que un ataque que se aproveche de la debilidad pueda tener lugar.
  • Deployment Scope: Identifica si la debilidad está presente en todas las versiones e instancias de despliegue del software, o si solo afecta a un subconjunto de plataformas o configuraciones específicas.

Environmental 

Contiene todos los factores que pueden ser específicos a un contexto operacional concreto como podría ser el impacto en el negocio, la probabilidad de explotación o la existencia de controles externos.
  • Business Impact: Describe el impacto potencial que puede sufrir el servicio si la debilidad fuera explotada.
  • Likelihood of Discovery: Establece la probabilidad (alta, media, baja, etc.) de que un atacante descubra la debilidad.
  • Likelihood of Exploit: Define la probabilidad de que un atacante con los privilegios y/o autenticación necesarios sea capaz d explotar la debilidad una vez la haya encontrado.
  • External Control Effectiveness: Hace referencia a la capacidad que tienen los controles o medidas de mitigación (externos a la aplicación) que eviten que una debilidad pueda ser aprovechada.
  • Remediation Effort: Es la cantidad de esfuerzo necesario para remediar la debilidad de manera que esta ya no comprometa la seguridad del software.
  • Prevalence: Identifica la frecuencia con que la debilidad se suele encontrar en el software en general. 

Aunque esta métrica no sea tan reconocida y utilizada como otras mencionadas, sí que son muy útiles entre grupos de desarrollo para la organización y priorización de tareas a lo largo del ciclo de vida de desarrollo del software.

En siguientes entradas hablaremos de otras dos siglas relacionadas con el ámbito de las debilidades y vulnerabilidades: CVRF y CWRAF.

* Ocho siglas relacionadas con las vulnerabilidades (I): CVE
Ocho siglas relacionadas con las vulnerabilidades (II): CWE y CAPEC
Ocho siglas relacionadas con las vulnerabilidades (III): CVSS

Umberto Schiavo
umberto.schiavo@11paths.com

No hay comentarios:

Publicar un comentario en la entrada