De qué manera se enfrenta la Seguridad como Código (Security as Code) a los nuevos desafíos de DevSecOps

La seguridad como código (Security as Code) es una fuerza motriz en la evolución actual de la seguridad de las aplicaciones. Va de la mano del desarrollo de software moderno y el auge de la infraestructura como código (Infrastructure As Code) o «IaC» por sus siglas en inglés, y también está ayudando a las organizaciones con mentalidad innovadora a abordar y lidiar mejor con el mayor reto de seguridad visto en años.

La metodología DevOps ha roto con éxito las barreras entre Dev (desarrollo) y Ops (operaciones) y la nube ha ayudado a permitir que los desarrolladores codifiquen rápidamente. La infraestructura necesaria para alojar el código en la nube se puede configurar fácilmente. Sin embargo, es este paso de configuración el que suele exponer ocasiones de errores y vulnerabilidades de seguridad más adelante. Para eliminar los pasos manuales y mejorar la consistencia y la seguridad del software, estas configuraciones se codifican como IaC, es decir, infraestructura como código.

La IaC permite la escala, la velocidad, la consistencia, la visibilidad y la trazabilidad de los cambios realizados en cada configuración. El reto son los muchos elementos diferentes de los que los equipos de DevOps y seguridad de la organización se deben ocupar. Con los ajustes de configuración integrados en diferentes servicios en la nube, en contenedores, orquestadores y en herramientas de creación e implementación de software, a menudo es difícil para los equipos de desarrollo y seguridad confiar en una configuración general adecuada.

Mediante la automatización, estas diferentes directrices pueden configurarse de forma centralizada y aplicarse sistemáticamente a todos los proyectos. Esta innovación elimina la dependencia de la toma de decisiones individuales (y su claro potencial de error), pero al hacerlo, crea un objetivo centralizado para cualquiera que quiera inyectar configuraciones maliciosas. Ahí radica el peligro.

La configuración puede estar automatizada, ser repetible y seguir los estándares o, puede ser un caos de elementos únicos creados sin comprender completamente el impacto de cada elección. De cualquier manera, la seguridad se debe tener en cuenta de cara al hardware, las aplicaciones y la infraestructura de la que dependen las aplicaciones a medida que se desarrollan, implementan y usan. Con la configuración codificada como IaC, se tratará ESE código con el mismo rigor con el que se trataría el código de una aplicación.

El catalizador aquí es la automatización y cómo se acelerará el tiempo de uso del software.

Debido a que la IaC está automatizada, por su propia naturaleza sucede casi instantáneamente. Ahora sus equipos pueden llevar a producción tanto la infraestructura como el código en un solo paso. Pero si no es seguro, las vulnerabilidades pueden extenderse con el código sin apenas tiempo para comprobar la integridad de la configuración. Este hecho requiere la automatización de los controles de seguridad y la necesidad de incorporarlos en los procesos de ensamblaje e implementación del software, en lugar de que existan como esfuerzos separados que deben ser gestionados por equipos de seguridad independientes. Así que, al final, la IaC genera seguridad como código.

IaC: nuevas ideas para la seguridad del software

El ataque a Solarwinds hizo que los ejecutivos, los profesionales de la seguridad y los desarrolladores de todo el mundo se detuvieran y reflexionaran sobre la seguridad de las fábricas de software de sus organizaciones. El ataque puso de relieve un claro fracaso en la protección del Ciclo Vital del Desarrollo de Sistemas, o SDLC por sus siglas en inglés.
En el exploit los hackers desplegaron un código malicioso en el software de monitorización y gestión de Solarwinds Orion, utilizado por miles de empresas y agencias gubernamentales en todo el mundo. SolarWinds envió entonces, sin saberlo, unas actualizaciones de software a sus clientes que incluían el código pirateado. Inyectado durante el proceso de construcción de la aplicación Orion, el código creó una puerta trasera a los sistemas informáticos de los clientes de SolarWinds, proporcionando acceso con fines maliciosos.

Europa se enfrenta a retos similares y crecientes. La investigación sobre amenazas publicada esta semana por la Agencia Europea de Ciberseguridad (ENISA) calcula que en 2021 habrá cuatro veces más ataques a la cadena de suministro que el año pasado.

Los ataques más dañinos tienden a basarse en actitudes internas poco atentas con la seguridad (como parches no completados o contraseñas que no se cambian regularmente) y usan exploits conocidos que han existido durante años. Según la cobertura mediática del incidente, la administración de Solarwinds confió en una simple contraseña y no la cambió Pasar a procesos automatizados podría garantizar la rotación periódica de las contraseñas, mientras que la detección de secretos puede buscar de forma rigurosa las contraseñas codificadas, especialmente frecuentes en las API que conectan diferentes aplicaciones.

