Guía: Cómo implementar DevSecOps

Aprende con Fluid Attacks a adoptar esta cultura

Blog Guía: Cómo implementar DevSecOps

| 13 min de lectura

Contáctanos

En pocas palabras, la implementación de DevSecOps en tu empresa requiere una transformación radical en los modos de pensar y actuar en materia de seguridad y en cómo esta se integra en los procesos de desarrollo y lanzamiento de software. Antes de entrar en detalle sobre los principios, retos y técnicas o prácticas recomendadas para esta implementación, definamos brevemente el concepto DevSecOps, del cual ya hicimos una introducción más extensa en un post anterior.

¿Qué es la metodología DevSecOps?

Cuando hablamos de DevSecOps, nos referimos no solo a una metodología, sino a una cultura en expansión entre las compañías de desarrollo tecnológico en la que la seguridad se introduce y se aborda desde el principio para mantenerse a lo largo del ciclo de vida de desarrollo de software (SDLC). En DevSecOps, como parte de una evolución del modelo anterior (DevOps), el equipo de seguridad se integra en una colaboración entre los equipos de desarrollo y operaciones. DevOps se centraba en entregar al mercado un producto de excelente calidad a gran velocidad. Ahora, DevSecOps conserva ese objetivo, pero añade el propósito de garantizar que el producto sea seguro. Con esta cultura corporativa, la seguridad se convierte en una responsabilidad compartida por todos los miembros de una organización.

Descripción general de la implementación de DevSecOps

Implementar DevSecOps es desplazar la seguridad hacia la izquierda. Es integrarla en el proceso de desarrollo tecnológico antes de que aparezca la primera línea de código. Adoptar DevSecOps es introducir en el SDLC requisitos y pruebas de seguridad, priorización y remediación de vulnerabilidades y seguimiento riguroso para la prevención de riesgos y el ahorro de costos. A diferencia de las metodologías anteriores, la identificación y corrección de los problemas de seguridad se producen al mismo tiempo que la actividad de desarrollo, sin esperar al final de cada ciclo. En DevSecOps, la seguridad actúa en la planificación, diseño, construcción, pruebas y lanzamiento del software, proporcionando retroalimentación continua a todos los equipos comprometidos.

Componentes fundamentales de DevSecOps

La implementación de DevSecOps se basa en cuatro componentes fundamentales: personas, procesos, tecnologías y gobernanza.

En primer lugar, están las personas, es decir, los miembros del equipo, quienes se integrarán para cooperar. Son ellos quienes, como parte del cambio cultural, asumirán la responsabilidad compartida de la seguridad en sus flujos de trabajo. Son ellos quienes formarán y recibirán formación para que la seguridad se incorpore al ADN corporativo.

En cuanto a los procesos, el modelo de responsabilidad compartida exige que todas las partes interesadas mantengan los objetivos generales de velocidad, seguridad y estabilidad del software. Por lo tanto, las mejores prácticas en seguridad, desarrollo y operaciones deben adoptarse desde el principio y a lo largo de todo el SDLC.

Para lograr lo anterior, el apoyo que prestan las tecnologías es crucial. Estas se integran en los ciclos y facilitan muchos procesos. Las pruebas de seguridad con herramientas automatizadas, por ejemplo, que complementan las pruebas de seguridad manuales realizadas por expertos, son valiosas en la cultura DevSecOps. Sin embargo, la automatización debe utilizarse cuando sea necesaria y no en exceso para que no afecte a la efectividad del desarrollo y el despliegue de software.

Por último, DevSecOps debe incluir la gobernanza. Las empresas deben supervisar sus procedimientos, medir su rendimiento, identificar y analizar sus obstáculos, fallas y progresos, definir desafíos y aprender y mejorar con la ayuda de la retroalimentación. Las métricas obtenidas a lo largo de la evolución de DevSecOps de una organización son bastante útiles para la toma de decisiones de gobernanza.

