La mayoría de las herramientas de seguridad de webapps y APIs fueron diseñadas para una época muy distinta. Antes de que los desarrolladores y los responsables de seguridad trabajaran juntos para crear software seguro gracias a flujos de trabajo integrados. Una época en la que las aplicaciones todavía no se distribuían de forma global y se basaban en APIs. Un tiempo en el que los ingenieros no podían introducir un comando y hacer una actualización global de forma instantánea.

No debemos olvidar que, como a nuestro CEO Joshua Bixby le gusta decir, «los atacantes son desarrolladores también». Y los atacantes no se ven frenados por las limitaciones de las soluciones heredadas. Son tan hábiles como siempre y emplean herramientas de desarrollo y flujos de trabajo modernos para construir y ampliar las amenazas que crean. Nunca ha sido más evidente la necesidad de un cambio. Por eso es un buen momento para enumerar las reglas que deben tenerse en cuenta para desarrollar aplicaciones web y asegurar la seguridad de las APIs que estén alineadas con la forma en la que se construyen las aplicaciones modernas.

Regla N.1: Las herramientas deben defenderse de las intenciones, no de amenazas concretas

Los equipos de seguridad se han centrado durante mucho tiempo en la lucha contra amenazas específicas. Cuando evalúan nuevas herramientas, se preguntan: «¿Puede esto protegerme contra el peligro X?». Esas amenazas son a menudo grandes acontecimientos como Stuxnet, o el más reciente ataque a SolarWinds. Este estilo de evaluación lleva a los profesionales a herramientas que buscan firmas o «indicadores de compromiso» (IoC, Indicators of Compromise) de una amenaza concreta. Los IoCs incluyen cosas como las direcciones IP de atacantes conocidos y expresiones regulares que coinciden con una URL de solicitud particular a la que se dirige el malware.

Lo que no hacen bien las herramientas basadas en firmas es diferenciar entre el tráfico legítimo y el malicioso, ni seguir el ritmo del incesante aumento de las amenazas. ¿Y cómo podrían hacerlo? Informes recientes indican que se crean más de 350.000 nuevas variantes de malware al día.

Sabemos que este modelo no funciona. Lo hemos visto fracasar con los proveedores de antivirus que no podían proteger contra las amenazas, los proveedores de WAF heredados que sólo buscan inyecciones SQL o scripts entre sitios, y las herramientas de mitigación de bots que sólo miran el agente de usuario de los navegadores solicitantes.

Las nuevas reglas para la seguridad de webapps y APIs exigen un cambio hacia un modelo más inteligente, que infunda la suficiente confianza en la cadena de herramientas de seguridad como para que un profesional pueda gestionar con seguridad el sistema frente al tráfico valioso sin temor a que bloquee los intentos legítimos o deje pasar los maliciosos.

En segundo lugar, los responsables de crear soluciones deben exigir que las herramientas puedan ejecutarse no sólo en modo de supervisión, sino también en modo de bloqueo. Las herramientas que sólo pueden ejecutarse en modo de monitorización por miedo a los falsos positivos refuerzan un sistema roto: el daño está hecho para cuando el equipo puede responder. Imagínese a un superhéroe que se para en una esquina de la calle gritando que se están produciento delitos (¡estafas! ¡robos!) y luego espera a que se produzca la respuesta de las fuerzas del orden en lugar de arremangarse y actuar en el momento.

Ahora mismo los equipos de seguridad y operaciones se están ahogando en alertas. Aunque siempre serán necesarias la detección y la respuesta (a las que nos referiremos más adelante cuando abordemos la visibilidad y el control), los equipos necesitan una base de herramientas que puedan bloquear con confianza las amenazas en el momento en que se producen, no limitarse a diagnosticar el problema después de la infracción.

Por último, las herramientas deben mantenerse al día con las amenazas modernas sin suponer una carga para los equipos de seguridad y operaciones. Con las modernas soluciones de nube y SaaS, se obtiene todo el peso de un equipo de seguridad de producto que se adelanta a las amenazas y proporciona actualizaciones de forma proactiva. No hará falta preocuparse por los parches ni obsesionarse con las últimas amenazas.

