Las nuevas reglas de seguridad para aplicaciones web y API
A decir verdad, la mayor parte de las herramientas de seguridad para aplicaciones web y API se diseñaron para otros tiempos. Tiempos en los que los desarrolladores y profesionales de la seguridad no colaboraban para crear software seguro mediante flujos de trabajo integrados; en los que las aplicaciones no se distribuían globalmente ni se basaban en API; en los que ningún ingeniero podría haber imaginado que introducir un comando le permitiría conseguir al instante una actualización a escala global. Pero, como le gusta decir a nuestro CEO, Joshua Bixby: «Los atacantes también son desarrolladores». Y las limitaciones que presentan las soluciones antiguas no son un obstáculo para ellos. Son tan ágiles como de costumbre: usan herramientas y flujos de trabajo de última generación para concebir nuevas amenazas e intentar ir un paso por delante en esta materia. Nunca antes había sido tan evidente que ya es hora de cambiar. Así que estamos perfilando nuevas reglas de seguridad para las aplicaciones web y las API que respeten la forma en que se diseñan las aplicaciones en la actualidad.
Regla 1: Las herramientas deben combatir intenciones, no amenazas específicas
Los expertos en seguridad llevan mucho tiempo centrados en combatir amenazas específicas. Al evaluar nuevas herramientas, lo que buscan es protección frente a amenazas concretas, que suelen acaparar grandes titulares, como el caso de Stuxnet o, más recientemente, el pirateo de SolarWinds. Este estilo de evaluación lleva a los profesionales a emplear herramientas que buscan firmas o «indicadores de compromiso» (IoC) de una amenaza en concreto. Los IoC incluyen elementos como las direcciones IP de atacantes conocidos y expresiones regulares que coinciden con una URL de petición particular a la que apunta el malware.
Las herramientas basadas en firmas carecen de la capacidad de distinguir con precisión el tráfico legítimo del malicioso y de seguir el incesante ritmo con el que van apareciendo nuevas amenazas. Lo cual es lógico: según algunos estudios recientes, más de 350 000 nuevas variantes de malware se crean cada día.
Ahora ya sabemos que este modelo no funciona, como demuestra el fracaso de los proveedores de antivirus, incapaces de proteger contra amenazas; de los proveedores de WAF antiguos, que solo buscan inyecciones SQL o scripts entre sitios; y de las herramientas de mitigación de bots, que únicamente examinan el agente de usuario de los navegadores solicitantes.
El nuevo enfoque de seguridad para aplicaciones web y API exige un modelo que esté dotado de mayor inteligencia y que infunda suficiente confianza en la cadena de herramientas de seguridad, de modo que un profesional pueda ejecutar el sistema con confianza frente a tráfico valioso sin temor a que bloquee intentos legítimos de acceso o permita el paso de los maliciosos.
Para conseguirlo, es necesario plantear nuevas exigencias a la tecnología de seguridad. En primer lugar, los profesionales deben exigir herramientas que examinen no solo la firma del tráfico, sino también su intención o comportamiento. Lo cual significa tener en cuenta factores como la velocidad de la petición, la hora del día y el estado de inicio de sesión del usuario.
En segundo lugar, los diseñadores deben exigir que las herramientas se puedan ejecutar no solo en modo de supervisión, sino también en modo de bloqueo. Las herramientas que solo pueden ejecutarse en modo de supervisión por temor a falsos positivos refuerzan la disfuncionalidad del sistema: cuando el equipo responde, el daño ya está hecho. Imagínate a un superhéroe que vocifera desde una esquina al detectar algún delito —«¡Peatón cruzando imprudentemente!» o «¡Atención, un robo!»— y que luego se pone a esperar a la policía en lugar de arremangarse y tomar cartas en el asunto. Las alertas están abrumando a los equipos de seguridad y operaciones. Aunque siempre serán necesarios los equipos de detección y respuesta (que analizaremos más adelante cuando abordemos la visibilidad y el control), estos precisan herramientas esenciales capaces de bloquear con confianza las amenazas en el momento en que se producen, no diagnósticos del problema posteriores a la violación de seguridad.
Por último, las herramientas deben mantenerse al día respecto a las amenazas actuales sin que ello comporte una carga adicional para los equipos de seguridad y operaciones. La modernas soluciones tipo SaaS y en la nube te permiten sacar el máximo partido de un equipo de seguridad de producto que se anticipa a las amenazas y distribuye actualizaciones con proactividad. Dejarás de preocuparte por la aplicación de parches y ya no te obsesionarás con las amenazas más recientes.
Regla 2: No hay seguridad sin usabilidad
El incremento de las experiencias web intuitivas al estilo de las web para consumidores en las herramientas tipo SaaS ha hecho que la usabilidad sea casi un requisito indispensable en la mayoría de las herramientas tecnológicas. A pesar de ello, lamentablemente las soluciones de seguridad se quedan atrás. Las herramientas antiguas se diseñaron para hacer cumplir y controlar, no para ser usadas por operadores. Sin embargo, los equipos modernos esperan tener algún vínculo con sus herramientas: necesitan la capacidad de integrar, observar y adoptar medidas.
La interfaz de usuario es la primera línea de defensa de cualquier operador. Por desgracia, es también el primer punto en que se descuida la usabilidad: las interfaces de usuario antiguas pueden llegar a ser lentas y engorrosas. Y los operadores a menudo tienen que iniciar sesión en varias interfaces para administrar el sistema, incluso cuando utilizan soluciones del mismo proveedor. Una interfaz de usuario deficiente crea todo tipo de riesgos: lagunas en cuanto al cumplimiento de políticas en todas las herramientas, lentitud y falta de coordinación en la respuesta a las amenazas urgentes, e incongruencias en la visibilidad del ecosistema de seguridad integral —o, lo que es peor, su invisibilidad—.
Toda solución de seguridad debería disponer de una interfaz única, intuitiva y fácil de usar que permita controlar y ver toda la solución. La observabilidad debería ser global y estar integrada de modo que se brinde una visibilidad completa del estado del sistema con un solo vistazo. Y, lo que es más importante, estas soluciones deberían poder usarlas los equipos de seguridad y los demás equipos, ya que en los departamentos de operaciones e ingeniería cada vez hay más personas implicadas en la lucha contra las amenazas.
Otro aspecto a tener cuenta es que las herramientas modernas deben adaptarse al diseño también moderno de las aplicaciones. Con demasiada frecuencia, un proveedor se encarga de empaquetar y vender conjuntos de herramientas que, sin embargo, no son realmente capaces de integrarse desde el punto de vista técnico. Un amigo mío lo llama «integración por factura». Si, para desplazarte por las soluciones, tu sistema te obliga a cambiar de pestañas, estarás perdiendo un tiempo y una visibilidad integrada muy valiosos mientras sufres el ataque. Este enfoque debilita tu seguridad general, ya que crea brechas técnicas y de visibilidad. Los proveedores deberían ofrecer automatización e integración por defecto, lo cual empieza por el control total de las API. Todas las soluciones de seguridad deberían albergar API fáciles de usar que expongan toda la funcionalidad del sistema. Las soluciones se deberían integrar fácilmente no solo entre sí, sino también con toda la cadena de herramientas de respuesta, como Jira, PagerDuty, Slack y Splunk. Además, deberían ofrecer registros y estadísticas en tiempo real que expongan los datos en cualquier sistema de supervisión u observabilidad de seguridad que utilice el equipo. Al integrar todas tus soluciones, te resultará infinitamente más fácil determinar la verdadera intención del atacante.
Regla 3: Los ataques en tiempo real requieren reacciones en tiempo real
El malware es un sistema de software, que es obra de desarrolladores. Por eso, los atacantes son también desarrolladores. Si se es consciente de este hecho, es mucho más fácil entender por qué las amenazas están superando los modelos de seguridad convencionales. Los atacantes acostumbran a ser ágiles y a emplear flujos de trabajo DevOps avanzados para probar, ajustar y desplegar rápidamente nuevos métodos. Puede ocurrir cientos de veces en un único ataque. ¿Cómo puedes proteger tus aplicaciones si no puedes reaccionar con la misma rapidez? Para ponerlo claro y diáfano: el tiempo de reacción no está limitado por la velocidad con la que funciona tu cerebro; depende de la velocidad de tus soluciones de seguridad. Vamos a dividirlo en velocidad de visibilidad y velocidad de control.
Velocidad de la visibilidad
Si detectar un ataque lleva minutos u horas, ya es demasiado tarde: si tras un primer intento los atacantes no tienen éxito, lo vuelven a intentar. Todo esto sucede en cuestión de minutos. Para cuando la solución de seguridad que utilices sea capaz de transmitirse los datos a sí misma o a un sistema SIEM o de supervisión, el daño ya está hecho. La visibilidad en tiempo real (medida en segundos) sirve tanto para los flujos de trabajo automatizados como para los manuales: permite al sistema aplicar lógica en tiempo real para examinar amenazas y brinda a los operadores la capacidad de reaccionar ante alertas que requieren intervención humana. En ambos casos, la visibilidad debe ir de la mano del control.
Velocidad de control
Una vez que tú o tu sistema consigáis ver la amenaza, la velocidad de respuesta o corrección es fundamental. El enfoque de mitigación basado en la intención, que es más inteligente, requiere varios flujos de datos para tomar una decisión. Los sistemas basados en la intención funcionan como sistemas de autoaprendizaje y autorrecuperación; es decir, analizan constantemente patrones y comportamientos para predecir amenazas nuevas o en evolución. Por ello, es imprescindible no solo que vean e interpreten el tráfico en tiempo real, sino que también tengan el poder de desplegar nuevas reglas en respuesta a amenazas cambiantes.
Cabe destacar que la velocidad de visibilidad y de control no se pueden limitar a un único despliegue o área geográfica. La prevalencia de los sistemas distribuidos (ya sean despliegues multirregionales y multinube, o una plantilla laboral distribuida que precisa protección) requiere la capacidad de adoptar medidas en varias ubicaciones y atravesando fronteras. Hemos comprobado que algunas soluciones de seguridad son rápidas siempre que la detección y la protección se ejecuten en un solo lugar. El mundo ha dejado de funcionar de esta forma: el software se despliega y las personas se distribuyen por todo el planeta, y la seguridad está obligada a seguir ese ritmo. Para obtener más información sobre esta regla, no te pierdas el seminario web bajo demanda «API-First Security for Real-Time Attack Response» para ver cómo la seguridad basada en interfaces de programación de aplicaciones (API) puede potenciar una rápida respuesta a incidencias.
Regla 4: Desarrollo, seguridad u operaciones, todos deben adoptar la mentalidad de ingeniero
Todos hemos asistido a la evolución que han experimentado los equipos de producción de software, que de trabajar de forma aislada (y dolorosa) en compartimentos estancos han pasado a unificar seguridad, ingeniería y operaciones a través del modelo de DevOps seguro. Sin embargo, estamos lejos de la línea de meta. Aunque muchos responsables de seguridad e ingeniería creen que salvar la brecha técnica y cultural entre los equipos dará lugar a ciclos de desarrollo de aplicaciones más rápidos y seguros, las prácticas y las herramientas anticuadas siguen siendo una rémora.
Una limitación importante es creer que DevOps seguro es más una iniciativa estética que una verdadera integración. Anclar los operadores de seguridad y sus herramientas preferidas al final de tu canal de despliegue no equivale a implementar DevOps seguro, ni tampoco acelera la distribución de tu software. Un verdadero modelo de DevOps seguro diseña la verificación de seguridad y el análisis de vulnerabilidades directamente en el marco de trabajo automatizado de pruebas y despliegue. Además, es una hoja de ruta hacia la integración de los equipos de seguridad en el equipo de desarrollo, no una puerta improvisada para presentar listas de vulnerabilidades y esperar que estas se solucionen antes de que el sistema se active. A su vez, los desarrolladores escriben código utilizando prácticas de desarrollo seguras y canalizaciones automatizadas de CI/CD que comprueban no solo la funcionalidad, sino también los agujeros de seguridad más habituales. Por último, el equipo de seguridad tiene las competencias y la autoridad para emplear auditorías de seguridad exhaustivas en caso de que el sistema automatizado pase algo por alto.
Para que el modelo de DevOps seguro esté a la altura de lo que promete, los profesionales de seguridad, los de operaciones y los desarrolladores deben adoptar una mentalidad de ingeniería centrada en la distribución de software seguro. Acabemos con el duro trabajo de gestionar productos y capacidades de seguridad, de modo que los profesionales de seguridad puedan actuar como ingenieros y no como operadores. Así conseguiremos que el sistema sea más fiable y seguro en su conjunto y, además, brindaremos a los empleados una carrera profesional más satisfactoria.
Una mejor seguridad es esencial para crear mejor software
Han pasado 15 años desde que Amazon lanzó AWS y se inició nuestra migración a la nube. En ese lapso, hemos conocido (y muchos de nosotros hemos adoptado) cientos de nuevos marcos de trabajo, lenguajes, herramientas y servicios destinados a diseñar aplicaciones más rápidas y centradas en el usuario. Y, para ser sincero, ha sido muy divertido. Sin embargo, el punto de fricción entre entregar software con rapidez y hacerlo con seguridad sigue siendo problemático por razones que, de hecho, hoy podemos resolver.
La estrategia para reducir esa fricción debe contemplar soluciones de seguridad que satisfagan las necesidades de los equipos de hoy en día y que integren la seguridad en los aspectos culturales y técnicos del diseño de software. No basta con entregar el software con rapidez: debemos entregar un software de alta calidad de forma segura. Por nuestra parte, nos vamos a centrar en diseñar soluciones de seguridad para aplicaciones web y API que respondan a las reglas que hemos explicado a grandes rasgos. Estamos juntos en esto.
Si estás listo para saber más, echa un vistazo a los casos de uso de clientes que se muestran para cada regla en nuestro libro electrónico «Las nuevas reglas de seguridad para aplicaciones web y API».