Principios o pasos básicos de DevSecOps

En relación a estos elementos, los siguientes son algunos principios o pasos básicos en la implementación de DevSecOps dentro de una organización:

  • Fomentar un cambio cultural gradual.

  • Educar, formar y certificar al personal en distintos roles respecto a la seguridad y sus buenas prácticas.

  • Elegir en qué puntos del SDLC realizar procedimientos de seguridad específicos.

  • Automatizar procesos (incluida parte de la gobernanza) y herramientas para lograr estabilidad y repetición en las distintas fases de los ciclos.

  • Comenzar evaluando pequeñas porciones de código o casos específicos y prioritarios.

  • Realizar intervenciones manuales continuas para reexaminar y profundizar.

  • Utilizar métricas para medir el rendimiento y el progreso, y aprender de la retroalimentación.

Impulsores de la adopción de DevSecOps

La popularidad de la metodología DevOps ha ido en aumento en los últimos años debido a la agilidad que aporta al desarrollo y lanzamiento de software. En el caso de la metodología DevSecOps, su creciente popularidad se debe a su inteligente —increíblemente aún no considerada necesaria por algunos— inclusión de la seguridad en el enfoque precedente sin afectar negativamente a su eficiencia. Fue prudente responder a los problemas de seguridad que surgen en la entrega acelerada de tecnología. Afortunadamente, cada vez más organizaciones perciben la seguridad como una necesidad en un ambiente plagado de personas inescrupulosas que desean aprovecharse de la ignorancia y los errores humanos a través de diferentes métodos.

DevSecOps resulta atractivo porque permite prevenir constantemente los riesgos y mitigar las amenazas que sin duda surgen en el desarrollo de software. También, porque la detección temprana de vulnerabilidades permite su remediación antes de pasar a producción y a menores costos. Gracias a la implementación de DevSecOps, las organizaciones pueden evitar cuellos de botella con evaluaciones de última hora y la interrupción de la rápida entrega de tecnología, la cual puede incluso mejorar. Además, pueden fomentar la transparencia, generar confianza, mantener una excelente reputación e incluso aumentar sus ingresos con la ayuda de un personal fielmente comprometido con la seguridad.

Retos de la adopción de DevSecOps

No obstante, las organizaciones también pueden enfrentarse a retos a la hora de adoptar la cultura DevSecOps. Uno de los obstáculos más mencionados es la resistencia interna al cambio. Realinear o redefinir los modus operandi y las mentalidades arraigadas de las personas no suele ser pan comido. Los equipos de desarrollo y operaciones pueden ver al equipo de seguridad como un obstáculo para la rápida presentación de resultados. Puede que se hayan acostumbrado a verlo como un equipo con prioridades diferentes, que antes trabajaba en un silo e incluso como un complemento en fases posteriores del SDLC, que no debería interrumpir su flujo de trabajo. Al fin y al cabo, pueden creer que la seguridad es sinónimo de ralentización, estancamiento e incluso limitación de la creatividad.

La falta de conocimientos sobre la seguridad y el cumplimiento de requisitos también se considera un reto para la implementación de DevSecOps. Es habitual encontrar que los desarrolladores carecen de habilidades relacionadas con la seguridad. Incluso pueden surgir ideas absurdas de la mala comprensión de la práctica DevSecOps, como que este método conduce a un mayor número de problemas de seguridad. Lo que la gente no está viendo con claridad es que los problemas existentes se identifican y reportan en las organizaciones gracias a este método, algo que normalmente no ocurre con una simple metodología DevOps. Muchos quieren ignorar que están en riesgo. Simplemente cierran los ojos hasta que el impacto los despierta.