Regla N.2: No existe la seguridad si no es fácil de usar

El aumento de las experiencias web intuitivas similares a las del consumidor en las herramientas basadas en SaaS ha hecho que la usabilidad sea casi una apuesta segura para la mayoría de las herramientas tecnológicas. Sin embargo, las soluciones de seguridad están lamentablemente rezagadas. Las herramientas heredadas se diseñaron para imponer y controlar, no para ser utilizadas. Pero los equipos modernos esperan tener una relación con sus herramientas. Necesitan la capacidad de integrar, observar y actuar.

La interfaz de usuario es la primera línea de defensa de un operador. Por desgracia, también es el primer lugar donde se descuida la usabilidad. Las interfaces de usuario heredadas pueden ser lentas y toscas. Y los operadores a menudo tienen que iniciar sesión en varias interfaces de usuario para gestionar el sistema, incluso cuando utilizan soluciones del mismo proveedor. Una interfaz de usuario deficiente crea multitud de riesgos: lagunas en las políticas y en la aplicación de las herramientas, una respuesta lenta y descoordinada a las amenazas urgentes, y una visibilidad inconsistente -o peor aún, ausente- del ecosistema de seguridad integral.

Una solución de seguridad debe tener una interfaz única, intuitiva y fácil de usar que permita el control y la visibilidad de toda la herramienta. La capacidad de observación debe ser global e integrada para proporcionar una visibilidad completa del estado del sistema de un vistazo. Y, lo que es más importante, estas soluciones deben poder ser utilizadas por los equipos de seguridad y por el resto de equipos, ya que así se capacita a más personas de los departamentos de operaciones e ingeniería en la lucha contra las amenazas.

Y llegamos a otra regla básica para la seguridad de webapps y APIs, que las herramientas modernas deben coincidir con el diseño moderno de las aplicaciones. Con demasiada frecuencia, los conjuntos de herramientas son simplemente empaquetados y vendidos juntos por un proveedor, pero no son realmente capaces de integrarse técnicamente. Un amigo mío llama a esto «integración por factura». Aunque un sistema solo requiera cambiar de pestaña para navegar por las funcionalidades, ya estaremos perdiendo valiosos segundos y visibilidad integrada si tenemos que movernos así durante un ataque.

Este enfoque debilita el planteamiengo global de seguridad al crear brechas técnicas y de visibilidad. Los proveedores deben esperar la automatización y la integración por defecto, que comienza con el control total de la API. Todas las soluciones de seguridad deben tener APIs fáciles de usar que expongan toda la funcionalidad del sistema. Las soluciones deberían integrarse fácilmente no sólo entre sí, sino con toda la cadena de herramientas de respuesta, incluidas herramientas como Jira, PagerDuty, Slack y Splunk. Y deben ofrecer registros y estadísticas en tiempo real que expongan los datos en cualquier sistema de supervisión de la seguridad o de observabilidad que utilice el equipo. La capacidad de integrar todas las soluciones hace que sea mucho más fácil determinar la verdadera intención del atacante.

Regla N.3: Los ataques en tiempo real exigen respuestas en tiempo real

El malware es un sistema de software. Los sistemas de software son construidos por desarrolladores. Por tanto, los atacantes son desarrolladores. Comprender esto hace que sea mucho más fácil entender por qué las amenazas están superando los modelos de seguridad tradicionales. Los atacantes ágiles emplean flujos de trabajo DevOps avanzados para intentar, ajustar y desplegar rápidamente nuevos métodos. Esto puede ocurrir cientos de veces durante un solo ataque. ¿Cómo puede proteger sus aplicaciones si no puede reaccionar con la misma velocidad? Para ser claros: el tiempo de reacción no está limitado por la rapidez con la que funciona tu cerebro. Depende de la velocidad de sus soluciones de seguridad. Vamos a dividir los detalles de esta tercera regla de seguridad de webapps y APIs en dos bloques: velocidad de visibilidad y velocidad de control.

