16 marzo 2011

Entrevista a Ivan Ristic, creador de ModSecurity

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 serun 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 estará dispuesta a darte batalla!


A continuación, para quienes no os gusten los subtítulos, os ofrecemos la entrevista a Ivan en versión original.

Interview to Ivan Ristic, ModSecurity principal author

Every computers security professional who has dedicated more than a morning to the analysis and study of web security will know Ivan Ristic. In 2002, being a web applications developer, was able to realize of the big security problems that would bring the weakness of web applications development and the big amount of attacks, at application level, that would appear. After looking for, unsuccessfully, along the wide Open Source community, to find some existing project to detect and block application attacks on web requests, he finally decided to develop his own solution: ModSecurity, the Open Source WAF.

I have to say with great satisfaction, that I had the opportunity to interview Ivan Ristic, who I approached through Twitter, and I was amazed because of the accesible, humble and pleasant that has been the contact and emails exchange with questions to so busy person. I lookup forward the interview seems as interesting for all of you as it was for me.


Hello Ivan, first of all, thank you very much for accepting us to request this interview for our blog. As the visionary you were, to create a new solution from scratch to be able to protect web applications, what do you think about the current security scenario? Which solution that does not exist would you be able to predict, that in 10 years more, there will be no company without it?

You are generous with your compliments, but I was not a visionary. I was not even in the security field back then, and I didn’t even know that I was building a web application firewall. The truth is much simpler—I was aware of many security issues in web applications, and I had to deal with them myself in my development team. ModSecurity emerged from our need to gain visibility into our web application traffic. Without knowing what’s happening in your back yard, you can’t really understand your situation well enough to deal with it.
As for the current security situation, I think we are on the wrong path. Instead of addressing the symptoms, which is what we are doing right now, we should be addressing the root causes of security issues.
What we need to do, is start to build computer systems out of components that are secure by default. That, however, is easily said—but the path we need to follow is not very clear. I try to talk about it in my “Stop complaining and fix a security problem instead” presentation.


As you started with ModSecurity, sold to Breach and now working for Qualys, why did you decided to start a new WAF from scratch (IronBee), instead of forking ModSecurity adding the new features you want?

My main motivation is very simple: Although I am very happy with the success of ModSecurity, there’s more to be done in the web application firewall space, and I want to do that work that will help achieve wider adoption of this technology.
Forking ModSecurity wouldn’t take us as far as we wanted to go. For one, ModSecurity is GPLv2, but we wanted IronBee to be as open as possible—we chose the non-viral Apache license. We believe that the choice of license is crucial for a healthy community to form around IronBee.
Then, on the technical side, we want IronBee to be portable (ModSecurity only works with Apache), as well as operate in a variety of deployment modes (for example, sniffer, batch, proxy, etc). To solve those and other architectural challenges, we needed to start our code base from scratch.


Did Breach stopped the development on their ModSecurity versión? It is clear you still add functionalities to it (as I have read on last POST file upload DoD thread)

Trustwave bought Breach Security last year, so ModSecurity now belongs to them. Development is ongoing, although we don’t know much about their plans. I personally do not contribute any code to ModSecurity, but I will continue to keep my book, ModSecurity Handbook, up to date for the time being.


Is the WAF the silver bullet against web threats?

There are no silver bullets, so a WAF cannot be one.
Web application firewalls are largely misunderstood. To explain why, I will start at the beginning: the only way to be secure is to have secure software. But we don’t have that today. Once you accept that your software is not secure you can try a variety of measures to address the insecurity, but none of them will be foolproof. WAFs have two roles: one is strategic and the other is tactical.
The strategic role of a WAF is to provide visibility and to be an auditing device. Then, when your systems are compromise (as they inevitably will be), the WAF can provide a record of that event and help you clean up.
The tactical role of a WAF is to help with risk mitigation, and they do that by providing a wide range of functionality that makes exploitation more difficult. Some of the features are more effective (e.g., virtual patching) and some less (e.g., blacklisting) but, in aggregate, they provide value.


