Los recientes ataques a la red significan que la automatización de la seguridad y el monitoreo continuo son fundamentales. Un conocimiento actualizado acerca del estado de la red y los puntos extremos que la comprenden son más importantes que nunca. La información de postura de la red permite a quienes defienden la red contar con la información que necesitan para proteger adecuadamente los datos críticos, corregir las vulnerabilidades antes de que sean explotadas y desviar los ataques de los actores maliciosos. Esta misma información de postura de la red sustenta la resiliencia de la red, permitiendo que los operadores luchen y se recuperen de los ataques a la red cuando no es posible desviarlos. Automatizar los procesos para recolectar esta información, aprovecharla contra los ataques a la red y soportar una operación resiliente permite ahorrar tiempo y recursos y, por ende, ofrece beneficios de seguridad a la red y beneficios económicos a sus dueños.
Entonces, ¿por qué la automatización de la seguridad no es algo generalizado? Porque una correcta automatización de la seguridad requiere la interoperabilidad de un variado conjunto de productos. cada herramienta o proceso analítico en la red debe trabajar en conjunto —desde los orquestadores que dirigen las acciones de seguridad de la red, hasta los recolectores que los alimentan con datos; desde las herramientas de gestión de eventos e infor- mación de seguridad (SIEm) que detectan ataques, hasta los rewalls que ejecutan comandos para bloquear actividades maliciosas; desde los routers y switches que forman el backbone de la red, hasta los dispositivos de borde que los protegen. cada punto extremo necesita ser parte de una solución completamente automatizada. El alcance de la solución deseada es enorme: automatizar las funciones de seguridad de la red en la mayor medida posible. En las soluciones de automatización de seguridad disponibles, los puntos extremos, herramientas y elementos de análisis no interoperan lo su ciente como para realmente automatizar las funciones de seguridad de la red.
Solo a través de los estándares se podrán lograr soluciones interoperables para este espacio. El Grupo de Trabajo del IETF sobre Automatización y monitoreo continuo de la seguridad (sAcm) ha estado trabajando para definir correctamente el alcance del problema de la automatización de la seguridad. Esto incluye identificar qué información de postura es esencial para la seguridad de la red y estandarizar cómo recoger y compartir esta información con herramientas de evaluación y análisis que puedan mejorar su capacidad para detectar y responder a los ataques. Para que el alcance de la estandarización de la automatización de la seguridad sea más manejable, es necesario dividirla en un conjunto de tareas de seguridad funcionales automatizadas con un orden de prioridad definido.
El sAcm ha elegido la evaluación de vulnerabilidades como la primera tarea de seguridad a automatizar. El escenario de evaluación de vulnerabilidades del sAcm1 describe cómo una empresa puede evaluar su susceptibilidad frente a una vulnera- bilidad anunciada. Existen muchas razones por las que la evaluación de vulnerabi- lidades es una buena primera opción para un caso de uso de automatización de la seguridad.
• Esta es una tarea de seguridad fun- damental, y el aumento de las “vulne- rabilidades con nombre”, por ejemplo, heartbleed y shellshock, es un indicador de ello.
- Es una tarea difícil de realizar sin un gran gasto de recursos.
- los efectos de una evaluación de vulnerabilidades de ciente
resonarán con el paso del tiempo. Por ejemplo, años después del anuncio de heartbleed, continúan habiendo implementaciones de ssl sin parchar que amenazan la seguridad de la red. - la evaluación de vulnerabilidades representa un desafío para las redes empresariales, pero se podría auto- matizar fácilmente si se brindaran los datos correctos a los evaluadores.Investigar la evaluación de vulnerabilidades como el primer caso de uso de la automatización tiene el bene cio agregado de que nos obliga a abordar el problema fundamental de saber qué hay en nuestra red. Es imposible evaluar las vulnerabilidades de una red sin conocer la compo- sición de la red. En particular, el evaluador necesita saber cuáles son los puntos extremos de la red y el software que se está utilizando —conocimiento apoyado en buenas prácticas de gestión de activos de software y hardware—. la gestión de activos de software y hardware sustenta la evaluación de vulnerabilidades, así como la gestión de con guraciones, la detección de amenazas, el análisis de malware y otra serie de funciones de seguridad de red susceptibles de ser automatizadas.
Aunque es evidente que los operadores de red deben monitorear continuamente los activos de software y hardware que se encuentran en la red, es muy importante comprender la arquitectura de este monitoreo. Para que esta información llegue a los evaluadores que la precisan, se debe recolectar en un formato estructurado y conocido. Para la seguridad de los puntos extremos que monitorean los operadores de red, la solución requiere protocolos autenticados y cifrados. cuando cambia la información monitoreada, los datos se deben proveer lo antes posible para eliminar los escaneos periódicos de la red que podrían ser utilizados para un ataque. Por razones de escalabilidad, la solución debe ser exible y liviana. a su vez, para soportar futuros casos de uso de automatización de la seguridad, la solución debe ser extensible.
El IETF ha estandarizado la arquitectura de evaluación de puntos extremos de la red (NEA), por lo que ya existe una solución que cumple con estos requisitos para los dispositivos cliente. usando el protocolo PT-TLP, cualquier punto extremo conectado a la red puede comunicar información de postura a un servidor de cumplimiento, incluida la identidad del punto extremo. construyendo sobre lo realizado por el Grupo de Trabajo sobre computación confiable (Trusted Computing), el sAcm le ha agregado a estos protocolos y ha especificado cómo comunicar los datos de especificación del software sobre NEA en el proyecto de especificación (draft) sobre mensaje y atributos de inventario de software para PA-TNC.
SWIma es una instancia de un colector NEA que puede monitorear inventario de software de puntos extremos y enviar informes a un servidor de cumplimiento. Utilizar SWIma en lugar de PT-TLS permite recolectar la identidad de los puntos extremos y el inventario de software antes de que se anuncie una vulnerabilidad. utiliza etiquetas de identidad de software (SWIdCo), un estándar Iso/IEc, como un modelo de datos que permite a los fabricantes y dueños de software desarrollar representaciones Xml únicas de la identidad de un software. El servidor de cumplimiento puede almacenar esta información en un repositorio de datos para futura referencia (Figura 1).
Algunos tipos de puntos extremos no podrán soportar el software cliente que requiere nEa. Otros, en particular los dispositivos de red, ya soportan protocolos específicamente diseñados para generar informes de postura. Es imposible tener una buena higiene en la red sin informes de postura de los dispositivos de red. En el IETF hay una lista de correo —Evaluación de la postura a través de la recolección de información de la red (PAnIc)— que está explorando soluciones para recolectar la postura de los dispositivos de red, en particular, modelos YanG que podrían ofrecer información adecuada a los dispositivos de defensa de la red acerca de la postura de sus dispositivos de red. Estos modelos, que se comunican sobre NETCONF y aprovechan el draft que especifica el YanG push, pueden ayudar a mantener un panorama actualizado del estado de la red (Figura 2).
Ahora que hay una colección robusta de información de inventario de software de los puntos extremos en el repositorio de datos, las herramientas de seguridad empresarial que tengan autorización apropiada podrán acceder a esta información y utilizarla.
Mientras que el escenario de evaluación de las vulnerabilidades se enfoca en utilizar la información de inventario de software para un caso de uso específico, es fácil ver que esta información puede llegar a ser valiosa para muchas otras herramientas de seguridad de red: herramientas de gestión de activos, análisis de comportamiento, e incluso las herramientas de detección de amenazas pueden mejorar sus salidas con acceso a información de inventario de software precisa y actualizada. cada uno de estos evaluadores consultará el repositorio de datos para obtener los datos que necesite. Para ampliar nuestro ejemplo de evaluación de vulnerabilidades, un evaluador consultará el repositorio de datos para determinar los puntos extremos que tienen instalado el software vulnerable, aprovechando así la información de gestión de activos de software recogida de los puntos extremos de la red. Otros evaluadores también pueden aprovechar estos datos, con lo cual se crea una conciencia situa- cional compartida de la postura de la red (Figura 3).
Además de comprender la postura de la red, las empresas precisan una conciencia situacional compartida de las amenazas actuales a la red. La conciencia de la situación puede tener diferentes formas en función del caso de uso abordado. En el caso de la evaluación de vulnerabilidades, la herramienta debe conocer qué vulnerabilidades está buscando. El proyecto del sAcm titulado Evaluación de las vulnerabilidades de ne un repositorio de datos de vulnerabilidades que puede proveer información sobre debilidades que podrían comprometer la seguridad de la red. Se trata de un repositorio de contenido al que deben acceder los evaluadores para ayudar a definir los criterios que utilizan para realizar su evaluación. Este repositorio se podría implementar utilizando el proyecto de especicación (draft) sobre intercambio de información orientado a recursos (rolIE) producido por el Grupo de Trabajo mIlE (Intercambio liviano de incidentes gestionado). RolIE construye sobre el protocolo de publicación ATom8 para compartir software, vulnerabilidades, inteligencia sobre amenazas en la red, listas de verificación de la configuración y otra información de la automatización de la seguridad de forma escalable. Los fabricantes, investigadores del área de la seguridad y personal encargado de gestionar las redes pueden crear repositorios roLIE para asegurar que sus evaluadores tengan la información de seguridad más actualizada posible (Figura 4).
El Grupo de Trabajo sAcm demostrará cómo los estándares SWIma, nEa y roLIE pueden satisfacer los requisitos del Escenario de evaluación de vulne- rabilidades durante el hackathon previo al IETF 99. Invitamos a las partes interesadas a sumarse a la lista de correo del sAcm9. Quienes estén interesados en la automatización de la seguridad para los equipos de red pueden suscribirse a la lista PAnIc10; quienes tengan interés en el trabajo sobre repositorios de contenido pueden suscribirse a la lista mIlE11.
Notas al pie
1. https://trac.ietf.org/trac/sacm/wiki/ sacmvulnerabilityAssessmentscenario.
2. https://tools.ietf.org/html/rfc5209.
3. https://datatracker.ietf.org/doc/rfc6876/.
4. https://datatracker.ietf.org/doc/draft-ietf- sacm-nea-swid-patnc/.
5. https://datatracker.ietf.org/doc/draft- waltermire-panic-scope/.
6. https://datatracker.ietf.org/doc/draft-ietf- netconf-yang-push/.
7. https://datatracker.ietf.org/doc/draft-ietf- mile-rolie/.
8. https://tools.ietf.org/html/rfc5023.
9. https://www.ietf.org/mailman/listinfo/sacm.
10. https://www.ietf.org/mailman/listinfo/panic.
11. https://www.ietf.org/mailman/listinfo/mile.