Otro reto en la implementación de DevSecOps está relacionado con las herramientas. Normalmente, las herramientas DevOps como las de CI/CD, gestión de código fuente, revisión de código y compilación, entre otras, proceden de distintos proveedores. Todo puede complicarse aún más con la adición de herramientas de pruebas de seguridad. Con la ausencia de documentación y formación, los desarrolladores pueden tener dificultades para elegir entre las herramientas disponibles. Integrar las herramientas en los procesos DevOps puede resultarles complicado y tomarles mucho tiempo. Además, pueden tener dificultades para combinar y conciliar los resultados de diversos recursos, especialmente si proceden de diferentes proveedores.

Obviamente, también pueden surgir retos monetarios. Los cambios en las prácticas empresariales pueden ser costosos. Esto es un impedimento para muchas compañías cuando no se evalúan los términos a corto y largo plazo. Por ejemplo, el entrenamiento del equipo y la adquisición de herramientas pueden suponer costos elevados a corto plazo. Sin embargo, un lanzamiento rápido de productos seguros y de alta calidad puede generar beneficios a largo plazo, y la prevención de ciberataques puede evitar costos más elevados.

Empieza ya con la solución DevSecOps de Fluid Attacks

Estrategia DevSecOps: las mejores técnicas de implementación

De acuerdo con los principios o pasos básicos mencionados anteriormente, te recomendamos las siguientes prácticas para aplicar correctamente la cultura DevSecOps en tu organización.

  • Cambio cultural gradual: Como mencionamos arriba, el cambio empieza con las personas. La adopción de la cultura DevSecOps puede ocurrir como pasa con muchas otras tendencias, es decir, con un efecto gradual. No recomendamos promover inmediatamente la metodología para todos los equipos de tu organización. Puedes comenzar con pequeños grupos de individuos que ya hayan mostrado un fuerte interés que encaje con los propósitos de DevSecOps para incorporar esta cultura con nuevas prácticas en su trabajo diario. A partir de ahí, los beneficios conseguidos pueden servir de inspiración para sumar a más miembros de tu organización a un cambio exitoso. Por supuesto, debes recordar que no se trata de crear un nuevo equipo llamado "DevSecOps". Los miembros de los equipos de tu organización comenzarán a hacer la transición a una forma de pensar en la que todos son responsables de la seguridad.

  • Formación y práctica en seguridad: Quienes ya están algo inmersos en la teoría y la práctica de la seguridad dentro de tu organización pueden servir de apoyo para dar los primeros pasos en DevSecOps, posiblemente acompañados de especialistas externos. Con estos últimos, puedes obtener servicios de evaluación de la seguridad antes de iniciar ciclos de desarrollo. Además, junto con tu equipo, pueden ayudarte con el modelado de amenazas y a definir qué controles y requisitos de seguridad implementar. Pero, con la ayuda de los primeros, deberías empezar a enfrentarte inmediatamente al reto de la falta de conocimientos. Los denominados 'campeones de seguridad', a veces en la posición de ingenieros DevSecOps, pueden establecer planes de difusión de conocimientos y llevar a cabo capacitación interna para aumentar la concientización sobre la seguridad dentro de cada equipo. A través de ellos, e incluso con cursos en línea, tus equipos deberían recibir entrenamiento sobre las mejores prácticas de codificación segura y gestión y remediación de problemas de seguridad. Obviamente, deben ser testigos y participar en la identificación de vulnerabilidades en los productos de tu organización y en su remediación, recibiendo retroalimentación continua. Para desarrollar aún más su experiencia y confianza, también pueden recurrir a la obtención de certificaciones.

  • Elección de los momentos para las actividades de seguridad: Antes de pensar en qué tipo de actividades de seguridad implementar en tu organización, es prudente reflexionar sobre los momentos del SDLC donde se aplicarán. Definiendo estos puntos y a través de las discusión y análisis de la seguridad, te será más fácil elegir las actividades y herramientas adecuadas a implementar. Por ejemplo, considerando las primeras fases del pipeline DevOps, lo anterior se dirige más específicamente al proceso de planificación inicial. En la fase de codificación, suelen utilizarse actividades como la revisión de código y los protocolos de seguridad para contraseñas y otra información sensible. Luego, en la fase de construcción, una vez añadido código al repositorio, pueden entrar en juego las pruebas de seguridad de aplicaciones estáticas (SAST) y el análisis de composición de software (SCA). El primero revisa el código en busca de vulnerabilidades, mientras que el segundo revisa las dependencias del código. En la fase de pruebas, cuando el producto está listo para ejecutarse y probarse, pueden utilizarse las pruebas de seguridad de aplicaciones dinámicas (DAST). Este método no accede al código, sino que envía vectores de ataque a los endpoints de las aplicaciones en ejecución. Ya el pentesting puede realizarse más adelante en el ciclo de vida de DevSecOps, en la fase de lanzamiento. Este método depende de hackers que intentan esquivar controles, crear exploits personalizados, etc.

