Pese a trabajar para un fabricante de soluciones WAF (Web Application Firewall), intentaré ser objetivo, puesto que sigo pensando que mientras el mundo requiera desarrollos "para ayer", la seguridad de las aplicaciones web queda relegada a una menor prioridad primando la funcionalidad y "cuanto antes". Lo verdaderamente seguro sería que los desarrollos pasasen por estrictos ciclos de calidad, de principio a fin, en los que la base fuesen los criterios de programación segura por encima de todo. Otro ingrediente esencial es una correcta y ágil administración de parches para el software de los servidores expuestos a Internet para evitar sorpresas por problemas en la infraestructura utilizada.Como las metodologías de desarrollo seguro no suele estar entre las buenas prácticas de las organizaciones más que en un mínimo porcentaje de los casos, ya sea por desconocimiento, por sub-sub-sub-sub-sub-contratación de los servicios de desarrollo o por prisas infundadas,… para tener la tranquilidad (y a veces por necesidad de cumplimiento únicamente), hay otras dos alternativas: auditorías periódicas o proteger mediante un dispositivo WAF que analice las peticiones web y bloquee las que considere como maliciosas.
Partiendo de que no se siguen metodologías de programación seguras, el eterno debate entre la preferencia entre auditar o proteger con WAF se ve zanjado con la mejor de las respuestas: las dos cosas.
La demostración más clara de ello es la decisión por parte de la empresa de seguridad americana Trustwave Spiderlabs al comprar Breach Security. Quizá Breach no os suene mucho, pero es la marca comercial de un WAF de los que ya hemos hablado en varias ocasiones en SbD. Se trata de mod security, un módulo de seguridad a nivel de aplicación embebido en Apache. De hecho, uno de los creadores de mod_security, Ivan Ristic era uno de los principales desarrolladores trabajando para Breach.
Con la compra de este tipo de solución, la empresa Trustwave Spiderlabs que, entre otras, ya proporcionaba soluciones y servicios de seguridad, completa su portfolio sobre todo para ofrecer a empresas que necesiten cumplir con determinadas normativas. Un ejemplo de esto es PCI-DSS, obliga a empresas que permitan utilizar tarjetas de crédito en sus negocios online, cumplan una serie de requisitos. En el punto 6.6 se indica claramente que sus aplicaciones web deberán ser convenientemente auditadas periódicamente y/o protegidas mediante una herramienta WAF.
Lo sensato a la hora de proteger las aplicaciones web sigan o no metodologías de programación segura, desde mi punto de vista, es añadir más capas de seguridad, basadas en auditoría y en WAF. Una serie de auditorías programadas con una frecuencia determinada ayudan a determinar dónde están los puntos débiles a nivel de aplicación y obligar por supuesto a su corrección para la siguiente evaluación. Sin embargo, contar con un WAF que permita "parchear virtualmente" esas aplicaciones, disminuye el tiempo de exposición desde que se detecta un agujero hasta que se tapa, así como reaccionar ante determinados ataques Zero-Day de una manera mucho más ágil.
En una estrategia de seguridad por capas, la unión de ambas técnicas para la protección puede hacer que un "encargo" de obtener información sensible de una organización, fuerce al atacante a buscar por otro sitio que no sea la web,… y Trustwave, parece que también opina lo mismo.
9 comments :
Con la seguridad de las webs siempre he dudado como vender a las empresas una vulnerabilidad encontrada. Es decir, si un atacante es capaz de sacar información de sus BBDD, suplantación de credenciales... lo mejor es contactar con la empresa mostrándole pruebas de que lo has hecho o simplemente comentarles que se puede?
@Anónimo -> Lo éticamente correcto suele ser contactar con ellos indicándole que haciendo esto, esto y esto otro, eres capaz de hacer nosequé. En muchas ocasiones ni siquiera les importa a las empresas las notificaciones de descubrimiento de una vulnerabilidad. Hablamos de esto en: http://www.securitybydefault.com/2009/05/les-importa-las-empresas-las.html
Gracias por el enlace. En cuanto al tema "remuneración"... si es cliente tuyo imagino que arregláis/vendéis una solución o en caso de trabajar en un auditoría ofrecerles vuestros servicios pero en el caso de un particular?? No es por ser pesetero pero avisándoles del problema, dándoles la solución y todo para que se la reporten a sus programadores recibiendo ya el "trabajo hecho"...
Lorenzo,
Como ya hemos comentado en alguna ocasion, me sigue sorprendiendo que los WAF no acaben de despegar. Y eso que mucha gente tiene puesto mod_Security, obviamente, no es suficiente.
Por que no hay instalaciones WAF en cada casa?
Has visto muchos ejemplos, y los conoces de sobra en "nuestras casas". Es otro dispositivo mas, "desconectado" de lo que se hace por debajo, "desconectado" de la vision del mundo, y virtualmente "desconectado" de las capas de seguridad perimetral. (si, ya se que no es exacto del todo, pero vale como argumento global)
Creo que se enfoca mal el producto, y alguna vez lo hemos comentado. Creo que en un mundo donde la seguridad es algo anecdotico en los presupuestos, que muchas veces hay que usar otras partidas para justificar las auditorias, habria que usar esa misma debilidad como fortaleza. Lo pondre muy sencillo
1) un dispositivo WAF debe venderse y tener todas las funcionalidades de un firewall perimetral. Ya tienes dos dispositivos en uno
2) Como los desarrolladores al final NO son expertos en seguridad y NO van a seguir las best practices (porque no nos engañemos, en una empresa "x" hay 1 jefe proyecto, 3 analistas, y 10 desarrolladores, de los cuales 5 son junior y 3 quieren irse a casa cuanto antes sin hacer horas extra), hay que hacer que sigan "las vias del tren". Es decir, usar un framework lo mas rigido posible que este en consonancia con el WAF.
3) La auditoria automatica, parcheado, vulnerabilidad, se tratara todo como uno, desde ambos puntos de vista.
Si, es idilico, pero creo que es la unica forma de abordarlo, o los WAF nunca despegaran.
cbote aka CarloX
@Anónimo -> yo te hablaba tanto en el caso de una organización con presupuesto para seguridad, a la que le notificas un fallo, en mi caso particular, le he ofrecido presentarle el WAF de mi empresa como solución previa al parcheo de la aplicación web vulnerable. En el caso de un particular, lo suyo es mandarle un correo y hacerle saber que su web "particular" está mal configurada... no sé si merece la pena ofrecerle una auditoría o un WAF.
@CarloX -> claro que lo hemos hablado varias veces. Pero tanto contigo como con otros potenciales clientes que me han realizado planteamientos similares a los tuyos ante por qué no ponen un WAF en sus redes.
También hace 10 años veías una barbaridad añadir un IPS en la red como elemento aislado para filtrar ataques de capas superiores en otros protocolos. El añadirlo a las capacidades de un firewall de red o un UTM incluso es una solución válida si eres de los que están de acuerdo con la filosofía all-in-one, en contra del best-of-breed. La desventaja del "all in one" es que si una de las funcionalidades del UTM no te gustan, te la tienes que comer igualmente porque es la que viene. En la "best of breed", tú eliges qué soluciones has evaluado y te gusta más para cada funcionalidad. En el caso del WAF, su localización es justo delante de las aplicaciones Web, ¿para qué vas a integrarlo como parte del UTM tan al principio? Por otra parte, el rendimiento siempre será mejor si tienes diferentes dispositivos especializados en hacer una única misión que uno sólo que además de antispam, antivirus y proxy saliente, balanceador, VPNs, etc,... haga de terminador de túneles SSL entrante y filtre ante ataques de nivel de aplicación.
Para los desarrolladores, se suele proponer una solución WAF más sencillita delante de los servidores web de desarrollo con la misma política de seguridad que el de producción, para forzar a que se programe adaptados a dicha política.
No obstante, en los tiempos que corren en España, los presupuestos son lo que más restringen este mercado.
Sin embargo, como decía en el post, no creo que el WAF sea lo único necesario, sino simplemente un seguro más para eliminar el tiempo de exposición de una vulnerabilidad existente. Las buenas prácticas (donde se sigan), auditorías periódicas (sin pasar por el WAF y pasando por él) y el parcheado de los fallos encontrados son la forma de hacer las cosas correctamente, pero contar con un mecanismo que cubra más gaps es mejor que no contar con él, ¿no?...
Bueno, ya lo discutiremos con esa birra que tenemos pendiente :D
Muchas gracias por vuestros comentarios a todos!
Si no pertenezco a ninguna empresa,¿ cómo aviso de las vulnerabilidades pudiendo obtener beneficios?
En el caso de una vulnerabilidad en un web concreto y no en una aplicación, olvídate de cualquier empresa estilo iDefense, ZDI...Ese tipo de fallos no se compran. El único beneficio que podrías sacar de eso, sin entrar en el mercado negro, es algún reconocimiento por parte de la empresa o como en el caso de Nokia, que te envíen un teléfono :)
Si es un fallo en un software ámpliamente usado, sí puedes contactarles. No si es en un fallo del MyCuñadoScript 2.0.
Gracias Ruben. Se podría decir que las vulnerabilidades web no son rentables a no ser que te pidan una auditoría.
En el caso de una vulnerabilidad en un web concreto y no en una aplicación, olvídate de cualquier empresa estilo iDefense, ZDI...Ese tipo de fallos no se compran. El único beneficio que podrías sacar de eso, sin entrar en el mercado negro, es algún reconocimiento por parte de la empresa o como en el caso de Nokia, que te envíen un teléfono :)
Si es un fallo en un software ámpliamente usado, sí puedes contactarles. No si es en un fallo del MyCuñadoScript 2.0.
Publicar un comentario