Español | English
rss facebook linkedin Twitter

Auditorias de seguridad teóricas

Imaginad la situación, partimos de un diseño de una red (en adelante modelo), pongamos como ejempo un diagrama en visio (vease también diag, o cualquier otra alternativa para los afines a lo GPL), lo metemos en una máquina que hace "bip", y obtenemos el listado de vulnerabilidades, debilidades y vectores de ataque asociados sin necesidad de realizar la auditoría real. Posteriormente, a partir de este resultado, es posible analizar la forma en que el número de vulnerabilidades y debilidades cambia cuando realizamos una manipulación del modelo (diagrama o información asociada), lo que permite al analista de seguridad comprobar si las medidas aplicadas o los cambios propuestos mejoran o empeoran la situación general, y a que componentes afectarían estos cambios. Sería ideal, es complicado, pero no es imposible.

Dentro del marco del proyecto INSPIRE en el que participamos de forma bastante activa, estamos desarrollando lo que para dicho proyecto se llama "security framework", que es la mezcla de varios repositorios de información, un sistema de categorízación y filtrado basado en un modelo ontológico específico y una herramienta de ayuda a la decisión. El objetivo del proyecto es, a partir de una modelización de una red SCADA evaluar las vulnerabilidades y mejoras aplicables.

Security Framework de INSPIRE

En entornos en los que la criticidad es una de las variables, se hace muy dificil introducir herramientas de auditoría orientadas al mundo IT. Las herramientas de auditoría son demasiado agresivas tanto para las plataformas como para los equipos que dan soporte (red, históricos, etc...). Se da la situación de que algunas de ellas podrían dejar los dispositivos analizados en estado poco estable para su funcionamiento, por lo que es necesario buscar alternativas que no repercutan de forma negativa en el rendimiento. Por todo ello, una alternativa teórica puede ofrecer cierta luz al respecto. Sobra decir que la cantidad de información y los criterios de relación necesarios para que un 'monstruo' de este tipo funcione son muchos, pero cuanta más información se incorpora al sistema, mejores serán los resultados obtenidos.

En una fase inicial, únicamente se han contemplado vulnerabilidades en sistemas operativos y aplicaciones a partir de un inventariado. Se relacionan las vulnerabilidades con los 'activos' analizados y ya es posible filtrar las existentes a partir de este "diagrama de red". La inclusión de debilidades inherentes a otras tecnologías, como criterios de autorización y autenticación (aplicables por ejemplo a elementos de red y protocolos) utilizados por los diferentes servicios permite obtener una visión más real del impacto asociado a las vulnerabilidades. Del mismo modo puede vincularse esta categorización con los vectores de ataque que pudieran afectar a la red. Por último, si se incluyen variables como factores de configuración de los servicios, usuarios y privlegios, es posible eliminar en gran medida la cantidad de falsos positivos en el resultado, y la aparición de nuevas debilidades ante cualquier cambio.

Todo esto se adereza con una relación de soluciones a las vulnerabilidades o debilidades descubiertas, pasos de explotación, referencias de exploits y herramientas que permiten abusar de esta vulnerabilidad, o cualquier otra información disponible que pueda ser relacionada en el repositorio y es lo que se llama: "la herramienta".

De la práctica a la teoría

Si bien es imposible obtener el mismo resultado que a través de una auditoría de seguridad real ya que son muchos los factores no controlables, si que es posible obtener una aproximación sorprendentemente acertada, tal y como tenemos la oportunidad de ver en nuestro laboratorio de SCADA. Posiblemente los resultados iniciales estén en cierta forma condicionados al hecho de que la tecnología necesaria para este proyecto ha sido realizada partiendo del laboratorio como fuente de información.

Para obtener resultados considerablemente reales es necesario realizar un inventariado lo más preciso posible con el que completar el modelo. El inventariado puede incluir opciones de configuración que permitan considerar la aparición de nuevas vulnerabilidades, o eliminar los falsos positivos existentes en el filtrado inicial. Este inventariado, así como la recogida de los factores de configuración también puede ser automatizado perfectamente.

Para los que consideren que este tipo de aproximación es demasido fantástica, podría recordarles que el MBSA de Microsoft comprueba la versión de una biblioteca del sistema operativo para saber si existe o no alguna vulnerabilidad, al igual que hace OVAL. La otra alternativa, mirar claves del registro de windows, es ampliamente utilizada por Nessus, entre otros, por poner un ejemplo. Muchos de los plugins y detectores de varias aplicaciones comerciales confían únicamente en el banner de los diferentes servicios para determinar la existencia de vulnerabilidades específicas.

Desde el punto de vista más práctico, para saber sin un servicio DNS dispone de transferencia de zona existen varias herramientas, ninguna lo hace comprobando directamente la configuración del servicio DNS (es decir, coger la configuración y mirar si esta opción está o no habilitada). Del mismo modo, es posible determinar si el usuario anónimo de un servicio FTP dispone de permisos de escritura realizando la prueba empírica o revisando la configuración del servicio. En cuanto al nivel de visibilidad, es posible realizar un barrido de pings o bien analizar la configuración de un firewall. La sesiones NULL de equipos windows pueden analizarse a partir del sistema operativo y las claves de registro correspondientes, o bien realizando el intento de conexión. Todos estos son ejemplos de auditoría de seguridad 'teórica', cuando el modelo dispone además del inventariado de información de configuración suficiente para realizar esta evaluación.

Existen varias maneras de obtener el mismo resultado, pero la particularidad de los entornos SCADA obliga a utilizar la menos agresiva.

Aplicaciones

Aunque el objetivo inicial de security framework del proyecto INSPIRE es el de realizar valoraciones de seguridad en entornos SCADA, es posible reorientarlo para entornos IT, en los que pueden incluirse un mayor número de repositorios de información. Cuando el sistema carece de información concreta aún es posible realizar una aproximación de tecnologías y criterios de seguridad a evaluar, que puede ser utilizado para orientar la auditoría y realizar una estimación inicial de esfuerzo. Si el sistema incluye toda la información adicional es posible incluso llegar a evaluar el impacto de las recomendaciones y sus implicaciones.

Nos vamos a Polonia a presentar una demo en Julio, os iremos contando más sobre su diseño, desarrollo y evolución, aunque de momento podemos decir que hace "bip"!.

Iñaki López
S21Sec labs

(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login