SCAP (Security Content Automation Protocol): Introducción

Un XML ilegible para gobernarlos a todos. Un XML enorme para encontrarlos, un XML grotesco para atraerlos a todos y atarlos en las tinieblas.
Según la definición extraída del NIST (National Institute of Standards and Technology) fuerte fuente donde obtener lo que buscamos:
“The Security Content Automation Protocol (SCAP) is a synthesis of interoperable specifications derived from community ideas. Community participation is a great strength for SCAP, because the security automation community ensures the broadest possible range of use cases is reflected in SCAP functionality. This Web site is provided to support continued community involvement. From this site, you will find information about both existing SCAP specifications and emerging specifications relevant to NIST’s security automation agenda. You are invited to participate, whether monitoring community dialog or leading more substantive activities like specification authorship.”

Helado me hayo… ¿un poco de información más consistente vendría bien no? Acudimos a otra fuente bastante menos legítima que el propio NIST pero probablemente válida para ayudarnos a tener una perspectiva más clara, Wikipedia:
“Security Content Automation Protocol, también conocido por sus siglas SCAP o S’CAP, es conjunto de especificaciones del NIST para expresar (formatos y nomenclaturas) y manipular información relacionada con la seguridad sobre fallos y configuraciones, de una forma estandarizada. De esta forma se permite automatizar, en cierto grado, el chequeo (búsqueda) de vulnerabilidades, evaluar posibles impactos de vulnerabilidades, la gestión de vulnerabilidades, mediciones de seguridad, y evaluación de políticas a adoptar. En definitiva, provee una infraestructura poderosa para la elaboración de análisis e informes sobre vulnerabilidades en los sistemas de información.”
Por si no queda claro lo podríamos resumir, grosso modo, que es un fichero normalmente gigante en el arcaico y conocido lenguaje de etiquetado XML, el cual respeta una especificación ya establecida para que sea válido de leer en múltiples aplicaciones relativas al análisis y estado de la seguridad en el dispositivo, sistema, servicio , app, etc que se analiza, donde las aplicaciones que lanzan estas verificaciones también deben soportar la versión de la especificación de SCAP para entenderse (es lo que tienen los protocolos), actualmente en la 1.2.
Muchos os estaréis preguntado a que viene todo esto y es que tras trabajar durante todo este año desarrollando herramientas relativas a este protocolo, dónde muchos ya os estaréis hechando las manos la cabeza con el tema del XML, queridos humanos, quisiera compartir con vosotros mis percepciones del mismo.

Si observamos su origen (MITRE [The MITRE Corporation], NIST [Instituto Nacional de Estándares y Tecnología], etc) y en los entornos que se van a mover (Gubernamental, militar, empresa privada, etc), podemos encajar en nuestra cabeza la razón del uso de XML, ya que no son start-up precisamente donde predomina el último producto de moda o de valor a tener en cuenta y testear, no… en esos ámbitos esto no encajaría, pues demasiada burocracia ha existido ya para aprobar XML como para aprobar por ejemplo JSON o YAML, que en mi opinión son bastante más factibles de leer para un simple velocista.
SCAP viene a solucionar un problema común donde multiples herramientas como Nessus, Qualys, etc no tienen estandarizado los ficheros para la gestión del análisis de vulnerabilidades, un cumplimiento de forma ágil y heterogénea.

Podríamos decir que estos ficheros SCAP nos sirven básicamente para determinar sobre que plataforma y servicios que vamos a realizar test en un análisis de vulnerabilidades. Todo esto ya se puede hacer con herramientas, solo que el problema viene que cada una es de su padre y de su madre, no siendo pues reutilizables estos ficheros entre las mismas, por lo que es dificilmente escalable en entornos grandes o complejos por la granularidad de los componentes existentes.
Un ejemplo práctico sería que quisiéramos analizar una plataforma de tipo "GNU/Linux" orientada a servicios frontales HTTPS. Dispondríamos de un fichero SCAP con diversas secciones donde básicamente se determinarían una serie de reglas a comprobar y que la herramienta, conociendo el protocolo de SCAP, sepa como lanzar estas comprobaciones.
Si tuviera que dar una opinión honesta de este protocolo, podría decir que si bien el intento es bueno, ni las tecnologías seleccionadas son las ideales ni las herramientas parecen evolucionar de forma rápida hacia este protocolo pese lo que se venda en el papel, donde un ejemplo lo tendríamos en Nessus, el mismo tiene soporte para la versión 1.2 pero ni siquiera soporta la capacidad de leer operaciones con WMI para plataformas Windows.
Como conclusión creo que SCAP podría tener sentido en determinados sectores muy concretos, como podría ser el militar, básicamente porque ya se ha determinado que hay que usarlo… aunque si lo trasladamos a empresas del mercado español, claramente la tendencia está en seleccionar una única solución de análisis de vulnerabilidades para ahorrar costes y energía (al menos que sea requisito de tener múltiples herramientas que básicamente lo que no vea una lo vea la otra) y probablemente se realizarían integraciones automatizadas con herramientas propias de integración de tests y automatización fuera del uso del protocolo SCAP.
