Test de vulnerabilidades As a CONTINOUS Services. Nessus Home.
Este concepto no me lo he inventado yo ni mucho menos, pero es algo sobre lo que llevo pensando desde hace tiempo. He visto varios artículos dándole vueltas al asunto, por lo que imagino que ya será una realidad en muchas organizaciones.
Como todos sabemos en el mundo de la seguridad, el ciclo de vida de los incidentes es muy corto. Pueden pasar horas, minutos, desde que un tipo en Kazajastan crea un exploit para un zero Day en un producto popular, y lo tenemos en la puerta de nuestra empresa probando infectar o atacar la vulnerabilidad. Los días que pasan desde que se publica la vulnerabilidad, hasta que el fabricante desarrolla la corrección pueden marcar la diferencia en el éxito o no de los ataques.
Desde el punto de vista clásico de un director TI, el contar con un informe de una empresa que le realiza un test de vulnerabilidades dos veces al año, sería una buena gestión. Pero entonces, confiamos en que nuestros sistemas están correctamente parcheados/configurados durante los 6 meses de diferencia entre auditoría y auditoría?.
En el mundo de la calle, en el que los empleados apuntan claves en Post-it, en los que aún hay empresas que no se adaptan a una simple LOPD por no tener ni una infraestructura de directorio, en ese mundo no hay auditorías de seguridad.
Como siempre reivindico en Inseguros, existe el término medio. No todos podemos administrar sistemas/seguridad en MegaCorp. S.L. con recursos para hardware/software. Ni tampoco tenemos que ser participes con nuestra falta de profesionalidad de administrar una empresa con la clave "1234".
Vamos a intentar proporcionar a nuestra organización, o por qué no, red de ordenadores domésticos ( por eso de las licencias) de una aproximación a lo que entiendo como un servicio continuo de Test de Vulnerabilidades.
La idea es muy sencilla. Definimos una plantilla con la configuración de una auditoría para nuestros sistemas. Programamos la realización de este test en un horario que no deteriore mucho el rendimiento de los sistemas.
Monitorizamos el resultado de los informes y monitorizamos los informes de resultados obtenidos entre auditorías realizadas entre fechas.
La palabra continuo aquí tiene sentido cuando hablamos del problema de tener informes de resultados cada 6 meses, pero no tiene sentido si lo comparamos por ejemplo con la continuidad que ofrece lo que hace un IDP en tiempo real. Programar una auditoría "ligera" diariamente y otra un poco más completa mensualmente lo considero aceptable para una PYME que le preocupe la seguridad, pero que no tiene los medios para adquirir un producto específico.
Para realizar este laboratorio necesitamos tener instalado Nessus 5.2 o superior, que en la versión Home posibilita la programación de test y la notificación por correo. Si queréis revisar los artículos sobre Nessus en Inseguros podéis pinchar aquí, aquí y aquí.
Lo primero que vamos a hacer es en Configuration, introducir los datos de nuestro servidor SMTP que realizará el envío.
Para crear una plantilla de Test nos vamos a Scan Templates y creamos una nueva del tipo programada. Introducimos la política de Test que queremos realizar. Debemos configurar una seria de Plugins acorde con el sistema que vamos a auditar, y tenemos que tener en cuenta la perdida de rendimiento en el equipo a auditar. Yo para esta demo ya tengo mi Policie llamada "kino" :-) .
Configuramos la periodicidad del Test.
Introducimos la lista de equipos que queremos auditar y configuramos una cuenta de correo de destino. En los filtros podemos indicar que resultados mostrar en el informe que enviaremos al correo. Considero oportuno filtrar algún tipo de información, por ejemplo, si estás de vacaciones y te llega el Report del Test no creo que te sea de utilidad saber que ha detectado " Windows Devices" o que hay un puerto 80 activo. En este informe no vamos a ver las diferencias entre el último Test, pero a mi me gusta ver estos informes en el correo en mi tiempo libre, por si detecto alguna anomalía. Para esta prueba he configurado que envíe los resultados en caso de encontrar algún resultado denominado Critical y por filtrar algún detalle más, que me muestre los que tienen algún tipo de exploit disponible.
Con esto lanzamos la programación para nuestro Test diario a las 21:30.
Este es un ejemplo de un Report enviado al correo.
Una vez tenemos generados suficientes informes como para poder comparar, solo tenemos que seleccionar los informes en el panel de resultados y pinchar en Options. Diff Result.
El informe de resultados que nos presenta no se almacena, es labor del responsable el realizar la comparación y detectar variaciones no deseadas en los resultados.
Como podéis ver, podemos tener un sistemas más o menos continuo para realizar test de vulnerabilidades programados, dentro de las posibilidades de una herramienta como Nessus.
Profesionalmente hay sistemas que se encargan de esto, del fabricante de Nessus, pero para controlar un poco más este aspecto, nos puede servir este procedimiento.
Como siempre, espero que os guste el artículo, y gracias por leerme !!!.
Google +
Como todos sabemos en el mundo de la seguridad, el ciclo de vida de los incidentes es muy corto. Pueden pasar horas, minutos, desde que un tipo en Kazajastan crea un exploit para un zero Day en un producto popular, y lo tenemos en la puerta de nuestra empresa probando infectar o atacar la vulnerabilidad. Los días que pasan desde que se publica la vulnerabilidad, hasta que el fabricante desarrolla la corrección pueden marcar la diferencia en el éxito o no de los ataques.
Desde el punto de vista clásico de un director TI, el contar con un informe de una empresa que le realiza un test de vulnerabilidades dos veces al año, sería una buena gestión. Pero entonces, confiamos en que nuestros sistemas están correctamente parcheados/configurados durante los 6 meses de diferencia entre auditoría y auditoría?.
En el mundo de la calle, en el que los empleados apuntan claves en Post-it, en los que aún hay empresas que no se adaptan a una simple LOPD por no tener ni una infraestructura de directorio, en ese mundo no hay auditorías de seguridad.
Como siempre reivindico en Inseguros, existe el término medio. No todos podemos administrar sistemas/seguridad en MegaCorp. S.L. con recursos para hardware/software. Ni tampoco tenemos que ser participes con nuestra falta de profesionalidad de administrar una empresa con la clave "1234".
Vamos a intentar proporcionar a nuestra organización, o por qué no, red de ordenadores domésticos ( por eso de las licencias) de una aproximación a lo que entiendo como un servicio continuo de Test de Vulnerabilidades.
La idea es muy sencilla. Definimos una plantilla con la configuración de una auditoría para nuestros sistemas. Programamos la realización de este test en un horario que no deteriore mucho el rendimiento de los sistemas.
Monitorizamos el resultado de los informes y monitorizamos los informes de resultados obtenidos entre auditorías realizadas entre fechas.
La palabra continuo aquí tiene sentido cuando hablamos del problema de tener informes de resultados cada 6 meses, pero no tiene sentido si lo comparamos por ejemplo con la continuidad que ofrece lo que hace un IDP en tiempo real. Programar una auditoría "ligera" diariamente y otra un poco más completa mensualmente lo considero aceptable para una PYME que le preocupe la seguridad, pero que no tiene los medios para adquirir un producto específico.
Para realizar este laboratorio necesitamos tener instalado Nessus 5.2 o superior, que en la versión Home posibilita la programación de test y la notificación por correo. Si queréis revisar los artículos sobre Nessus en Inseguros podéis pinchar aquí, aquí y aquí.
Lo primero que vamos a hacer es en Configuration, introducir los datos de nuestro servidor SMTP que realizará el envío.
Para crear una plantilla de Test nos vamos a Scan Templates y creamos una nueva del tipo programada. Introducimos la política de Test que queremos realizar. Debemos configurar una seria de Plugins acorde con el sistema que vamos a auditar, y tenemos que tener en cuenta la perdida de rendimiento en el equipo a auditar. Yo para esta demo ya tengo mi Policie llamada "kino" :-) .
Configuramos la periodicidad del Test.
Introducimos la lista de equipos que queremos auditar y configuramos una cuenta de correo de destino. En los filtros podemos indicar que resultados mostrar en el informe que enviaremos al correo. Considero oportuno filtrar algún tipo de información, por ejemplo, si estás de vacaciones y te llega el Report del Test no creo que te sea de utilidad saber que ha detectado " Windows Devices" o que hay un puerto 80 activo. En este informe no vamos a ver las diferencias entre el último Test, pero a mi me gusta ver estos informes en el correo en mi tiempo libre, por si detecto alguna anomalía. Para esta prueba he configurado que envíe los resultados en caso de encontrar algún resultado denominado Critical y por filtrar algún detalle más, que me muestre los que tienen algún tipo de exploit disponible.
Con esto lanzamos la programación para nuestro Test diario a las 21:30.
Este es un ejemplo de un Report enviado al correo.
Una vez tenemos generados suficientes informes como para poder comparar, solo tenemos que seleccionar los informes en el panel de resultados y pinchar en Options. Diff Result.
El informe de resultados que nos presenta no se almacena, es labor del responsable el realizar la comparación y detectar variaciones no deseadas en los resultados.
Como podéis ver, podemos tener un sistemas más o menos continuo para realizar test de vulnerabilidades programados, dentro de las posibilidades de una herramienta como Nessus.
Profesionalmente hay sistemas que se encargan de esto, del fabricante de Nessus, pero para controlar un poco más este aspecto, nos puede servir este procedimiento.
Como siempre, espero que os guste el artículo, y gracias por leerme !!!.
Google +
