DevSecOps desaparecerá y DevOps tendrá la seguridad incorporada. Aquí está la seguridad que es relevante durante la codificación y la seguridad que es relevante durante las operaciones, pero nunca ha habido una "Sec" separada en DevOps. Ambas actividades de seguridad se convertirán en una parte integral de sus respectivas "mitades" del ciclo DevOps. El fervor en torno a DevSecOps se enfriará porque el mercado y los analistas reconocerán que la seguridad en el desarrollo, la entrega y la producción deben incorporarse a un nivel fundamental, obviando así la necesidad de pensar en DevSecOps como algo separado de DevOps.

1. ¿DEVSECOPS
puede
desaparecer?
DEVSECOPS

2. Luciano Moreira
• Chief DevSecOps strategy Officer en Cloud Legion
• seleccionado por la gente de peerlyst como uno de los "50 Influential
DevSecOps Professionals“
• Embajador del DevOps Institute
• Instructor acreditado de los cursos (DevSecOps Foudation, DevSecOps
Enginier y DevSecOps Master Professional)
• Master en Ciberseguridad por la Universidad Camilo José Cela.
• Primer Auditor CSA STAR certificado en la región SOLA
• Elegido Cybersecurity Consultant of the Year en los premios Cybersecurity
Excellence Awards del 2016 al 2019,
• MVP - Most Valuable Professional Microsoft Azure
• Auditor Líder ISO 27001:2013, 27018, 27017, 22301, 20000, 25000 y 9001
• Co-Fundador y Tribe lider de DevSecOps Argentina y Latam,
• Presidente del capítulo argentino de la CSA Cloud Security Alliance.

3. ¿Ser o no ser DevSecOps
esa es la cuestión?

4. Maratón OPS
¿Cual será el próximo OPS de moda a alcanzar?

5. oh, lo intentamos y no
funcionó….
cambiemos el nombre de la idea original
a uno que organización aún no haya
rechazado
DevXxxOps en todas partes
BizDevSecTestNetFinDataGitOps

6. BizDevSecTestNetFinDataGitNoMLSRExxxxOps
• Recuerden, el objetivo de DevOps es incrementar la
colaboración a través de toda la organización para
que usted tenga la capacidad de liberar software útil
de forma confiable y rápida a la organización.
• Como quieras llamarlo, depende de ti, pero como
trataremos de mostrar en esta presentación, todos
los otros nombres que existen para DevOps son sólo
palabrería.
Cualquiera que haya leído The Phoenix Project. La primera forma de DevOps es la idea del
pensamiento sistémico. ¿Cómo entregamos valor a nuestros clientes? Y en este punto, es un poco
inocente pensar que sólo los desarrolladores y operaciones están entregando valor a los clientes.

7. ¿Hay diferencias entre DevOps y
DevSecOps?
• El acrónimo de DevOps no significa que incluyamos
Desarrolladores y Operaciones, y que dejemos de lado todo lo
demás, sino que, en cambio, piense en Desarrollo y Operaciones
como cabeceras, con DevOps incluyendo todo lo que se
encuentra en el medio también; pruebas, seguridad,
rendimiento, etc.
• La diferencia entre DevOps y DevSecOps es únicamente el
marketing. Una de tantas palabras de moda que surgió porque
demasiadas personas han implementado DevOps sin seguridad,
están sufriendo y, en lugar de decir, lo hicimos mal, se les ocurrió
un nuevo término (DevSecOps)
• Si analizamos una de la primicia de DevSecOps es Security Shift
Left, El nombre mas adecuado no sería SecDevOps?

8. ¿Entonces
DevSecOps
puede
desaparecer?
DevSecOps es solo
una palabra ¿como
podría
desaparecer?

9. DevSecOps es solo una palabra, no existe o es
invisible…
¿Como que
DevSecOps no
existe?
¿Qué hago ahora
con la metodología
carísima que
pagamos para
implementarlo?
¿Puede que tenga
razón o no?
¿La mejor idea es
profundizar un poco
mas en ese analisis?

10. Repasemos algunos principios de la
industria

11. es la unión de personas, procesos y herramientas para permitir la entrega continua de
valor a sus usuarios finales.
Las operaciones de desarrollo constituyen una combinación de filosofías culturales,
prácticas y herramientas que incrementan la capacidad de una organización de
proporcionar aplicaciones y servicios a gran velocidad.
El término "DevOps" es una combinación de las palabras "development" y "operations",
pero representa un conjunto de ideas y prácticas que van más allá de ambos conceptos,
ya sea que estén juntos o separados. DevOps incluye sistemas de seguridad, maneras
de trabajar en colaboración, análisis de datos, entre otras características..
DevOps
“
”
“
”
“
”
es un conjunto de prácticas que agrupan el desarrollo de software ( Dev ) y las
operaciones de TI ( Ops ). Su objetivo es hacer más rápido el ciclo de vida del
desarrollo de software y proporcionar una entrega continua de alta calidad.
“
”