Several times I have heard (and I have lived it of course) that ModSecurity is hard to be used on large corporations because of the lack of GUI. Why did not you start a parallel project for a ModSecurity WAF to manage graphically rules and logs for example? I know there are commercial solutions with GUI but when will be a reliable open source one? Will IronBee have it?

That’s absolutely right; ModSecurity is difficult to use once you grow out of a single-sensor deployment. The problem is not with ModSecurity itself, but with the fact that, at that level, you need a GUI.
You can expand the GUI question from ModSecurity to IronBee to any open source project. If you look around you will find that there are virtually no good open source GUIs that handle the infrastructure. The answer to that is very simple—GUIs do not solve the core problems the project authors had set out to solve. Most of those involved with open source projects do so because they have an itch to scratch, and you don’t need a GUI for that. GUIs address the issue of management, which is a problem that generally only organizations have. That’s why GUIs are built commercially, to address the market demand.


What do you think about security through obscurity as a way of protection?

Obscurity does not provide any security, but it does create some protection in the form of a hurdle that your adversary needs to overcome before he can actively exploit any of the weaknesses you might have. Take brute-force attacks against SSH, for example. Changing the port from 22 to something else will not help you if your passwords are insecure, but it will make you more secure generally speaking because most automated attacks don’t bother with non-standard ports. However, if you are up against a dedicated attacker, it will be trivial for him to discover the real SSH port and attack you.


Because of the current speed of the social networks, interaction among users and their autonomy to execute applications (which are not always safe),.. do you think WAF technologies will be adopted by huge sites as Facebook, Twitter, youtube, Linkedin, etc,... or the performance would be so affected, they would prefer to write and certify secure code instead?

I am sure that all the web sites you mention already have some form of user activity monitoring and that, under my definition, falls under the responsibility of a web application firewall. They probably call it something else, but the principle is the same. Performance is not an issue simply because the cost of monitoring is effectively the cost of doing business online. Without security, the sites would be taken over by criminals.
This is why I said that WAFs are misunderstood. Part of the problem is with the name, as the word "firewall" implies access control. That's why I usually prefer to talk about application security sensors instead.
On the topic of performance, it is only an issue if you are thinking of WAFs as having a separate reverse proxy layer. Most large sites would struggle with that approach. However, if you adopt the embedded option and install an application security sensor in every web server, your WAF automatically scales with your system.


How is your relation with Qualys? You have to sell the technology, help them to improve it giving your opinion and defining strategies or even directly coding some modules?

At Qualys, I manage a development team that works on IronBee and also on some of Qualys’s commercial offerings. I focus on what’s within my realm and work on making that as good as it can be.


What do you do in your free time? Do you know what “free time” means?

Well, I rarely have free time these days. If I had any, I would probably write another book and look for new ways for technical literature to be written and read. I am very passionate about the concept I call continuous publishing, which is an idea that a technical book is never done. You have to continue to update it and interact with your readers indefinitely. Today’s dominant publishing approaches don’t make that easy, however, which is why, in order to publish ModSecurity Handbook in the way I wanted to, I had to start my own publishing company Feisty Duck.


Which is your favourite operating system? And which programming language?

I don’t have a favourite operating system, probably because I am a very practical person and I use whatever gets the job done. You could say that I am a Unix person, though. On the server side I like Debian, but have recently switched to Ubuntu because of its long-term support option. On the client side, I use Windows XP and Mac OS X in probably equal amounts.
On the programming language side, I use C, PHP, and Java, depending on the task: C for systems programming, PHP for quick tasks and scripting, and Java for web and daemon applications.


Thank you very much Ivan! Good luck with IronBee…. on the other side, you will find a bunch of people ready to fight!

1 comments :

Anónimo dijo...

Me ha parecido genial la entrevista.

Sólo tengo una sugerencia: Creo que deberías avisar al principio de que detrás de la traducción está también la versión original. Ya que al no saberlo la he leído en español y cuando he visto que estaba también en inglés ya había terminado y no tenía ganas de leerla otra vez.

Gracias!