¿Por qué ya no funcionan tus herramientas de seguridad?
Con un Internet cada vez más complejo, más descentralizado y más impulsado por API, los profesionales de IT y seguridad no pueden evitar preguntarse: ¿por qué las herramientas de seguridad que servían hace unos años ya no están a la altura?
Hace tiempo que sabemos que esto no es ninguna exageración, sino que está demostrado por investigaciones recientes. «El punto de inflexión de la seguridad en la web», un nuevo informe que publicamos la semana pasada en colaboración con Enterprise Strategy Group (ESG) Research, desvela que, para nada menos que la mitad de las organizaciones encuestadas, la seguridad de las API y aplicaciones web es más compleja hoy de lo que lo era hace tan solo dos años. Por si fuera poco:
El 82 % de las organizaciones admitieron haber sufrido ataques con éxito contra sus API y aplicaciones web el año anterior.
El 64 % prevé que la mayoría o la totalidad de sus aplicaciones utilicen API, pero les inquieta cada vez más que los puntos de conexión sufran vulnerabilidades, ataques de malware y filtración de datos.
El 45 % de las alertas resultan ser falsos positivos, lo cual señalan como problemático nueve de cada diez encuestados.
El 75 % de las organizaciones dedican tanto o más tiempo a los falsos positivos que a los ataques reales.
Entonces, ¿qué pasa? ¿Las herramientas se han quedado obsoletas? ¿Los atacantes son más listos que los equipos de seguridad? Hay varias razones por las que las herramientas de seguridad en las que invertiste hace solo unos años ya no dan la talla.
La innovación avanza a gran velocidad
Nos movemos más rápido que nunca, y parte de ello se debe a la proliferación de las API. Las herramientas de seguridad antiguas se crearon para proteger las aplicaciones web que se comunican con una base de datos. Sin embargo, hoy en día las API contienen mucha lógica, por lo que las aplicaciones se comunican directamente con ellas en lugar de con la base de datos.
Tradicionalmente, los equipos de seguridad se han mantenido fuera de los flujos de trabajo de lanzamiento de software, de modo que no conocen tan de primera mano las nuevas tecnologías que utiliza el personal de ingeniería para crear y hacer funcionar aplicaciones y servicios. Por ejemplo, puede que desconozcan las nuevas tecnologías para API, como GraphQL, y que no entiendan por qué razón las herramientas actuales que se centran en REST serán deficientes para GraphQL. Además, como los equipos suelen mantenerse aislados, apenas se produce intercambio de conocimiento. Necesitamos un enfoque más centralizado que garantice la integración de los flujos de trabajo y los procesos.
No se puede proteger lo que no se ve
Se denomina «IT en la sombra» a la tecnología no aprobada por el departamento de IT. Según Statista, el 42 % de las personas encuestadas afirma utilizarla. Por ejemplo, con el objetivo de saltarse la cola de aprobación y trabajar más rápidamente, los desarrolladores pueden no informar a los equipos de IT de cada nueva API que crean para obtener su necesaria autorización, autenticación, protección contra vulnerabilidades, etc. Una empresa puede terminar con 20 API distintas, cada una con una forma diferente de protección (sin ir más lejos, las herramientas creadas para REST no ofrecen compatibilidad directa con GraphQL), y los atacantes solo tienen que probar cada una para ver cuál es más vulnerable.
Además, la mayoría de las herramientas de seguridad antiguas se crearon para aplicaciones web monolíticas, no para API. Por tanto, no solo se necesitan procesos más estandarizados; también hacen falta herramientas creadas para nuevas arquitecturas y nuevos tipos de API. Todo esto se agrava por la falta de estandarización y, en muchos casos, la falta de patrones de autenticación ampliamente verificados y utilizados por todos los equipos.
Las herramientas no se comunican entre sí
Por mucho tiempo que pasemos reforzando la tecnología y la seguridad, la cuestión es que se comuniquen entre sí y te ofrezcan una visión integral del tráfico y las vulnerabilidades.
Al fin y al cabo, las herramientas tienen que integrarse en tu flujo de trabajo, no al revés. Por ejemplo, tu WAF debería desencadenar un mensaje de Slack, un ticket en JIRA y una notificación en PagerDuty. Debería enviar la información a una herramienta centralizada de análisis de datos, donde se pueda correlacionar con otros datos. Si quieres tener una visión integral del tráfico, no puede haber datos aislados en un panel, a partir de los cuales tú tengas que sacar conclusiones prácticas. Al integrarlo con tus otras herramientas y flujos de trabajo, puedes obtener una visión exhaustiva de tu superficie de ataque sistémica y de las amenazas que puedan surgir. Por ejemplo, dos alertas de dos herramientas distintas pueden no significar nada si se examinan en momentos o en contextos diferentes, pero cuando se correlacionan en un sistema central, sí que se puede establecer un vínculo, lo cual facilita mucho la detección.
En conclusión
Hay un denominador común en todas estas razones por las que las herramientas de seguridad parecen menos efectivas hoy que hace dos años: el aislamiento. Las herramientas no se comunican entre sí, los equipos se mantienen aislados y, en lugar de aprovechar los puntos fuertes de cada parte, las organizaciones compran más herramientas, lo que no hace más que empeorar el problema.
Necesitamos herramientas sólidas e integradas que funcionen para todos los equipos. Sin embargo, es complicado llegar a ese punto, y es que necesitamos entender los flujos de trabajo de cada uno y asegurarnos de que las herramientas que usamos encajen en ellos. Las organizaciones deben ponerse como prioridad actualizar y afianzar los procesos y los stacks de seguridad. Si no, se irá acumulando la complejidad y cada vez será más probable que algo salga mal.
Descarga el informe completo para ahondar en el tema.