12. DevOps es un conjunto de prácticas
destinadas a reducir el tiempo que
transcurre entre la introducción de
un cambio en un sistema y su
puesta en producción normal,
garantizando al mismo tiempo una
alta calidad. Bass, Weber y Zhu
DevOps

13. Como vimos se habla mucho de DevSecOps
por parte de expertos, profesionales,
académicos y proveedores.
Pero para mantener el software seguro, hay
que ir más allá de asegurar el código que se
está desarrollando y también asegurar el
pipeline que entrega ese código.
DevSecOps
La seguridad forma parte de DevOps
y antes de eso ya era una atributo de
calidad

14. Seguridad
Se debe garantizar el acceso y la utilización de la información y los
sistemas de tratamiento de la misma por parte de los individuos,
entidades o procesos autorizados cuando lo requieran.
Se debe velar por el mantenimiento de
la exactitud y la completitud de la
información y sus métodos de proceso.
Se debe evitar que la información no
esté a disposición o no sea revelada a
individuos, entidades o procesos no
autorizados.

15. Calidad
Calidad del sistema/producto de software
Adecuación
funcional
Completitud
Corrección
Idoneidad
Eficiencia en el
desempeño
Comportamient
o en el tiempo
Utilización de
recursos
Capacidad
Compatibilidad
Coexistencia
Interoperabili-
dad
Usabilidad
Reconocimiento
de la aptitud
Capacidad de ser
aprendido
Operabilidad
Protección
contra errores
Estética de la
interfaz con el
usuario
Accesibilidad
Confiabilidad
Madurez
Disponibilidad
Tolerancia a las
fallas
Recuperabilidad
Seguridad
Confidencialidad
Integridad
No repudio
Trazabilidad
Autenticidad
Capacidad de se
mantenido
Modularidad
Reusabilidad
Capacidad de ser
analizado
Capacidad de ser
modificado
Capacidad de ser
testeado
Portabilidad
Adaptabilidad
Capacidad de ser
instalado
Capacidad de ser
reemplazado

16. Calidad en el uso
Calidad en el uso
Efectividad
Efectividad
Eficiencia
Eficiencia
Libre de riesgos
Mitigación de
riesgos
Satisfacción
Cumplimiento del
propósito
Confianza
Contexto de uso
Completitud del
contexto
Flexibilidad

17. ¿Entonces que pasa con
DevSecOps?
• En los últimos años, DevSecOps ha sido una de las
principales estrategias en muchas organizaciones.
• La supuesta idea es que DevSecOps sea DevOps
con seguridad incluida también.
• Pero si el objetivo de DevOps es enfocarse en
lanzamientos sólidos, mientras comprende más
sobre lo que está lanzando a través de métricas y
datos de calidad, la seguridad debe estar incluida
en esto; de lo contrario, simplemente lanzará
software vulnerable más rápido.

18. DEV OPS

19. ¿Entonces DevSecOps no existe?
• Si lo estas haciendo bien, el "Sec" debe ser silencioso e indetectable.
• La seguridad se convierte en un componente integral de todo su SDLC. Piense en ello
como "Cambiar la seguridad en todas partes “ para entregar valor a sus clientes.
• Sí, el código debe ser seguro, pero también deben serlo los mecanismos que utiliza para
llevarlo a producción.
• También debe estar atento a las vulnerabilidades que ocurrirán una vez que se publique
su código. (Sucederán, lo que nos lleva a ...)
Ser como el bambú doblarse pero no romperse

20. ¿cómo mantener
verdaderamente
seguro el software?
Tu empresa tu receta

21. DevOps y DevSecOps son lo mismo
• La seguridad es claramente una parte integral de DevOps. La tendencia
DevSecOps surgió para alinear las prácticas de gestión de la seguridad y el
cumplimiento con el resto de DevOps. Sirve para señalar el abismo temporal
que existe entre la seguridad y DevOps.
• A medida que las comprobaciones y los controles de seguridad se
automatizan e integran, uno se da cuenta que DevOps y DevSecOps
convergen en lo mismo.
• Para seguir siendo relevante, su equipo de seguridad debe integrarse en el CI
/ CD y asegurarse de que los entornos recién creados cumplan con las
políticas de la organización.

22. Mantenga el software seguro haciéndolo
resistente, no invulnerable
• La perfección no es posible, así que ni lo intentes.
• Es mejor que seas de clase mundial en el descubrimiento
de vulnerabilidades antes del lanzamiento, así como en
responder a ellas después del lanzamiento.
• Practica los fracasos.
• Escanee todo, en todas partes, constantemente.

