SBN

Guía: Cómo implementar DevSecOps

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 and 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
por diferentes métodos y caminos.

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
e interrumpir 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.

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
    a veces en la posición de,
    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.
    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,
    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 lotransmitas, 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 fiinal;
    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 de gestión de resistencia a ataques (ARM).
La plataforma ARM 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 comparar 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
y qué hace un ingeniero DevSecOps?

*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Felipe Ruiz. Read the original post at: https://fluidattacks.com/es/blog/como-implementar-devsecops/