Pipeline DevSecOps Fluid Attacks

(Imagen tomada de aquí.)

  • Automatización de las actividades de seguridad: Automatizar herramientas y procesos relacionados con la seguridad dentro de la metodología DevSecOps es útil para evitar desvirtuar el propósito del enfoque DevOps de inyectar velocidad. La automatización de procesos permite que estos se lleven a cabo de forma coherente e iterativa. Las herramientas de automatización de DevSecOps reducen las cargas al proporcionar alertas tempranas o información relevante a los desarrolladores para una rápida remediación de los problemas de seguridad. Sin embargo, es importante que determines hasta dónde debería llegar la automatización, ya que las intervenciones manuales siempre son necesarias, por ejemplo con el pentesting. Ciertamente, el trabajo manual sigue siendo un componente indispensable para la precisión y la profundidad.

    Hay que tener en cuenta que el software y los estándares para su regulación cambian constantemente. Por lo tanto, la automatización para la evaluación y el cumplimiento de las normas es bastante útil. En función del sector al que pertenezca tu empresa, tu equipo selecciona los requisitos de seguridad que necesitan o deben cumplir, por ejemplo, PCI DSS, HIPAA y GDPR. Una vez que los requisitos estén codificados, la automatización te permite verificar rápidamente en el código o el producto si estos se están incumpliendo y notificarlo al personal para su pronta resolución. Además, cuando supervisas el cumplimiento y recibes continuamente estados completos del software, puedes agilizar las acciones de respuesta para evitar costosas multas y demandas por incumplimiento de la normativa.

  • Evaluación progresiva de la seguridad: Al integrar y aplicar actividades de seguridad, conviene ir poco a poco, sin aspiraciones desmesuradas. De lo contrario, bombardear a los desarrolladores con un sinfín de hallazgos por abordar en periodos cortos puede hacer que se muestren poco dispuestos a solucionarlos. Así que, en lugar de ejecutar pruebas completas cada vez, puede ser más razonable una evaluación gradual, por ejemplo, en los primeros casos, atendiendo solo a las áreas, o buscando vulnerabilidades, de alta prioridad. Más adelante, las siguientes pruebas o actividades de seguridad servirán de complemento para una evaluación más amplia y profunda antes de pasar a producción. Adicionalmente, una recomendación importante en pro de la agilidad es que el equipo de desarrolladores de tu organización envíe siempre el código en pequeños fragmentos para su revisión.

  • Actividades de seguridad manuales: Como se ha indicado anteriormente, aunque la automatización es relevante en la adopción de DevSecOps, la actividad manual sigue siendo especialmente importante. Las herramientas automatizadas de detección de vulnerabilidades siguen reportando mentiras (falsos positivos) e incurriendo en omisiones (falsos negativos). Las evaluaciones manuales pueden hacer verificaciones de lo anterior y escaneos más profundos. Por ejemplo, el ejercicio manual puede centrarse en tareas desde la perspectiva de los atacantes para explotar vulnerabilidades de forma controlada y evaluar posibles impactos a la organización (hacking ético). La recomendación es que tu organización haga evaluar sus sistemas en pruebas de penetración continuas que mantengan una fuerte cultura de remediación. No es recomendable realizar solo pruebas de penetración periódicas, ya que el período de tiempo entre una prueba y otra podría dar a los atacantes la oportunidad de aprovecharse de la exposición al riesgo de tu sistema.

  • Medir el rendimiento y el progreso: La medición forma parte de la correcta implementación de DevSecOps. Lo ideal es recopilar datos de tu organización sobre su rendimiento dentro de la nueva metodología, organizarlos cuidadosamente y establecer métricas significativas. Entre los datos a recoger pueden estar, por ejemplo, los relacionados con las pruebas de seguridad y sus hallazgos, así como con las actividades de remediación y despliegue. Las métricas permiten llevar un registro de los progresos. Resulta muy beneficioso disponer de una plataforma que elimine el ruido en la recopilación de datos procedentes de distintas fuentes.

  • Aprender mediante la retroalimentación: La medición de éxitos y fracasos siempre será esencial en la implementación de DevSecOps. Pero más importante aún es que esos registros sirvan para optimizar procesos dentro de tu organización. En la integración y el despliegue continuos de software, siempre habrá resultados que comparar y analizar. La detección de lo que mejoró o empeoró las cosas en un proceso o ciclo es algo que puedes transmitir a tus equipos a modo de retroalimentación con la esperanza de que conduzca al aprendizaje. Cuanto antes lo transmitas, mejor.

  • Nueva gobernanza: La gobernanza clásica puede implicar retrasos en la entrega de software que no encajan en absoluto con la cultura y la mentalidad DevSecOps. La sugerencia entonces es recurrir de nuevo a la automatización. Puedes automatizar las actividades de verificación, como son los controles antes de que el software pase a producción. No hay necesidad de evaluar manualmente un estado de seguridad final; aplica excepciones preseleccionadas y rompe el build cuando haya problemas sin solucionar. Para adoptar una nueva gobernanza como esta, dentro de DevSecOps, debes contar con la colaboración y aprobación de tus equipos.

