Las cinco trampas más comunes en la protección de las aplicaciones
This post is also available in:
Inglés 
Francés 
Alemán 
Italiano 
Portugués, Brasil 
Ruso
Todos los años, las empresas gastan mucho dinero en las últimas tecnologías de seguridad para proteger la confidencialidad de los datos y la experiencia del usuario. Los directores de seguridad de la información (CISOs) salen a buscar aprendizaje automático, orquestación de análisis y respuesta a los eventos, y confían en los proveedores de la nube pública y su integrador del sistema. No obstante, la violación de los datos sigue ocurriendo.
Primera trampa: “Pensé que un WAF era suficiente”
Ignorar las amenazas adicionales a las aplicaciones ha ido más allá de las vulnerabilidades que aprovechan los 10 riesgos principales para las aplicaciones web enumeradas por OWASP. Sí, los riesgos como inyecciones, scripting entre sitios, CSRF, secuestro de sesión, envenenamiento de las cookies y otros similares siguen estando muy vigentes, en especial cuando todavía se usan tantos sistemas heredados sin parches. Los equipos de desarrollo están poniendo más énfasis en la agilidad que en la seguridad. Sin embargo, la superficie de ataque y, por lo tanto, la exposición a los riesgos es mucho más grande actualmente.
Tres amenazas más contra las que hay que luchar:
1. Los bots maliciosos: un cuarto del tráfico de Internet es generado por los bots maliciosos [CB1]. Con la carga en las redes y los intentos persistentes de apoderarse de las cuentas de los usuarios, la manipulación de las transacciones en línea y extracción de datos sensibles, las organizaciones no pueden confiar solamente en el firewall de las aplicaciones web, o peor, perder tiempo creando scripts personalizados desarrollados internamente, y deben empezar a pensar en una tecnología de gestión de bots dedicada. Una tecnología que permita la entrada de los bots buenos y repela a los malos con precisión.
2. Protección de las APIs: sistemas y aplicaciones interconectadas que intercambian datos a través de las APIs. Por lo general, estas son confiables y, por lo tanto, pueden pasarse por alto fácilmente. El robo de datos a través de las APIs mal protegidas ya se ha informado varias veces (PaneraBread, Venmo, Boots y mucho más). Las organizaciones no siempre están al tanto de todas las APIs que tienen, qué tipo de datos procesan y quiénes tienen acceso a ellas. Necesitan una buena herramienta para descubrir, clasificar y asegurar todos los puntos de conexión de sus APIs.
3. Denegación del servicio: ha pasado mucho tiempo desde que este era un problema para los operadores de la red. Los servidores web y los activos digitales ahora son los objetivos frecuentes de los adversarios que quieren interrumpir o dejar fuera de servicio un sitio web. Es totalmente lógico integrar una protección contra DDoS de alto volumen como parte de la estrategia de seguridad de las aplicaciones.
Segunda trampa: “Estuve tentado de combinar mi WAF con el servicio CDN”
Sí, es totalmente lógico. Si te importa el rendimiento más que los datos sensibles de tus clientes, esa podría ser una buena forma de actuar. Pero, si te sientes responsable de proteger los datos de la empresa y los usuarios, debes repensar este compromiso. Por la naturaleza de la arquitectura, un WAF en el extremo de la red no ve el tráfico de cada aplicación y, por lo tanto, no puede aplicar ningún mecanismo de aprendizaje, detección de anomalías y seguridad positiva, que resultan de la falta de protección de día cero. Es muy probable que se violen los datos de estas aplicaciones porque no están protegidas contra técnicas de ataques desconocidas.
En los entornos de nube pública, la brecha es aún mayor, ya que la tecnología de WAF que brinda el proveedor de IaaS, no un proveedor especializado, a menudo tiene una clasificación baja en los informes de los analistas. Más en nuestro blog anterior
Tercera trampa: “Puedo implementar la misma seguridad en todas las plataformas”
Eso es una verdadera pena. Si quieren ejecutar la misma política de seguridad de las aplicaciones en todos los entornos –centros de datos, nube privada, Azure, AWS, GCP y Alibaba o Tencent– las empresas están obligadas a sacrificar algo. El motivo es que cada entorno y cada proveedor requiere ajustes, tales como permisos de acceso, protección de la infraestructura, mecanismos de autenticación y autorización, controles del tráfico de bots, herramientas de seguridad de las APIs en el backend y mucho más.
Si uno elige consistencia (como un servicio administrado basado en la nube), en ese caso ambas, la experiencia del usuario (latencia) y la seguridad (consulta la segunda amenaza más arriba) están en riesgo. Elegir la optimización de la seguridad resultará en un esfuerzo para ajustar las soluciones correctas para cada entorno, y dedicar tiempo y recursos para actualizar e imponer constantemente la política de seguridad que el CISO quiere implementar.
Esta situación desafortunada lleva a otra posición de seguridad con muchas fallas, donde las consecuencias potenciales ya se pueden adivinar. Estas son algunas prácticas recomendadas.
[¿Te gusta esta publicación? Subscríbete ahora para recibir el contenido más reciente de Radware en tu bandeja de entrada todas las semanas, además de acceso exclusivo al contenido Premium de Radware].
Cuarta trampa: “Creí que podía manejar todas las excepciones por mi cuenta”
Históricamente, los firewalls de aplicaciones web han sufrido de mala reputación, y por una buena razón. Se bloquearon demasiadas normas legítimas de las reglas y configuraciones que no estaban en línea con los requisitos comerciales. Cuando eso sucede, el costo puede ser devastador. Una mala experiencia del usuario lleva a una posición negativa hacia la marca y a una reducción en los índices de conversiones. El costo total de propiedad (TCO) de gestionar un WAF interno puede ser muy alto debido al trabajo general requerido y a que es un asunto de expertos, en especial cuando se tienen en cuenta todas las amenazas de seguridad mencionadas anteriormente. Un ojo menos experimentado no podrá ver a través de la gran cantidad de alertas que vienen de diferentes soluciones puntuales. Una estrategia de seguridad consolidada gestionada por expertos con automatización avanzada y análisis accionable reduce drásticamente el TCO mientras ofrece seguridad a gran velocidad.
[También puede interesarte: How To Achieve Application Protection Behind AWS/Azure CDN]
Quinta trampa: “Creí que DevOps escucharía”
Algunos ataques no tienen éxito gracias a una posición de seguridad débil y desarticulada debida a procesos inutilizados y conflictos internos. La dinámica de hoy en día del desarrollo y las prácticas de seguridad de las aplicaciones es tal que las soluciones de seguridad y el personal especializado no pueden seguirle el ritmo. Desde la perspectiva de un desarrollador, hay muchas ventajas disponibles para diseñar la canalización de CI/CD perfecta con herramientas automatizadas de aprovisionamiento, pruebas y orquestación. La agilidad se trata de correr hacia adelante, la siguiente versión, el siguiente parche, la siguiente corrección de una falla, no de disminuir la velocidad para inspeccionar cada transacción y cada módulo. Dado que la productividad siempre viene primero, la seguridad debe acompañarla. No obstante, este es un equilibrio delicado que cada organización maneja de manera diferente. Mientras DevOps está teniendo más influencia en las decisiones relacionadas con la seguridad, el personal de seguridad de la información debe tener en cuenta que una solución de seguridad de las aplicaciones debe hacer mucho más que solo bloquear los ataques, se debe integrar bien con el ecosistema SDLC, y poder adaptarse y ajustar la política cada vez que se introduce un cambio en las aplicaciones. También debe darle a DevOps la visibilidad que necesita en las métricas de rendimiento y la automatización en todos los entornos. De esta forma, corregimos el proceso y todos estamos contentos.
Evitar estas trampas resultará en una estrategia de seguridad de las aplicaciones que sea:
• Consistente
• Transparente
• Adaptativa
• Eficaz
