UNIVERSIDAD POLITECNICA DE CATALUÑA SIGVI Sistema Inteligente de Gestión de Vulnerabilidades Informáticas Sebastián Gómez, Óscar Güell - UPCnet UNIVERSIDAD POLITECNICA DE CATALUÑA

Índice de la presentación Introducción a las vulnerabilidades Panorama actual: problema de la gestión de vulnerabilidades Propuesta de solución: SIGVI Futuro del SIGVI Referencias Ruegos y preguntas

Introducción a las vulnerabilidades Visión histórica Asaltantes antiguos buscaban vulnerabilidades en cajas fuertes, la seguridad de un banco, etc. En la Sociedad de la Información los salteadores no necesitan dinamita ni pistolas para conseguir asaltar un objetivo. Bastará un equipo conectado a Internet y encontrar un fallo de seguridad, normalmente provocado por una vulnerabilidad en alguno de los componentes del sistema Todos hemos visto una película de baqueros, donde un ladrón usa dinamita para “volar” la puerta de una caja fuerte También películas más actuales de atracos planificados y llevados a cabo con gran perfección Todas tienen en común que los asaltantes buscan vulnerabilidades en los sistemas para conseguir acceder a ellos y obtener objetos de valor. En el caso del baquero, aplicando dinamita conseguía abrir la caja, en el caso del ladrón de guante blanco, cualquier fallo de seguridad le permitía acceder en los sistemas supuestamente seguros. En la Sociedad de la Información, los asaltantes ya no necesitan dinamita, ni pistolas, en la mayoría de los casos ni un simple esquema de un sistema. Por desgracia muchas veces únicamente con un ordenador conectado a Internet y conocimientos básicos de cómo “asaltar” un servidor aprovechando una vulnerabilidad.

Introducción a las vulnerabilidades Tipos de asaltantes, vulnerabilidades y consecuencias Inducidos por diferentes motivos: fama dentro de la Comunidad (hackers) o beneficio económico (crackers) Aprovechan fallos en la programación o configuración de un servicio, o fallos en el entorno del sistema Para conseguir acceso privilegiado a un sistema, o denegación del servicio, o bien comprometer datos Tipos de hackers Hay foros de hackers donde se publican exploids de vulnerabilidades que cualquier persona sin apenas conocimientos puede lanzar contra un objetivo. En muchas de las ocasiones ni si quiera saben las consecuencias de estas acciones. Muchos hackers únicamente pretenden hacerse con el control de un sistema para conseguir fama, únicamente dejar su huella para que el resto de la comunidad hacker. Raramente En otros casos son ataques planeados y perfectamente dirigidos con fines maliciosos, como hacerse con documentación Tipos de vulnerabilidades Normalmente las vulnerabilidades vienen provocadas por fallos de programación del servicio, pero muchas veces son simples errores de configuración de ese servicio o bien un fallo en el entorno del sistema. Consecuencias de las vulnerabilidades Las consecuencias pueden llegar desde que el atacante consiga más privilegios dentro del sistema, como detener el servicio, como llegar a tomar posesión de documentación (compromiso del sistema – algunos casos de espionaje industrial).

Panorama actual Realidad del problema de las vulnerabilidades Incremento diario del número de infraestructuras y de servicios Estos servicios han de estar protegidos Y hay que estar al tanto de la aparición de nuevas vulnerabilidades Impulsadas sobre todo por el gran número de potenciales clientes, Las empresas y las administraciones aumentan cada día las inversiones en infraestructuras para crear nuevos servicios o mejorar los existentes Para protegerlos de intrusiones usamos toda serie de protecciones activas y pasivas (firewalls, IDS, IPS, …) La seguridad total no existe en absoluto, Y muestra de ello son el número creciente de publicaciones de alertas de vulnerabilidades

Panorama actual Evolución constante del número de alertas El Incremento anual de avisos de vulnerabilidades es notablemente visible Gestionar todos estos avisos cada vez requiere más recursos Fuente National Vulnerability Database En los últimos 10 años, el NVD ha publicado casi 20.000 vulnerabilidades Casi la mitad de ellos han aparecido entre el año pasado y lo que llevamos de éste. 14 vulnerabilidades diarias por el número de servidores y servicios requiere un tiempo razonable No solo identificar los servicios o servidores afectados sino también determinar su alcance y la gravedad Está claro que cuanto antes se sepa antes podrá ponerse remedio y con ello disminuir el riesgo de ataques

Panorama actual Escenario habitual de gestión de vulnerabilidades 1 3 NVD, hispasec, oxigen, Altair, … 2 Linux, Windows, Solaris, AIX, ..., SSH, Apache, MySQL, CheckPoint ... (35000) Administradores 4 5

Propuesta de solución: SIGVI Objetivos Crear una herramienta FREE que diera solución a la necesidad Automatizar las tareas de recolección, comparación y aviso Proporcionar a los administradores un entorno colaborativo de seguimiento de las alertas y repositorio de vulnerabilidades Proporcionar a los responsables un entorno de consulta del estado de las infraestructuras y herramientas de reporting En el momento en que se estudió este proyecto no se conocía ninguna herramienta de libre distribución que resolviera la necesidad. Si que existían productos de pago, pero con precios quizás un poco elevados.

Propuesta de solución: SIGVI Planteamiento básico NVD, hispasec, oxigen, Altair, … 1 3 Repositorio Servicios / Servidores 2 4 5