Si quieres conocer las mejores prácticas de DevSecOps, es decir, las acciones que mantienen viva tu implementación, visita este post.

Herramientas y recursos DevSecOps

La implementación de DevSecOps incluye herramientas para diferentes tipos de pruebas de seguridad integradas en el SDLC.

  • SAST: Las herramientas para este tipo de pruebas escanean código que no se está ejecutando para detectar errores de codificación y diseño que puedan crear debilidades explotables.

  • SCA: Las herramientas para este tipo de pruebas escanean código y archivos de componentes de código abierto y de terceros para identificar vulnerabilidades conocidas y problemas de licencia.

  • DAST: Las herramientas para este tipo de pruebas, las cuales no requieren acceso al código fuente, evalúan las aplicaciones en ejecución para detectar vulnerabilidades relacionadas con su configuración de despliegue, datos y lógica empresarial.

Algunas consideraciones recomendadas para la selección de productos DevSecOps son las siguientes:

  • Es fácil de instalar, configurar y utilizar.

  • Es altamente preciso, es decir, genera bajas tasas de falsos positivos y falsos negativos, y busca lo que necesitas que busque.

  • Es lo suficientemente rápido como para funcionar dentro de tu SDLC.

  • Cubre las políticas que tu empresa necesita abarcar.

  • Puede trabajar continuamente, en paralelo e integrado con otras herramientas en uso.

Adicionalmente, nos gustaría destacar un par de recursos relacionados con las herramientas anteriores que son bastante útiles en la implementación de DevSecOps:

  • Pentesting: En esta metodología de pruebas de seguridad, en la que predomina el trabajo manual de los hackers éticos sobre las verificaciones con herramientas automatizadas, se simulan ataques reales para identificar vulnerabilidades que podrían explotar los atacantes en un determinado ambiente.

  • Plataforma de gestión de resistencia a ataques: Este es otro tipo de herramienta que facilita la gestión y remediación de vulnerabilidades de seguridad. Esta plataforma unifica los datos obtenidos por diferentes métodos y herramientas, facilita la comprensión y el análisis de los problemas detectados, y prioriza los hallazgos clave para su pronta remediación.