Velocidad de visualización

Si se tarda minutos u horas en detectar un ataque, ya es demasiado tarde. Los atacantes hacen un intento y, si falla, intentan otro. Todo esto sucede en el lapso de minutos. Para cuando una solución de seguridad es 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 la lógica en tiempo real para el examen de las amenazas, y proporciona a los operadores la capacidad de reaccionar ante las alertas que requieren la intervención humana. En ambos casos, la visibilidad debe ir de la mano del control.

Velocidad de control

Una vez que los técnicos o el sistema pueden ver la amenaza, la velocidad de respuesta o reparación es fundamental. El enfoque más inteligente de la mitigación, basado en la intención, requiere disponer de múltiples flujos de datos para tomar una decisión. Los sistemas basados en la intención funcionan como sistemas de autoaprendizaje y autorreparación. Analizan constantemente patrones y comportamientos para predecir amenazas nuevas o en evolución, por lo que es imperativo que no sólo puedan ver e interpretar el tráfico en tiempo real, sino que también tengan la capacidad de desplegar nuevas reglas en respuesta a las amenazas cambiantes.

Vale la pena señalar que la velocidad de visibilidad y control no puede limitarse a un único despliegue o geografía. La prevalencia de los sistemas distribuidos (ya sean despliegues multirregionales y multi-nube, o una fuerza de trabajo distribuida que necesita ser protegida) requiere la capacidad de tomar medidas a través de ubicaciones físicas o fronteras. Hemos visto algunas soluciones de seguridad que son rápidas siempre que la detección y la protección se realicen en una sola ubicación. El mundo ya no funciona así: el software y las personas se despliegan por todo el mundo y la seguridad debe seguir ese ritmo.

Regla N.4: Dev, Sec u Ops, todos deben pensar como un ingeniero

Juntos, hemos observado la evolución desde equipos aislados que trabajaban de forma independiente (y dolorosa) para distribuir el software hasta la unificación de la seguridad, la ingeniería y las operaciones a través del modelo Secure DevOps. Pero estamos lejos de colgar el cartel de misión cumplida. Aunque muchos líderes 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 herramientas anticuadas siguen frenando a los equipos.

Una limitación notable se da cuando el DevSecOps es más una pirueta técnica que una auténtica integración. Añadir operadores de seguridad y sus herramientas preferidas al final de un canal de despliegue no significa que se esté haciendo DevSecOps, y no hará que el software se entregue más rápido. El verdadero DevSecOps incorpora la verificación de la seguridad y la exploración de vulnerabilidades directamente en los marcos de pruebas y despliegues automatizados. Proporciona una vía para que los equipos de seguridad se muestren como una parte integrada del equipo de desarrollo, no como un añadido sumado en el último minuto para presentar una lista de vulnerabilidades y esperar que se arreglen antes de que el sistema salga a la luz.

A su vez, los desarrolladores escriben el código utilizando prácticas de desarrollo seguras y los flujos automatizados de CI/CD comprueban no sólo la funcionalidad, sino los agujeros de seguridad más comunes. Por último, el equipo de seguridad tiene las habilidades y la autoridad para emplear auditorías de seguridad en profundidad en caso de que el sistema automatizado pase por alto algo.

Para que el paradigma DevSecOps esté a la altura de lo que promete, los profesionales de la seguridad, los de operaciones y los desarrolladores deben adoptar una mentalidad de ingeniería centrada en el envío de software seguro. La cuarta regla para conseguir la seguridad de webapps y APIs consiste en eliminar el trabajo de gestión de productos y capacidades de seguridad para que los profesionales de la seguridad puedan pasar de operadores a ingenieros. Esto no sólo hace que el sistema en general sea más fiable y seguro, sino que ofrece a los empleados una trayectoria profesional más satisfactoria.