Como resultado del ataque a SolarWinds, seguido por el también notorio ataque al gasoducto Colonial, el presidente Biden emitió una Orden Ejecutiva para la ciberseguridad. Todas las personas en la comunidad del software deben tomar nota, ya que esta intervención podría desencadenar un nivel de esfuerzo en la gobernanza, las pruebas y la seguridad que no se ha visto desde la planificación del efecto 2000, en la que se inspeccionó cada aplicación para ver cómo manejaba las variables de fecha, y muchas requirieron un rediseño. Este nuevo enfoque en asegurar la cadena de suministro de software promete un nivel similar de introspección.

¿Por dónde empezar la gobernanza y las pruebas de seguridad?
Afortunadamente, hay pasos clave que su organización puede dar, y como consecuencia, esta automatización acelerará el tiempo de entrega de su software.

Deberá pensar y detallar los procesos y las políticas para cada paso. A medida que defina las políticas, debe considerar una serie de nuevas preguntas. Por ejemplo, hasta qué punto prueba el código fuente. ¿En todas las aplicaciones? ¿Cuáles son las excepciones? ¿Quién puede aprobar excepciones? ¿Prueba sus contenedores? ¿Cuándo? ¿Quién lo hace? ¿Quién tiene acceso a su fábrica de software? ¿Qué se les permite cambiar?

Es útil dividir el esfuerzo de seguridad del software y los recursos en tres áreas principales:

• Entregar un código más seguro: pruebe el código que cree para identificar y eliminar los riesgos de vulnerabilidad. Determine las directrices según los análisis que se utilicen y el ámbito de su cartera de aplicaciones. Lo ideal sería ejecutar varios tipos de análisis, en las etapas de confirmación del código y de fusión con la rama principal. Considere las herramientas que tienen todos estos análisis incorporados para eliminar la gestión de una compleja integración de la cadena de herramientas. A continuación, determine las directrices para las acciones requeridas cuando se identifiquen las vulnerabilidades.

• Proteger la infraestructura circundante de la aplicación: pruebe si hay errores de configuración y controle los cambios imprevistos. Tenga en cuenta:
1. Contenedores: qué hay en ellos (bibliotecas y dependencias).
2. Orquestadores (por ejemplo, Kubernetes): configurados para dirigir cómo, dónde y cuándo se ejecutan los contenedores, controlando qué aplicaciones pueden comunicarse entre sí y qué recursos de computación y almacenamiento puede consumir cada aplicación.
3. Servicios en la nube: el entorno que aloja máquinas virtuales y contenedores.
4. IaC (configuraciones codificadas) como APIs, paquetes, gráficos Helm, Terraform, etc. A medida que las aplicaciones monolíticas se dividen cada vez más en microservicios, la autenticación y la autorización adquieren una dimensión completamente nueva, y adoptan un mayor uso de las API. Debe probarlas e, idealmente, capturar, almacenar y visualizar todas las llamadas a la API para fines de auditoría de su organización.

• Asegurar la propia fábrica de software: proteja la fábrica de software contra intervenciones maliciosas. La canalización de CI es esencialmente su línea de ensamblaje de software, por lo que gestionar el acceso, ya sea por medios humanos, de máquina o API, es fundamental.

Aplicar los principios de Confianza Cero a este trabajo. Este enfoque incluirá elementos como garantizar el acceso con privilegios mínimos a su cadena de herramientas DevOps y a la infraestructura de la aplicación. Además, deberá recopilar un inventario de elementos de infraestructura como registros, administradores de paquetes, etc., y evaluar los diferentes niveles de acceso permitidos. La Gestión de Accesos debe considerar este nuevo y más amplio alcance.

Una canalización automatizada de CI/CD tiene la ventaja de aplicar sistemáticamente controles comunes adicionales para el cumplimiento, como la separación de tareas, las aprobaciones de fusiones, etc. Estas capacidades, a su vez, también simplificarán las auditorías de seguridad internas.

La seguridad como código puede acelerar DevSecOps

Las aplicaciones de software modernas requieren los últimos métodos de seguridad de aplicaciones, incluso más allá del desplazamiento a la izquierda. A medida que se aceleran los ciclos de desarrollo, la seguridad como código se vuelve primordial. Este cambio trae beneficios adicionales que no son posibles con los métodos tradicionales más aislados: velocidad, visibilidad del riesgo, control. Las estrategias de seguridad como código permiten a las organizaciones comenzar a prepararse ahora para esta evolución de la seguridad de las aplicaciones al integrar realmente la seguridad en su fábrica de software de extremo a extremo.