Descubre aquí cómo Fluid Attacks utiliza las herramientas DevSecOps.

Implementa DevSecOps con Fluid Attacks

En Fluid Attacks estamos preparados para ayudarte en la transformación de tu organización, implementando DevSecOps. Contamos con profesionales de seguridad certificados y experimentados, encargados de integrar procesos y herramientas de seguridad desde el inicio y a lo largo de tu SDLC. En una única solución, incluimos herramientas automatizadas para pruebas de seguridad como SAST, DAST y SCA. Nuestro equipo de hackers éticos añade pruebas de penetración o procedimientos de simulación de brechas y ataques y te garantizan bajas tasas de falsos positivos y falsos negativos. Además, nuestras pruebas de seguridad pueden validar alrededor de 50 estándares de referencia internacional para tus requisitos de cumplimiento. Todas las vulnerabilidades de seguridad que detectamos en tu software se reportan en un único lugar, nuestra plataforma. Esta plataforma te permite conocer el estado de seguridad de tus sistemas y aplicaciones, conocer en detalle las vulnerabilidades detectadas y priorizarlas para su pronta y correcta remediación. Además, esta plataforma te permite hacer un seguimiento de los tratamientos y ver métricas que puedes utilizar para hacer comparaciones y tomar mejores decisiones, entre otras muchas cosas. En Fluid Attacks, hackeamos tu software constantemente para estar un paso por delante de los atacantes maliciosos. Además, nuestra solución DevSecOps hace que la seguridad impregne a tus equipos para que esta sea entendida como responsabilidad de todos.

¿Quieres saber más sobre DevSecOps?

Para más información sobre la solución DevSecOps de Fluid Attacks y cómo puede beneficiar a tu empresa, sigue este enlace o ponte en contacto con uno de nuestros expertos. También te invitamos a conocer cómo nuestros servicios son clave para implementar DevSecOps en AWS (aquí) y Azure (aquí). Adicionalmente, aquí tienes dos de nuestras entradas que responden a las siguientes preguntas sobre DevSecOps: ¿Qué es DevSecOps? ¿Qué hace un ingeniero DevSecOps?

Suscríbete a nuestro blog

Recibe el boletín semanal de Fluid Attacks.

Blog posts recomendados

Quizá te interesen los siguientes posts similares.

Foto por FlyD en Unsplash

Gestionando la cadena de suministro de software en el sector financiero

Foto por Robs en Unsplash

Las violaciones de datos más graves cometidas en el sector financiero

Foto por Towfiqu barbhuiya en Unsplash

Consejos y más sobre la protección de datos en este sector

Foto por Jasmin Egger en Unsplash

Si tu capa esencial de seguridad es vulnerable, estás frito

Foto por Christian Wiediger en Unsplash

La necesidad de mejorar la seguridad en el sector fintech

FOto por Claudio Schwarz en Unsplash

¿Es tu servicio financiero tan seguro como crees?

Foto por mitchell kavan en Unsplash

Poniendo en práctica el modelo zero trust

Inicia tu prueba gratuita de 21 días

Descubre las ventajas de nuestra solución Hacking Continuo, de la cual ya disfrutan cientos de organizaciones.

Inicia tu prueba gratuita de 21 días
Fluid Logo Footer

Hackeando software durante más de 20 años

Fluid Attacks analiza aplicaciones y otros sistemas, abarcando todas las fases de desarrollo de software. Nuestro equipo ayuda a los clientes a identificar y gestionar rápidamente las vulnerabilidades para reducir el riesgo de ciberincidentes y desplegar tecnología segura.

Copyright © 0 Fluid Attacks. We hack your software. Todos los derechos reservados.