Buenas prácticas de DevSecOps

Las buenas prácticas de DevSecOps garantizan la implementación de la seguridad en el desarrollo de software y las operaciones de TI. Las organizaciones que siguen estas prácticas permiten a sus equipos trabajar de forma colaborativa, crear software más seguro y aumentar la velocidad de desarrollo.

En este post compartiremos nuestra selección de buenas prácticas de DevSecOps que puedes empezar a implementar o reforzar ahora mismo.

Adoptar una cultura y una mentalidad de DevSecOps significa que las personas de los equipos de desarrollo, operaciones y seguridad trabajan juntas para lanzar software seguro con rapidez. El objetivo de este cambio es permitir una comunicación fluida y el trabajo en equipo, fomentando así el sentido de propiedad y la responsabilidad.

La implementación de DevSecOps implica que cada desarrollador sea tan responsable de la seguridad del software como cualquier miembro del equipo de seguridad. Además, cada uno puede aumentar sus conocimientos de codificación segura corrigiendo los problemas detectados por las pruebas de seguridad continuas. El papel del equipo de seguridad es proporcionar entrenamiento, así como ayuda y orientación complementaria. Ya no lleva toda la carga de la seguridad sobre sus hombros.

Como ya hemos mencionado en nuestra serie de DevSecOps, la ciberseguridad comprende no solo la tecnología, sino también las personas. Los expertos en seguridad son responsables de implementar y supervisar las pruebas de seguridad para perfilar el riesgo cibernético, ofrecer soluciones y evaluar su eficacia. También son responsables de definir y cumplir las políticas de la organización. Una mentalidad de DevSecOps es aquella en la que todo el mundo es responsable de la seguridad.

Algunas de las cosas que puedes enseñar a tu equipo son las definiciones de ciberseguridad, el valor de la información, los mecanismos de control de acceso, la gestión de contraseñas, la ingeniería social, el malware, la informática segura y los mecanismos de seguridad física.

Los expertos en ingeniería de software que te pueden ayudar a llevar a cabo este método se conocen comúnmente como campeones de seguridad, que a veces tienen el cargo de ingenieros DevSecOps.

DevSecOps consiste en integrar la seguridad en cada parte de la ingeniería de sistemas de la información lo antes posible en el ciclo de vida de desarrollo de software (SDLC). Esto contrasta con la realización de pruebas de seguridad solo en las fases tradicionales de prueba y producción de software.

Para saber más sobre los retos y los impulsores de la implementación de DevSecOps, haz clic aquí.

La automatización de procesos es clave en la cultura de DevSecOps. Al automatizar las pruebas de seguridad, tienes la ventaja de acelerarlas para la entrega rápida de software; pero confiar solo en la automatización y no combinarla con la experiencia de los hackers éticos implica tener baja precisión, es decir, altas tasas de falsos positivos y falsos negativos. Las herramientas automatizadas deben ayudar a los expertos a hacer lo siguiente:

SAST analiza el código fuente de la aplicación. En una fase temprana del SDLC, estas pruebas pueden señalar la ubicación exacta de las vulnerabilidades. Son muy útiles para detectar problemas tales como los relacionados con la falta de validación de datos, que abren la posibilidad a un ataque por inyección de código.

DAST no requiere acceso al código fuente de la aplicación. Implica la evaluación de aplicaciones en ejecución mediante el envío de vectores de ataque a sus puntos finales. Estas pruebas pueden detectar vulnerabilidades en la configuración del despliegue de la aplicación, así como problemas de autenticación y de sesión, pero no pueden mostrarte la ubicación exacta de estos problemas de seguridad en el código.

Las herramientas SAST y DAST no son aconsejables por sí solas, ya que producen reportes con un alto número de falsos positivos y falsos negativos. Además, ninguna de estas herramientas puede encontrar problemas de control de acceso (el principal riesgo para las aplicaciones web en el último Top 10 de OWASP), mientras que las pruebas de seguridad manuales sí pueden hacerlo. Sigue leyendo para saber más sobre sus ventajas.

Desarrollar con rapidez significa no perder el tiempo reinventando la rueda. Por lo tanto, es normal que se utilicen dependencias externas a lo largo de la construcción de tu tecnología. De hecho, es posible que se utilicen hasta tal punto que probablemente no puedas recordar cada dependencia específica. Esto es un problema cuando ocurre algo importante, como el frenesí de explotación de las vulnerabilidades encontradas en la popular herramienta de registro Log4j, y de repente todos tienen que informarse sobre si utilizan o no la dependencia vulnerable en sus aplicaciones.

