Todo aquel profesional de la seguridad informática que haya dedicado más de una mañana al análisis y estudio de la seguridad web conocerá a Ivan Ristic. En 2002, siendo un desarrollador de software fue capaz de ver los grandes problemas de seguridad que implicaría la debilidad en la programación de aplicaciones web y el gran abanico de ataques, a nivel de aplicación, que se abriría. Después de buscar sin éxito en la amplia comunidad Open Source por proyectos existentes para detectar y bloquear ataques de aplicación en peticiones web, finalmente decide desarrollar su propia solución: ModSecurity, el WAF Open Source por excelencia.
He de decir con gran satisfacción que he tenido la oportunidad de entrevistar a Ivan Ristic, al cuál abordé a través de Twitter, y asombrado me he quedado de lo accesible, humilde y agradable que ha sido el contacto y el intercambio de correos con preguntas para una persona tan ocupada. Espero que os resulte tan interesante como me pareció a mí.
Hola Ivan, primero que nada, muchas gracias por tu disponibilidad la entrevista para nuestro blog. Como el visionario que fuiste, crear una solución desde cero para proteger aplicaciones web, ¿qué piensas sobre el escenario de seguridad actual? ¿Qué solución de seguridad que no exista ahora mismo serías capaz de predecir que, de aquí a 10 años más, no habrá una empresa sin ella?
Eres generoso con tus elogios, pero no era un visionario. Ni siquiera estaba en el campo de la seguridad en aquel momento, y nunca supe incluso que lo que estaba construyendo era un Cortafuegos de Aplicaciones Web. La verdad es mucho más simple,era consciente de que había muchos problemas de seguridad en las aplicaciones web y tenía que lidiar con ellos en mi equipo de desarrollo. ModSecurity aparece debido a nuestra necesidad de ganar visibilidad dentro del tráfico web. Sin saber qué sucede en nuestro patio de atrás, no puedes entender suficientemente bien la situación para enfrentarte a ella.
En cuanto a la situación actual del mundo de la seguridad, creo que estamos en el camino incorrecto. En vez de buscar los síntomas, que es lo que hacemos actualmente, deberíamos buscar los orígenes de los problemas de seguridad.
Lo que tenemos que hacer es comenzar a construir sistemas informáticos libres de componentes que no sean seguros por defecto. Eso, sin embargo, es fácil de decir, pero el camino que tenemos que seguir no está tan claro. Trato de hablar sobre ello en mi presentación “Dejad de quejaros y arreglad el problema de seguridad“.
Empezaste con ModSecurity, lo vendiste a Breach y ahora trabajas para Qualys. ¿Por qué te decidiste a comenzar el desarrollo de un nuevo WAF desde cero (Ironbee), en vez de hacer un fork de ModSecurity y añadirle las nuevas funcionalidades que quieras?
Mi motivación principal es muy sencilla: Aunque estoy muy contento con el éxito de ModSecurity, hay mucho más por hacer en el sector del Cortafuegos de Aplicaciones Web y quiero hacer ese trabajo que ayudará a alcanzar una adopción más amplia de esta tecnología.
Hacer un Fork de ModSecurity no nos llevaría tan lejos como nosotros queremos ir. Por un lado, ModSecurity está basado en GPL2, y queríamos que IronBee fuera tan abierto como fuera posible, así que elegimos la licencia Apache “non viral”. Creemos que la elección del tipo de licencia es crucial para formar una comunidad sana alrededor de IronBee.
Entonces, por la parte técnica, queremos que IronBee sea portable (ModSecurity sólo funciona con Apache), y también operar en una variedad de modos de despliegue (como por ejemplo, sniffer, batch, proxy, etc). Para resolver estos y otros retos de arquitectura, necesitamos empezar nuestro código desde cero.
¿Ha parado Breach el desarrollo de su versión de ModSecurity? Está claro que tú aún le añades funcionalidades (por lo que he leído en el último hilo del DoS basado en subir ficheros mediante POST)
Trustwave compró Breach Security el año pasado, así que ModSecurity les pertenece también a ellos. El proyecto sigue, aunque no sabemos mucho sobre sus planes. Yo personalmente no contribuyo con nada de código a ModSecurity, pero continuaré con my libro, ModSecurity Handbook, actualizándolo el tiempo que sea.
¿Es el WAF la bala de plata contra las amenazas web?
No hay balas de plata, por lo que el WAF no puede ser una.
Los Cortafuegos de Aplicaciones Web han sido ampliamente incomprendidos. Para explicar por qué, empezaré por el principio: La única forma de estar seguro es tener software seguro. Pero eso es algo que no tenemos a día de hoy. Una vez que tú asumes que tu software no es seguro puedes intentar aplicar diferentes medidas para afrontar la inseguridad, pero ninguna de ellas será infalible. Los WAF tienen dos roles: uno estratégico y otro táctico.
El rol estratégico del WAF es proveer visibilidad y servir de dispositivo de auditoría. Entonces, cuando tus sistemas han sido comprometidos (que lo serán inevitablemente), el WAF puede proveerte de un registro de ese evento y ayudarte a entender cómo se llevó a cabo (N. Del T: En inglés “Clean Up” es ordenar/limpiar, pero Ivan creo que se refiere a poder analizar cómo han comprometido el sistema).
El rol táctico de un WAF es ayudar a mitigar riesgos, y lo hacen proporcionando un amplio rango de funcionalidades que hacen la explotación más difícil. Algunas de las características son más efectivas (como por ejemplo el “Virtual patching”) y otras menos (como por ejemplo una lista negra), pero todas juntas, dan valor.
Muchas veces he escuchado (y además vivido, por supuesto) que ModSecurity es complicado que lo implanten grandes organizaciones porque no posee una GUI. ¿Por qué no lanzaste un proyecto paralelo para gestionar gráficamente las reglas y los logs (por ejemplo) de ModSecurity? Sé perfectamente que hay soluciones comerciales con GUI (como por ejemplo Breach) pero ¿cuándo habrá una GUI confiable y libre? ¿La tendrá Ironbee?
Tienes toda la razón; ModSecurity es difícil de usar cuando pasas de un despliegue de una sola sonda/sensor. El problema no es con ModSecurity en sí mismo, sino con el hecho de que a ese nivel, necesitas una GUI.
Puedes expandir la pregunta de la GUI de ModSecurity a IronBee y a cualquier proyecto Open Source. Si miras a tu alrededor encontrarás que no hay virtualmente buenas GUIs Open Source que gestionen la infraestructura. La respuesta a esto es muy sencilla: Las GUIs no resuelven los problemas “de base” que los autores de los proyectos intentan solucionar. La mayoría de éstos que están involucrados con proyectos Open Source porque tienen un agujero que tapar (N. Del T.: “Itch to Scratch” es literalmente “un picor que rascar”), y no necesitan una GUI para eso.
Las GUIs se utilizan para las funcionalidades de gestión, que es un problema que generalmente sólo tienen las organizaciones. Esa es la razón por la que las GUIs se desarrollan comercialmente, para satisfacer la demanda del mercado.
¿Qué opinas de la seguridad por oscuridad como una medida de protección?
La oscuridad no provee de ninguna seguridad, pero crea cierta protección en la forma de obstáculo/valla que tu adversario tiene que superar antes de que pueda explotar activamente alguna vulnerabilidad que puedas tener. Por ejemplo, fíjate en los ataques de fuerza bruta contra SSH. Si cambias el puerto del 22 a cualquier otro, no te ayudará si tus contraseñas son inseguras, pero te hará más seguro en general porque la mayoría de los ataques automatizados no te molestarán a puertos no estándar. Sin embargo, si quien tienes como enemigo es un atacante experimentado, no le costará mucho descubrir donde está el puerto real para SSH y atacarte.
Debido al vertiginoso crecimiento de las redes sociales, la interacción entre los usuarios y su autonomía para ejecutar aplicaciones (que no son siempre seguras),… ¿piensas que las tecnologías WAF serán adoptadas por organizaciones enormes como Facebook, Twitter, Youtube, LinkedIn, etc,… o les penalizaría demasiado el rendimiento y que en vez de eso preferirán escribir y certificar código seguro?
Estoy seguro que todos los sitios que mencionas, ya tienen algún sistema de monitorización de la actividad de los usuarios y que, bajo mi definición, cae bajo la responsabilidad de un cortafuegos de aplicación web. Ellos probablemente le llaman de alguna otra forma, pero el principio es el mismo. El rendimiento no es un problema, simplemente porque el coste de la monitorización es efectivamente el coste de hacer un negocio online. Sin seguridad, los sitios podrían estar bajo el control de criminales.
Esto es por lo que decía que los WAF han sido malentendidos/incomprendidos. Parte del problema es con el nombre, porque la palabra “Cortafuegos” implica control de acceso. Eso es por lo que yo generalmente prefiero llamarlos “sensores de la seguridad de las aplicaciones”.
Respecto al tema del rendimiento, sólo puede ser un problema si piensas en un WAF como una capa separada funcionando como “proxy inverso”.
La mayoría de las grandes organizaciones lucharían contra este enfoque. Sin embargo, si adoptas la solución embebida e instalas un “sensor de seguridad de aplicaciones” en cada servidor web, tu WAF escalará automáticamente con tu sistema.
¿Cuál es tu relación con Qualys? ¿Tienes que vender su tecnología, asesorarles para mejorar, dar tu opinión y definir estrategias o incluso directamente desarrollas código para algún módulo?
En Qualys, gestiono un equipo de desarrollo que trabaja en IronBee y también en otras ofertas comerciales de Qualys. Me centro en lo que está dentro de mi dominio y trabajo haciéndolo tan bien como puedo.
¿Qué haces en tu tiempo libre? ¿Sabes lo que es eso?
Bueno, raramente tengo tiempo libre en estos días. Si tuviera, probablemente escribiría otro libro y buscaría nuevas formas de literatura técnica para escribir y leer. Me apasiona el concepto de lo que yo llamo “publicación continua” que consiste en que para mí un libro técnico nunca se termina. Tienes que continuar actualizándolo e interactuar con tus lectores indefinidamente. Actualmente, los mecanismos de publicación dominantes no lo permiten fácilmente, y es por eso por lo que para publicar “ModSecurity Handbook” en la forma que quise, tuve que iniciar mi propia compañía editorial, Feisty Duck
¿Cuál es tu sistema operativo favorito? ¿Y qué lenguaje de programación?
No tengo un sistema operativo favorito, probablemente porque soy una persona muy práctica y uso cualquiera que me permita hacer el trabajo. Aunque podríamos decir que soy una persona UNIX. Para servidores me gusta Debian, pero me he pasado hace poco a Ubuntu debido a su opción de soporte long-term. En el lado cliente, utilizo Windows XP y Mac OS X a partes iguales probablemente.
Como lenguaje de programación, uso C, PHP y Java, dependiendo de la tarea: C para programación de sistemas, PHP para cosas rápidas y scripting y Java para web y servicios (N. Del T.: Originalmente “daemon applications”)
Muchísimas gracias Ivan! Buena suerte con IronBee,… en el otro lado, te encontrarás un montón de gente que estará dispuesta a darte batalla!
Fuente: SecurityByDefault