Propuesta de solución: SIGVI Características Permite definir múltiples fuentes de vulnerabilidades Organización por grupos Realiza un cálculo del impacto para cada caso específico Envía automáticamente notificaciones a los administradores Proporciona un repositorio de: Vulnerabilidades (autoalimentado), Servidores y productos, Alertas (histórico) y seguimiento de las alertas El administrador del SIGVI podrá definir diferentes fuentes de vulnerabilidades. Los usuarios están organizados por grupos, de manera que podemos tener grupos totalmente independientes en una misma instancia. Para cada caso de producto vulnerable detectado en un servidor, se calcula el impacto, en función de las características propias de la vulnerabilidad (gravedad, accesos requeridos, consecuencias) y las características propias del servicio (si está filtrado por un firewall, si es un servicio crítico). Para cada positivo se envía un mail a los administradores de ese equipo detallando del servicio afectado y un resumen de la vulnerabilidad. A su vez se crea una entrada en el repositorio de alertas para que los administradores puedan realizar el seguimiento. El entorno ofrece un repositorio de: Vulnerabilidades, que se autoalimenta de las fuentes de vulnerabilidades Servidores y productos, que los gestionan los usuarios Alertas creadas por el propio SIGVI. Permite realizar seguimiento histórico y gestión de alertas abiertas.

Propuesta de solución: SIGVI Capturas de pantalla I Vista del administrador - El administrador de equipos únicamente verá la información relativa a los equipos de su grupo

Propuesta de solución: SIGVI Capturas de pantalla II Vista del administrador - El administrador de equipos únicamente verá la información relativa a los equipos de su grupo

Propuesta de solución: SIGVI Arquitectura Implementado en plataforma LAMP (Linux, Apache, MySQL, PHP) Diseño orientado a objetos Características básicas: Modular Múltiples lenguajes Múltiples motores de bases de datos

Propuesta de solución: SIGVI Estado actual de la aplicación Existe una versión 1.0 - 100% funcional, además… Están en estudio mejoras para grandes entornos como puede ser el CPD de una universidad Volumen orientativo de datos: 19.742 vulnerabilidades importadas de NVD (desde 1988) Lista de 40.300 productos recopilados Desde diciembre de 2005 ya existe en SourceForge una versión estable del producto, pero tiene limitaciones para grandes implantaciones. Estas limitaciones se basan en que la carga de datos inicial (servidores y servicios asociados) es manual. En pequeñas implantaciones donde pueden haber no más de 30 servidores, se puede asumir, pero en implantaciones con más de 200 servidores como es nuestro caso puede representar muchas horas de trabajo. Por otro lado, normalmente las organizaciones con grandes CPDs ya cuentan con repositorios propios de servidores y de servicios, por lo que tendríamos redundancia de los datos, y la gestión de éstos sería más compleja (duplicados). Estamos estudiando permitir la integración con grandes entornos, ya sean con bases de datos que contengan los repositorios o bien con herramientas tipo OCS Inventory. Para hacerse una idea del volumen de datos almacenado, se han recopilado casi 20.000 vulnerabilidades del NVD, desde la primera que publicaron en 1988, y una lista de más de 40.000 productos vulnerables.

Propuesta de solución: SIGVI Impacto en un CPD En un CPD de más de 200 servidores. Liberación de 3h/día de técnico de seguridad. Incremento de la seguridad: conocimiento real del estado de los servidores en todo momento. Proporciona una base común de trabajo y seguimiento de alertas. Desde diciembre de 2005 ya existe en SourceForge una versión estable del producto, pero tiene limitaciones para grandes implantaciones. Estas limitaciones se basan en que la carga de datos inicial (servidores y servicios asociados) es manual. En pequeñas implantaciones donde pueden haber no más de 30 servidores, se puede asumir, pero en implantaciones con más de 200 servidores como es nuestro caso puede representar muchas horas de trabajo. Por otro lado, normalmente las organizaciones con grandes CPDs ya cuentan con repositorios propios de servidores y de servicios, por lo que tendríamos redundancia de los datos, y la gestión de éstos sería más compleja (duplicados). Estamos estudiando permitir la integración con grandes entornos, ya sean con bases de datos que contengan los repositorios o bien con herramientas tipo OCS Inventory. Para hacerse una idea del volumen de datos almacenado, se han recopilado casi 20.000 vulnerabilidades del NVD, desde la primera que publicaron en 1988, y una lista de más de 40.000 productos vulnerables.

Propuesta de solución: SIGVI Previsiones de ampliaciones y mejoras Flexibilizar las parametrizaciones de la aplicación. Posibilidad de integración con repositorios existentes en cada instalación concreta. Integración con productos como OCS Inventory. Se está trabajando en la flexibilización de la parametrización de la aplicación de manera que el administrador de cada grupo pueda definir los parámetros de la aplicación, por ejemplo: Qué tipo de vulnerabilidades quiere descartar, para qué servidores se alertará en función de las características, cómo se calcula el factor de impacto, etc. Y como ya hemos comentado antes, facilitar la integración con repositorios existentes Y permitir integración con sistemas como OCS Inventory. -

Referencias · Demo online: http://sigvi.upcnet.es · Proyecto en sourceforge: http://sigvi.sourceforge.net · National Vulnerability Database: http://nvd.nist.gov/ · OCS Inventory: http://ocsinventory.sourceforge.net/ · UPCnet: http://www.upcnet.es · e-mail contacto: sebastian.gomez@upcnet.es

Gracias por vuestra atención