¿Por qué hacer una auditoría de seguridad informática?

Los más experimentados en el mundo de la gestión de sistemas informáticos no publican un nuevo servicio en Internet sin pasar previamente una auditoría de seguridad. Los más inexpertos siguen haciéndolo, como se puede apreciar en casos como la web del Senado de los 500.000 € o el famoso sitio web de la presidencia europea de España en el año 2010. Tras esa primera auditoría, la pregunta que hay que responder es ¿cuándo se debe hacer la siguiente auditoría?

Figura 1: XSS de Mr. Bean en la Web de la presidencia de EU 2010

Si eres lector de este blog ya sabes qué es lo que opino yo, pero dejadme que lo argumente de una manera más extensa para poder explicar cómo lo veo yo de forma más pausada.

¿Por qué hacer una auditoría de seguridad informática?

Tal vez parezca una perogrullada esta pregunta, pero seguro que la has escuchado alguna vez si has presentado un presupuesto al comité de la empresa. Tal vez incluso te pregunten si no vale con la auditoría que se hizo la última vez o la que se hizo cuando se puso en producción el servicio:

“¿No hicimos una auditoría y nos dijeron que estaba con una seguridad aceptable?”

Los motivos por los que se hace una auditoría informática suelen ser varios, pero se pueden reducir a dos: Para cumplir con los procedimientos o para evitar fallos de seguridad.

Al lector no experimentado puede parecer que el primero implica al segundo, pero no es así. El primero implica cumplir las normas, y no tener un objetivo que persiga la seguridad del proceso. Para ello se buscan auditorías que se contratan a precio de saldo, con cientos de direcciones IP por jornadas, automatizadas al máximo y aprovechando hasta el último día para cumplir con los procedimientos.

Estas auditorías se pueden hacer por cualquier normativa interna de la empresa, pero generalmente suele ser por cumplir con alguna auditoría externa, tipo ISO 27.001 o PCI-DSS, y los plazos que se aplican tienden a ser, habitualmente, de seis meses a un año, quedándose fuera de la auditoría todo aquello que no se considera “core” dentro de la certificación.

Cuando se suele contratar una de estas auditorías se busca un informe, lo más gordo y rápido posible, que se adjuntará a la documentación del servicio y que suele ser lo más automatizado posible, utilizando escaners de vulnerabilidades y herramientas certificadas para tal tarea. Un tramite automatizado.

Las segundas auditorías, las que se realizan para estar seguro, son de otra forma. Suelen estar impulsadas por los equipos de seguridad y buscan descubrir de verdad cuál es el estado real de la seguridad. Suelen ser incómodas para negocio, ya que si sale algo severo obliga a trabajar a toda la empresa. En ellas se buscan equipos serios, se hacen a veces con equipos en paralelo que buscan a la vez los fallos de seguridad y presentan resultados que permiten a los responsables buscar no solo las deficiencias, sino una garantía de que el resultado al final de la auditoría será bueno.

¿Cada cuánto tiempo se debe hacer una auditoría de seguridad?

Si lo que buscas es una auditoría del primer tipo, como ya he dicho, las normas suelen ser laxas y permiten periodos de un año. Tener un sistema expuesto a Internet durante un año sin realizar auditorías de seguridad – por mucho mantenimiento de sistemas y actualización de parches que se haga – es una temeridad.

Figura 2: Recomendaciones de frecuencia de auditorías según PCI-DSS

Hoy en día, los cambios del software base son constantes, y el entorno sobre el que correo una aplicación web en un instante de tiempo T1 no se parecerá al entorno de software en el que correrá en un instante de tiempo T1+1 año. Durante ese periodo el sistema operativo habrá actualizado cientos de parches, cambiado componentes internos y modificado pequeñas funciones en componentes que habrán sido modificados. Habrá cambiado el software que utiliza el cliente y el software de toda la electrónica de red que conecta desde el usuario final, hasta el almacén de datos.

