Ocho siglas relacionadas con las vulnerabilidades (y VII): CPE

miércoles, 10 de septiembre de 2014

Para finalizar con esta serie de entradas asociadas a las vulnerabilidades, el MITRE dispone de otra iniciativa llamada Common Platform Enumeration (CPE). En resumen, permite identificar con un nombre único y estándar los sistemas, plataformas y software de una manera muy detallada.

Las necesidades que el CPE se encarga de satisfacer son:
  • Un formato estandarizado para referirse a productos y plataformas que pueda ser utilizado por otras herramientas.
  • Un conjunto de procedimientos para la comparación de nombres.
  • Un lenguaje para la construcción de "declaraciones de aplicabilidad", que combinan un CPE con operadores lógicos simples.Un diccionario CPE y una noción general para la interpretación de los nombres CPE contenidos en él.

Esta iniciativa puede llegar a parecer un tanto simple a primera vista. ¿No tienen ya los productos hardware o software un nombre perfectamente definido? Sí, pero no pueden ser tratados a nivel de programación, y ciertos nombres (si no se conoce específicamente el producto) no permiten saber, a simple vista, si se trata de un software, hardware, sistema operativo, aplicación, etc. Usando CPE esto es posible, entre otras muchas cosas. Gracias a esto se puede saber, de forma totalmente unívoca y exacta, por ejemplo qué versiones, ediciones o en qué idiomas, un producto se ve afectado por una vulnerabilidad.

Obviamente, CPE puede integrarse dentro del Common Vulnerability Reporting Framework (CVRF), utilizada para reportar toda aquella información asociada a una vulnerabilidad. Dentro de este framework, se utiliza el CPE para hacer referencia a tecnologías, herramientas, sistemas o plataformas específicas con la mayor exactitud posible.

Aunque este diccionario es propio del MITRE, en la actualidad, el National Institute of Standards and Technology (NIST) mantiene una versión autorizada para distribución como parte de su iniciativa U.S. National Vulnerability Database (NVD), a la vez que alberga todos los documentos de especificación y aplicabilidad correspondientes al CPE.

La versión 2.3

Creada ya a mediados de 2011, introducía cambios interesantes. La versión 2.2 mantenía una estructura "simple" que se fundamentaba en este esquema:

cpe:/ {part} : {vendor} : {product} : {version} : {update} : {edition} : {language}

En el que por ejemplo,

cpe:/o:microsoft:windows_xp:::pro

Representaba a los Windows XP Profesional en cualquier versión, lenguaje o edición. También existía un diccionario en XML en el que se almacenaba toda la información de productos, para "oficializar". La versión 2.3 CPE, sin embargo, creó un modelo más rico y complejo, además de tener que mantener compatibilidad hacia atrás. Si anteriormente se basaba en el concepto de URI, en ella se introdujo el concepto de Well Formed CPE Name o WFN. El WFN viene a ser algo así:

wfn:[part="a",vendor="microsoft",product="internet_explorer",
version="8\.0\.6001",update="beta"]

O por ejemplo,

wfn:[part="a",vendor="microsoft",product="internet_explorer",
version="8\.*",update="sp?",edition=NA,language=ANY]

Para referirse a Microsoft Internet Explorer 8.* SP? (sin edición y en cualquier lenguaje).

Los campos que puede manejar son bastante explícitos.

Compatibilidad hacia atrás

En el documento del NIST, se especifica cómo pasar de WFN a formato URI "tradicional". Por ejemplo, el WFN anterior de Internet Explorer 8.0.6001 quedaría:

cpe:/a:microsoft:internet_explorer:8.0.6001:beta

Para conseguir traducir todo WFN hacia el formato 2.2, se ha tenido que "inventar" otra fórmula donde el CPE contiene "subcampos" dentro de los ya conocidos ":" pero estos separados por la virgulilla "~". Por ejemplo, supongamos que tenemos el producto HP Insight Diagnostics 7.4.0.1570
Online Edition para Windows 2003 x64 y su WFN sería:

wfn:[part="a",vendor="hp",product="insight_diagnostics",
version="7\.4\.0\.1570",update=NA,
sw_edition="online",target_sw="win2003",target_hw="x64"] 

Ahora se traduciría, manteniendo la compatibilidad hacia atrás en la versión 2.2, de CPE de esta forma:

cpe:/a:hp:insight_diagnostics:7.4.0.1570:-:~~online~win2003~x64~

En el que se "empaquetan" bajo la virgulilla los campos que no existían (o para las que se "reciclaban" campos) en la versión 2.2 "pura" del CPE (son sw_edition, target_sw y target_hw)

Otra fórmula

Pero también se define otra fórmula para asociar el WFN a un formato, que si bien se parece al CPE tradicional (una URI) y se representa con el mismo espíritu, resulta en un formato ligeramente diferente. El ejemplo anterior, sería:

cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:*

En el que se deja más claro que el CPE es de la versión 2.3 y que permite especificar más atributos con cualquier valor (el asterisco). Otro ejemplo. El WFN:

wfn:[part="a",vendor="hp",product="insight",
version="7\.4\.0\.1570",update=NA,
sw_edition="online",target_sw="win2003",target_hw="x64"]

Se traduciría en, "formato URI 2.3":

cpe:2.3:a:hp:insight:7.4.0.1570:-:*:*:online:win2003:x64:*

El "guión" hablaría de que el "update" está "NA" (no aplica), y los asteriscos a que este CPE casa con cualquier valor.

Para mayor información acerca de las especificaciones de los nombres de CPE se puede consultar la documentación ofrecida por el NIST.

Entre algunas de las compañías que implementan o cuyas herramientas permiten implementar esta iniciativa a través de plugins, se encuentran: Dell, Hewlett-Packard, McAfee, Microsoft, Qualys, Rapid7, Symantec, VMware...

* 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
Ocho siglas relacionadas con las vulnerabilidades (IV): CWSS
Ocho siglas relacionadas con las vulnerabilidades (V): CVRF
* Ocho siglas relacionadas con las vulnerabilidades (VI): CWRAF


Umberto Schiavo
umberto.schiavo@11paths.com

No hay comentarios:

Publicar un comentario