En un artículo publicado en TechTarget, el experto Michael Cobb habló acerca de una tecnología de seguridad cuyo uso se está popularizando entre los desarrolladores: RASP, Runtime Application Self-Protection. A continuación, conoceremos un poco más de ella a través de lo que dijo, junto con algunas reflexiones interesantes acerca de los efectos que tiene en la seguridad la presión de desarrollar cada vez más rápido y con más funcionalidades.
El problema con el tema de la seguridad
Según Cobb, la mayoría de las metodologías de desarrollo de software no priorizan la seguridad. El enfoque se pone sobre todo en encontrar maneras más eficientes de desarrollar productos finales en el menor tiempo posible. Estas filosofías y modelos de procesos tienen como objetivo final cumplir plazos de entrega cada vez más estrechos de cara a mantenerse en pie en un entorno competitivo cada vez más feroz.
Para solucionar esta problemática, han ido apareciendo con el tiempo varias iniciativas y tecnologías con la intención de reducir los fallos de seguridad que podrían colarse en una versión final. Por ejemplo, Microsoft dio un paso adelante con su Trustworthy Computing Security Development Lifecycle en 2004 para propiciar un cambio de mentalidad en este aspecto. Y al margen de la propuesta de los de Redmond, tenemos también otras tecnologías bastante populares entre los desarrolladores preocupados por la seguridad como IAST (Interactive Application Security Testing), DAST (Dynamic Application Security Testing) y SAST (Static Application Security Testing).
Sin embargo, esto no parece ser suficiente. Los ataques exitosos contra aplicaciones desarrolladas y gestionadas por algunas de las más grandes empresas del sector aparecen casi de manera diaria, lo cual pone en tela de duda la efectividad de estos métodos.
Es en este contexto en el que RASP se perfila como una opción a tener en cuenta.
Qué es RASP
Cuando la tecnología RASP (Runtime Application Self-Protection) se integra en una aplicación, obtiene la capacidad de controlar su ejecución, lo cual permite detectar y prevenir ataques en tiempo real. Tal y como se explica en TechTarget, su objetivo es cerrar el hueco que hay entre las pruebas de seguridad de las aplicaciones y los controles perimetrales de la red, ninguno de los cuales tienen conocimiento suficiente de los datos en tiempo real y de los flujos de eventos como para prevenir vulnerabilidades que se hayan escapado en el proceso de revisión o bloquear nuevas amenazas no previstas durante el desarrollo. Por ejemplo, Application Defender de HP monitoriza las llamadas de la API de una aplicación a las principales librerías, permitiendo analizar el flujo de la aplicación e identificar eventos potencialmente maliciosos, como el cross-site scripting o la inyección de código.
La seguridad de las aplicaciones protegidas por RASP permite depender menos de dispositivos externos como los firewalls, de manera que si este tipo de defensas fallan al identificar el tráfico malicioso y, además, también el equipo de desarrollo ha fallado en implementar una validación apropiada que examine la introducción de datos por parte de un usuario, la aplicación aún puede protegerse a sí misma. Al permitir que una aplicación realice chequeos continuos de seguridad y que pueda responder a ataques en vivo, se provee de un nivel adicional de protección en la medida en que se puede finalizar la sesión de un usuario malicioso si se detecta un ataque y alertar a los sistemas de monitorización acerca de lo que ha sucedido.
Confiar solo en las tecnologías no es suficiente
En principio, las tecnologías RASP parecen una buena idea. Esa «autoprotección» que brindan ayuda a construir aplicaciones en Internet que sean más robustas y seguras. Sin embargo, para Cobb, esto puede tener un efecto secundario que no hay que desdeñar.
Y es que, siempre según Cobb, los equipos de desarrollo tienden a relajarse un tanto en el momento que aparece una nueva tecnología o metodología, confiando en ella para que se encargue de la seguridad por ellos. Esto ocurre, entre otras cosas, porque las presiones comerciales hacen que los desarrolladores se enfoquen en actualizaciones frecuentes dentro de ciclos de desarrollo cortos para introducir nuevas características con más rapidez.
Lo más recomendable de acuerdo a Cobb es que los desarrolladores vean la seguridad como una feature más que debe ser probada tal y como se hace con cualquier otra, definiendo unos requerimientos mínimos de seguridad durante las etapas de diseño y arquitectura de un proyecto, lo cual les permitirá planear e integrar controles de seguridad de mejor manera.
Por lo tanto, está claro que tiene sentido añadir RASP como otra capa de seguridad, pero no como una solución rápida al problema, pues eso no existe cuando estamos hablando de seguridad. Recurrir a RASP, sí, pero a la vez que se aplican una serie de buenas prácticas que nunca deben dejarse de lado.
Imagen: Veracode