No solo habrá cambiado el software base, sino que se habrán producido decenas o cientos de cambios pequeños en la web que sumados generarán un cambio sustancial en el código de la aplicación. Se habrán añadido nuevos interfaces de usuario para soportar los últimos gadgets, se habrá cambiado la plantilla de la web para adaptarse a los cambios de diseño y se habrán tocado pequeñas o grandes funcionalidades en la web, que sumados todos harán que el código de todo el sistema se parezca poco al que había en el T1 original.

Pero lo más importante es que durante todo ese periodo habrán sido publicadas tropecientas conferencias de seguridad ofensiva que mostrarán nuevas técnicas de hacking, nuevas herramientas o nuevo conocimiento sobre la tecnología existente, se habrán publicado miles de artículos en blogs, congresos académicos y revistas técnicas y habrán aparecido cientos de vulnerabilidades en el software publicadas en foros, listas de correo o bases de datos de expedientes de seguridad.

La suma de estos tres factores, es decir, el software base de la aplicación web sobre la que corre el servicio, los cambios en el código de la aplicación y el avance del conocimiento en técnicas de ataque, hacen que en un año el resultado de una auditoría web en T1 y en T1+1 año pueda resultar “inseguramente” distinto.

La ventana de tiempo importa

Este periodo de tiempo es lo que permite que cuando se hace una auditoría de seguridad, por regla general, siempre aparecen cosas de nivel crítico. Es común auditar un sistema y acabar encontrando cosas de alta criticidad. Si has hecho auditorías de seguridad ofensiva, estarás acostumbrado a que en el 90 % de los casos acabes entrando hasta la cocina usando las últimas herramientas que traiga para pentesting Kali, los últimos exploits de Metasploit o buscando fallos de SQL Injection en las últimas páginas web añadidas.

Esta ventana de tiempo es también uno de los elementos que permite que, como decía en la presentación, los ciberespías siempre ganen, ya que si el malo descubre un fallo antes que lo descubra el pentester o el auditor de seguridad, entonces ya habrá ganado.

Pentesting Continuo, Pentesting by Desing

Es por esto por lo que para que un sistema esté “razonablemente” seguro, decía yo que los auditores tienen que ser más rápidos encontrando los fallos de un sistema que los malos explotándolos. Para ello es necesario que cada vez que se cambia el software de base o se realiza un cambio en una aplicación un pentester pruebe todas las técnicas conocidas, además de que cada vez que se descubre un nuevo bug, una nueva técnica de hacking o un nuevo fallo de una tecnología, esta se revise sobre todo el sistema.

Con estas ideas es con lo que en Eleven Paths estamos trabajando en hacer de la FOCA una solución “FOCA as a Service”, para revisar la seguridad de una aplicación web constantemente, revisando todos los días todos los fallos conocidos sobre el sistema. Evolucionando el Pentesting Driven by FOCA a un Pentesting Done by FOCA añadiendo día a día nuevas pruebas de auditoría. Es decir, revisando una base de conocimiento K1 sobre un sistema en los instantes de tiempo T1, T2,T3, … Tn, pero al mismo tiempo que se realiza ese análisis constante en tiempo, la base de datos de conocimiento irá creciendo día a día, pasando a ser K2, K3, … Kn a lo largo del tiempo.

Figura 3: Arquitectura versión "alpha" de FOCA as a Service

Esto nos dejaría que un sistema informático deberá soportar el pentesting by desing, permitiendo que se revise el conocimiento de seguridad Kn en un instante de tiempo Tn. Es decir, la auditoría de seguridad de un sistema debe ser algo lineal y constante, que mantenga el nivel de intensidad a lo largo del tiempo.

¿Es sostenible esta revisión continua de la seguridad?

A día de hoy muchos sistemas no están preparados para esta intensidad de auditoría. Ya muchos administradores se ponen nerviosos con pensar sólo en que llega “la semana de la auditoría” o “la noche de la prueba de DDOS”, como para escuchar que se van a estar realizando estas pruebas de forma continuada. Lo sé. Pero es a donde creo que debemos llegar, a que realizar un proceso de auditoría de seguridad continuado sea algo habitual que se realiza antes de publicar el servicio en Internet.