23. Cierre la brecha entre MTTD y MTTR con
MTTM
• El tiempo entre el (MTTD) tiempo medio de detección y el
(MTTR) tiempo medio de reparación es el tiempo que está
expuesto a esa vulnerabilidad.
• Instale sistemas para mitigar automáticamente el problema
a través de interrupciones de apagado a nivel de función o
reversiones quirúrgicas bien ensayadas.
• Cerrar esa vulnerabilidad tras la detección le brinda un búfer
de seguridad para desarrollar y probar a fondo una solución.
Los indicadores de funciones pueden ayudar con esto.
MTTD
MTTR
MTTM

24. Aplique (CIA) al software,
no solo a los datos
• Mantener el software seguro requiere (CIA) de ese
software.
• Garantizar la confidencialidad significa utilizar RBAC
para garantizar la segregación de funciones y la
visibilidad gestionada.
• Asegurar la integridad significa garantizar no solo que
se utilicen los bits o el código correctos, sino también
que sean los bits de código correctos.
• Garantizar la disponibilidad significa que todos tienen
el acceso y los niveles de privilegios adecuados para
hacer su trabajo y también sus sistemas de entrega
de software son lo suficientemente resistentes como
para estar siempre disponibles.

25. Cuando surgen problemas,
la cultura importa
• Los problemas van a pasar…
• En lugar de dispararle al mensajero cuando lo
hagan, aplauda al mensajero que lo encontró
(con suerte antes de que los malos actores lo
hayan encontrado).
• Ha esperado y practicado para esto, ¿verdad?
Celebre cuando su práctica y previsión hayan
valido la pena (después de haber solucionado
el problema, por supuesto).

26. Todos los componentes de
software deben tratarse
por igual
• Trate todos los artefactos de automatización
con el mismo nivel de seguridad con el que
trata cualquier código fuente.
• Son tan importantes para su postura de
seguridad como el código que desarrolla.
• Versión de ellos.
• Audítelos.
• Revise, revise y actualice periódicamente.
• Retirar los que ya no encajan.

27. Automatizar todo
• Si no está automatizado, no es auditable ni
protegible.
• Si es un paso manual, no se puede controlar,
auditar ni mitigar fácilmente.
• Automatice todas las medidas de seguridad
para que sean parte del proceso.

28. Los auditores no son el
enemigo, ¡deléitelos en su
lugar!
• Asegúrese de que los auditores estén en la
mesa con usted, no frente a usted.
• Si tiene la seguridad y la gobernanza
construidas de la manera correcta, ellos
podrán obtener lo que necesitan por sí
mismos.
• Además, los datos que tienes son inmutables
(porque también los has protegido, ¿verdad?).

29. No todo el mundo
necesita ser un experto en
seguridad
• La seguridad es el trabajo de todos, pero no
todos necesitan saber cómo solucionar una
vulnerabilidad, ni todos necesitan saber cómo
detectar o mitigar una.
• Asegúrese de que las personas adecuadas
sepan cómo manejar sus responsabilidades
individuales para mantener el software seguro.

30. CALMS
CULTURE
Todos los equipos tecnológicos son responsables de la seguridad; la seguridad es
tarea de todos. Todos comprenden el sistema de extremo a extremo y colaboran
regularmente para crear confianza.
AUTOMATION
La automatización ayuda a garantizar la seguridad mediante el uso estratégico de la
orquestación y la automatización de tareas y procesos que tienen vulnerabilidades
de seguridad cuando se hacen manualmente y donde la automatización puede
mejorar las prácticas de seguridad.
LEAN
La seguridad no es una limitación en el flujo de valor y los equipos no esperan a
que se realicen las actividades de seguridad: el flujo se optimiza. El trabajo es
visible a través de los backlogs compartidos.
MEASUREMENT
Se entiende el coste de la infracción, se comparten las métricas de negocio y de
ataque y se sigue un enfoque centrado en el flujo de valor para optimizar el tiempo
del ciclo y garantizar que no haya retrasos causados por la seguridad.
SHARING
Los ingenieros de seguridad y de software tienen competencias cruzadas y
colaboran para automatizar los conocimientos. Las historias se comparten a través
de wikis, standups y en el día a día...
https://devsecops-latam.org/

31. Dormir bien
• O quizás mejor, sabiendo que has integrado
herramientas y procesos en todo el sistema.
• Que tienes sistemas para detectar y mitigar
problemas, ha practicado fallas y ha
automatizado todo lo que puede.
• Cuando sucede algo, estás preparado.

32. Comunidad
• Para profundizar los principios y la temática en DevSecOps, súmate a DevSecOps Latam
https://devsecops-latam.org/

34. Thank You