Para mitigar los riesgos que plantean las dependencias de código (especialmente los ataques a las cadenas de suministro), una buena práctica consiste en disponer de un inventario completo y actualizado de las dependencias que componen tu software y mantenerlas al día con los últimos parches. La respuesta a esta necesidad es SCA.

SCA requiere acceso a tu código fuente para revelar las dependencias externas del software. Así, este análisis puede informarte de las licencias de los componentes, versiones y vulnerabilidades de seguridad, en caso de que las haya. Al realizar SCA combinando trabajo automático y manual, no existen limitaciones debidas al lenguaje de codificación, ni se limita el análisis a las vulnerabilidades comúnmente conocidas.

Ya que las amenazas evolucionan continuamente, las organizaciones necesitan evaluar a fondo sus sistemas para comprobar si cumplen las buenas prácticas, las normas internacionales y los reglamentos nacionales. Como es de esperar con este alcance, la evaluación no se limita a comprobar si el software en uso tiene el último parche. Una auditoría de seguridad incluye evaluar la integridad de los componentes físicos de los sistemas, la seguridad de la red y el comportamiento de los empleados.

Recomendamos auditorías de seguridad continuas en lugar de periódicas, ya que estas últimas podrían permitir una ventana de tiempo durante la cual se podría aprovechar la exposición al riesgo. Si actualizas tus conocimientos sobre los puntos débiles de seguridad de tus sistemas, se podrá supervisar constantemente el cumplimiento de la normativa. Remediando esos problemas, es posible dotar a tus sistemas de una protección más adecuada frente a los ciberataques.

Te recomendamos que cuentes con expertos que evalúen tus sistemas de forma continua con técnicas como el pentesting manual. Estas implican el trabajo de hackers éticos que exploran el sistema para explotar vulnerabilidades y evadir las defensas o revisar el código manualmente (en Fluid Attacks, se ayudan de la priorización por IA), entre otras cosas, dependiendo de la fase del SDLC en la que se realicen las pruebas. Estos expertos están al día en las tácticas utilizadas por los atacantes y tienen la capacidad de comprobar el nivel de seguridad de tu tecnología frente a ataques especialmente diseñados para ella.

Dado que los reportes de seguridad basados en escaneos realizados con herramientas automatizadas tienen altas tasas de falsos positivos y falsos negativos, valoramos inmensamente el trabajo manual realizado por los expertos. Para que te hagas una idea, nuestros análisis de las pruebas de seguridad realizadas el año pasado en los sistemas de nuestros clientes muestran que el 67,4% de la exposición al riesgo se reportó solo con métodos manuales. Por ello, sostenemos que las pruebas de penetración son un componente valioso en favor de la precisión y la profundidad.

En pocas palabras, aconsejamos pruebas de penetración continuas para validar la seguridad de tu tecnología y probar contra nuevas técnicas utilizadas por los atacantes. Esto contrasta con el consejo común de realizar solo pruebas de penetración periódicas con el fin de cumplir las regulaciones, entre otros motivos. Las evaluaciones continuas apoyan una sólida cultura de remediación, que va más allá de las obligaciones periódicas.

Es recomendable impedir el despliegue de un sistema si se detecta una vulnerabilidad en él. En nuestro informe State of Attacks 2022, reportamos que a los clientes que activaron nuestra función para romper el build les llevó casi 30% menos de tiempo remediar las vulnerabilidades de sus sistemas que a los que no la activaron. Esto es automático y responde a las políticas de la organización que establecen qué tan severa debe ser una vulnerabilidad para que rompa el build, el periodo de gracia antes de que una nueva vulnerabilidad reportada rompa el build, etc. Con este ejemplo, puedes ver que vale la pena automatizar herramientas y procesos.

En Fluid Attacks somos especialistas en pruebas de seguridad a lo largo de todo el SDLC, combinando herramientas automatizadas y pruebas de seguridad manuales. Nuestro plan Essential de Hacking Continuo te permite encontrar vulnerabilidades de software a través de SAST, DAST y SCA con gran precisión mientras desarrollas. Si te cambias a plan Advanced, puedes contar con nuestros hackers éticos para encontrar vulnerabilidades complejas y más severas con técnicas manuales y aconsejarte sobre cómo remediarlas.

Utilizando Hacking Continuo, puedes hacer uso de nuestro agente DevSecOps, el componente que romperá el build de acuerdo con las políticas de tu organización. Así te damos los medios para comprometerte plenamente con el desarrollo de software seguro con rapidez.

¿Quieres probar plan Essential de Hacking Continuo? Pulsa aquí para disfrutar de una prueba gratuita de 21 días. Contáctanos si deseas más información. Estaremos encantados de responder a todas tus preguntas sobre DevSecOps.