Todos a una: cuatro pasos para centralizar las herramientas de seguridad

Me llamaron la atención un par de datos, en apariencia contradictorios, de «El punto de inflexión de la seguridad en la web», el nuevo informe que publicamos la semana pasada en colaboración con ESG Research. Los encuestados afirman utilizar, en promedio, 11 herramientas de seguridad para API y aplicaciones web, pero el 93 % asegura que les interesa o tienen pensado adoptar un enfoque unificado en materia de herramientas de seguridad. El uso de tantas herramientas y, al mismo tiempo, el claro deseo de adoptar un enfoque unificado, dibujan un abismo que hay que salvar.

Lo entiendo perfectamente: cuesta ver que tienes 11 herramientas y pensar en reducir la deuda tecnológica y mejorar las prácticas y el stack de seguridad. Sin embargo, es más difícil todavía recuperarse de una violación de la seguridad de gran envergadura. 

Lo positivo es que no es necesario rehacerlo todo a la vez. Mi recomendación es centrarse en «demostrar» a medida que se revisa la seguridad, empezando con un proyecto pequeño. Por ejemplo, puedes aplicar Okta en toda la organización y demostrar que, aunque pueda haber una ralentización inicial, quedarse con la solución equivocada conlleva una ralentización permanente, además de un mayor riesgo de que algo salga mal. Una vez que tengas la aprobación general y que haya confianza entre el/la CEO o CFO y el/la CISO, repites el proceso. 

A continuación recomiendo cuatro pasos repetibles para ayudar a saldar la deuda tecnológica, aportar seguridad a tus API y aplicaciones y avanzar hacia un enfoque unificado en materia de herramientas de seguridad.

Aunque pueda haber una ralentización inicial, quedarse con la solución equivocada conlleva una ralentización permanente, además de un mayor riesgo de que algo salga mal.

1. Hacer un inventario

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, y según Statista, la utiliza el 42 % de las personas encuestadas. Por ejemplo, los desarrolladores quieren avanzar rápidamente en sus proyectos, así que es posible que no informen a los equipos de TI de nuevas API o instancias de AWS. Por mucho que cuentes con las herramientas de seguridad más sofisticadas del mercado, si un desarrollador lanza una API desconocida, no estará protegida.

Parte del problema es que trabajamos aislados. Es humano querer resolver un problema enseguida, pero no todas las herramientas que utiliza un desarrollador las ha creado o autorizado el departamento de seguridad. Para empezar, lo mejor es hacer un inventario y entender los flujos de trabajo de lanzamiento de software de tu organización. ¿Qué tienen en común en materia de tecnología o proceso? ¿Qué componentes sirven como puntos de centralización o tienen acceso a toda la actividad de IT? A partir de ahí, puedes trabajar con los responsables de ingeniería para identificar la mejor manera de tratar estas categorías de riesgo, en lugar de ir dando palos de ciego con una lista creciente de proveedores o herramientas específicas.

2. Asignar riesgos y priorizar

Una vez que tengas la lista de todo lo que necesitas que esté protegido, puedes asignar calificaciones de riesgo a cada elemento. En primer lugar, es esencial comprender qué servicios o herramientas son los más importantes para lograr lanzar software. ¿Qué garantiza que los servicios de producción sigan ofreciendo gran disponibilidad a los usuarios? ¿Qué componentes almacenan o procesan datos sensibles? ¿Qué herramientas tienen conexiones privilegiadas con otras herramientas o componentes? Básicamente, piensa en los elementos de tus sistemas de software que afectarían en mayor medida a la generación de ingresos y la distribución a tus usuarios.

Luego valora las vías más obvias de ataque a estos recursos tan importantes y sopesa cómo cortar de raíz esos accesos para dificultar la actividad de los atacantes. En este paso te puede resultar útil la lista de los 10 principales ataques según OWASP. Las tres principales amenazas para 2021 son los ataques por inyección, los ciclos de autenticación interrumpidos y la revelación de datos sensibles. A la hora de planificar la revisión general, lo lógico sería empezar con todo aquello que pueda estar expuesto a estas tres amenazas. 

Una vez que hayas asignado calificaciones de riesgo y hayas ordenado la lista por prioridad, ponte manos a la obra, empezando con tareas pequeñas y abordando gradualmente otras más ambiciosas. No intentes hacerlo todo a la vez; empieza en serie: optimiza o reemplaza algo y luego pasa a lo siguiente.

3. Implementar un DevOps seguro en paralelo

Mientras trabajas por estandarizar paso a paso tus prácticas y herramientas de seguridad, no pierdas de vistas los procesos. Si los desarrolladores realizan despliegues varias veces al día, no pueden esperar a que el personal de seguridad dé el visto bueno a cada nueva instancia. Así, en realidad, cuando hablamos de DevOps seguro nos referimos a integrar las herramientas en el producto: a medida que se desarrolla, también se somete a pruebas de seguridad sin que ello altere el rendimiento o la velocidad del proceso de desarrollo. 

Los equipos de desarrollo y de seguridad deben trabajar codo con codo para que cuando, por ejemplo, se cree una nueva API, se apliquen las políticas de seguridad. De este modo, el personal de seguridad puede ajustar la política ante nuevas amenazas o vulnerabilidades, y aplicarla a todo lo que se haya creado en esa API. 

Sin embargo, no se trata solamente de que tus equipos se comuniquen entre sí. La teoría de la defensa en profundidad se entiende bien, pero la práctica es más complicada: puedes contar con herramientas que protejan de manera efectiva contra amenazas concretas, pero si no se integran, estás en apuros. Se necesita visibilidad contra toda una gama de amenazas porque los atacantes prueban múltiples puntos para encontrar vulnerabilidades o formas de aprovecharse de las funcionalidades. Dentro del DevOps seguro también entra contar con una visión integral de tus amenazas y el tráfico en todo el panorama de desarrollo y seguridad.

4. Dar cera, pulir cera

Una vez que tengas tu nueva herramienta o práctica en marcha, ponla a prueba. Cuando llegue a producción, no dejes de probarla. La cuestión es que no puedes dejarla ahí y olvidarte de ella, porque el sueño de todo atacante es encontrarse con herramientas olvidadas o abandonadas que reducen las posibilidades de que los atrapen (o que se convierten en un punto cómodo desde el que persistir en sus ataques). El objetivo es ganar en confianza de forma continua y demostrable con cada solución, según su orden de prioridad para el negocio. Así, te aseguras el máximo retorno de la inversión y das a tus equipos herramientas fiables que usarán en sus flujos de trabajo porque ya las han probado repetidas veces. 

La tarea de rehacer el stack e incorporar soluciones de seguridad más unificadas puede parecer abrumadora, pero el retorno de la inversión vale la pena: reducción de puntos ciegos, reducción de falsos positivos, simplicidad, ahorro de costes y mucho más. Si nos centramos en «demostrar», las soluciones unificadas están al alcance de la mano.

Descarga el informe completo y obtendrás más información sobre cómo y por qué las herramientas de seguridad se encuentran en un punto de inflexión.