lunes, mayo 21, 2012

Common Vulnerability Reporting Framework 1.1

Los días que hay muchos advisories de trabajo siempre pienso en mi amigo Sergio de los Santos echando "ofús". Esos días debe filtrar todos los documentos publicados por los fabricantes de software para que sean distribuidos a través de su servicio SANA y para ello debe pegarse con las maneras que cada uno de los fabricantes tienen de poner disponible esa información, así que sé que tiene una tarea larga por delante, por muy automatizados que tengan los procesos internos.

Esto es algo que sucede en casi todos los frameworks de gestión de vulnerabilidades, consolidación de reportes, o integración de resultados, en los que se muestra el expediente de seguridad del fabricante para ampliar la información del bug.

Para evitar esto se está trabajando en estandarizar la forma en la que se publica y consume esta información en un formato de documento definido como Common Vulnerability Reporting Framework, en el que se intenta crear un tipo de documento en XML que sea capaz de ser producido y procesado de manera estándar.

Figura 1: Esquema del schema de CVRF 1.1

El formato del documento está siendo definido por ICASI (An Internet Consortium for Advancement of Security on the Internet), y en el whitepaper publicado, además de justificar la necesidad de un consenso para hacer más fácil gestionar esta información, expresan la necesidad de seguir trabajando en la integración y evolución de otros formatos estandarizados para comunicarse, como son:
Security Content Automation Protocol
- Common Platform Enumeration
- Common Weakness Enumeration
- Open Vulnerability and Assessment Language
Hoy en día, modelos como el CVSS para medir la criticidad de una vulnerabilidad son ampliamente utilizados - aunque algunos fabricantes adapten esas métricas y la expresen de otra forma -, pero todos estos esfuerzos en estandarización del advisory ayudarán a que haya un lenguaje completo y no solo una "manera de hacer las cosas", para que sea mucho más sencilla la tarea de consumir toda la información de seguridad que se produce.

Algunos fabricantes ya han anunciado que comenzarán a utilizarlo, como es el caso de Microsoft o de CISCO, que incluso ha publicado un manual en dos partes con un ejemplo de cómo transformar un advisory de CISCO a formato CVRF 1.1.
- The Missing Manual: CVRF 1.1 (Part 1 of 2)
- The Missing Manual: CVRF 1.1 (Part 2 of 2)
Espero que en el futuro, mi amigo Sergio de los Santos eche menos "ofús" los días que se hayan publicado muchos security advisories, y le quede más tiempo para otras cosas.

Saludos Malignos!

No hay comentarios:

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares