Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Dev Sec
LoscasosdenoéxitodeDevSecOps 1.1
OOPS!!!.
2
SI TIENES PREGUNTAS
DURANTE LACHARLA INGRESA
AL CODIGO QREINGRESA ESTE
NUMERO
#22617qrco.de/preguntar
3
Chief Executive Officer en Cloud Legion
Referente en DevSecOps en la región
Amazon Web Services (AWS) Technical Trainer
...
Luciano Moreira
4
Chief DevSecOps strategy Officer en Cloud Legion
“TOP 50 Influential DevSecOps Professionals“
Embajador ...
Aveces mepregunto sitanto
nos gustan lashistorias de
superación….
…¿Porque ninguna empresa o
consultor publica suscasos de...
Lacultura deléxito (Unfrenoparalainnovación )
Solemos reverenciarel éxito, el logro, la realización de lo que esperamos, p...
¿Sepuede aprender del fracaso tanfácilmente?
En realidad, no se aprende de fracasar, se aprende de superar
los fracasos. Y...
¡Fracasar esbueno! ¡Falla rápido, falla barato!
• Fallamos rápido, fallamos a menudo y aprendemos a diario de
forma contin...
Loscasos denoéxito deDevSecOps
“Los casos que veremos en la presentación están en alto nivel y modificados
para no exponer...
#1:Mono=One, Rail =Rail… (Sharing &Culture)
Algunas empresas no logran comprender DevSecOps y como
adoptarlo
En este prime...
#1:Mono=One, Rail =Rail… (Sharing &Culture)
Luego de profundizar la cuestión
con varios clientes sobre este
fracaso de ado...
#1:Mono=One, Rail =Rail… (Sharing &Culture)
Veamos algunos ejemplos:
• DevSecOps es un proceso/metodología.
• DevSecOps y ...
#1:Mono=One, Rail =Rail… (Sharing &Culture)
Visión Nerd del caso
Esta falta de confianzasobre la integraciónde la segurida...
#1:Mono=One, Rail =Rail… (Sharing &Culture)
Lecciones aprendidas
Un patrón que recomendamos en los caso de nos éxito de ad...
#1:Mono=One, Rail =Rail… (Sharing &Culture)
Lecciones aprendidas
A veces la colaboración de un tercero para la realización...
#2: Herramientitis aguda(Automation & Culture)
Centrarse en herramientas puede ser una receta peligrosa
El caso de no éxit...
17
Muchos clientes y conocidos empezaron sus proyecto de
DevOps/DevSecOps por las herramientas.
Pronto se dieron cuenta lo...
#2:Herramientitis aguda(Automation &Culture)
Visión Nerd del caso
Empezar DevSecOps por las herramientasnos puede traer co...
#2:Herramientitis aguda(Automation &Culture)
Lecciones aprendidas
No vamos a negar que la Automatización basada en
herrami...
#2:Herramientitis aguda(Automation &Culture)
Lecciones aprendidas
Muchas empresas han empezado sus proyectos implementando...
#3:TreeHouse ofZombies (Measurement &Culture)
Backup Tapes…
Backup Tapes…
Backup Tapes…
En este caso de no éxito nos basar...
A menudo vemos a las empresas implementar nuevas técnicas o
practicas sin tener en cuenta todo el ecosistema del negocio y...
#3:TreeHouse ofZombies (Measurement &Culture)
Visión Nerd del caso
No prepararse para el cambio cultural, a nivel empresa ...
#3:TreeHouse ofZombies (Measurement &Culture)
Lecciones aprendidas
Existen innumerables métricas posibles en el mundo
DevS...
#4:Entra cuchillo salen lastripas (Lean,Sharing &Culture)
Muri & Muda
Este caso usaremos los términos japoneses Muri y
Mud...
#4:Entra cuchillo salen lastripas (Lean,Sharing &Culture)
Si pensamos en Muri, podemos decir que la postura del
oficial de...
#4:Entra cuchillo salen lastripas (Lean, Sharing &Culture)
Visión Nerd del caso
No cumplir con los plazos del proyecto por...
#4:Entra cuchillo salen lastripas (Lean,Sharing &Culture)
Lecciones aprendidas
No importa de que área seas “Sec,Dev o Ops”...
#4:Entra cuchillo salen lastripas (Lean,Sharing &Culture)
Lecciones aprendidas
Comenzamos por considerar la visión o direc...
Errores típicos
• Demasiadas empresas posterganla implementación de iniciativas DevSecOps.Hastaque
"sospecharono validaron...
Errores típicos
• DevOps implica más que simplemente unirlos equipos de desarrolloyoperaciones; Es un proceso continuo
de ...
Como evitar omitigar?
Cambio de mentalidad: El software se ha convertido en la piedra angular de la innovación y el
crecim...
Como evitar omitigar?
Shift Left para "fallar rápidamente“: Inspeccionar la calidad del
código lo antes posible es parte d...
Como evitar omitigar?
Construí campeones de seguridad: Normalmente los equipos de
seguridad son pequeños en comparación co...
35
Conclusión
“Desarrolla tu grito de guerra para la transformación de
DevSecOps”
Próximamente
Lo que vimos hoy es solo la punta del iceberg
Desde DevSecOps Latam - Squad de Argentina estuvimos relevando ...
37
SITIENESPREGUNTAS DURANTE
LACHARLA INGRESAALCODIGO
QREINGRESA ESTENUMERO
#22617qrco.de/preguntar
Gracias!
Upcoming SlideShare
Loading in …5
×
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

1

Share

Download to read offline

DevSec-Oops!... "Los casos de no éxito en DevSecOps

Download to read offline

Luciano Moreira da Cruz y Christian Ezequiel Ibiri nos comparten en el #DragonJARCON 2020 una charla titulada "DevSec-Oops!... "Los casos de no éxito en DevSecOps" cuya descripción es:

Aprendemos más de los fracasos que de los éxitos. Cuando algo sale como se esperaba, usamos ese proceso como una plantilla mental para futuros proyectos. El verdadero aprendizaje llega a través de la crisis. Si algo sale mal, tenemos que revolver, experimentar, hackear y seguir nuestro proceso.



-----------------------------------------------------------------------------------------------
Youtube: DragonJARtv (http://bit.ly/DragonJARtv)
Facebook: La.Comunidad.DragonJAR (http://bit.ly/DragonJARfb)
Twitter: @DragonJAR (http://bit.ly/DragonJARt)
Instagram: Dragon.JAR (http://bit.ly/DragonJARig)
Discord: https://invite.gg/DragonJAR
Blog: Comunidad DragonJAR (http://bit.ly/DragonJAR)
-----------------------------------------------------------------------------------------------

Related Books

Free with a 30 day trial from Scribd

See all

DevSec-Oops!... "Los casos de no éxito en DevSecOps

  1. 1. Dev Sec LoscasosdenoéxitodeDevSecOps 1.1 OOPS!!!.
  2. 2. 2 SI TIENES PREGUNTAS DURANTE LACHARLA INGRESA AL CODIGO QREINGRESA ESTE NUMERO #22617qrco.de/preguntar
  3. 3. 3 Chief Executive Officer en Cloud Legion Referente en DevSecOps en la región Amazon Web Services (AWS) Technical Trainer Cybersecurity Team of the Year en los premios Cybersecurity Excellence Awards del 2019, Board Member - Argentina Chapter of Cloud Security Alliance "50 Influential DevSecOps Professionals“ Co-Fundador y Tribe lider de DevSecOps Argentina y Latam. Christian Ibiri @Christianibiri /in/christian-ibiri/
  4. 4. Luciano Moreira 4 Chief DevSecOps strategy Officer en Cloud Legion “TOP 50 Influential DevSecOps Professionals“ Embajador del DevOps Institute Master en Ciberseguridad por la Universidad Camilo José Cela. 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 y 9001:2015, Co-Fundador y Tribe lider de DevSecOps Argentina y Latam, Presidente del capítulo argentino de la CSA Cloud Security Alliance. @Luciano_m_cruz /in/lucianomoreiradacruz/
  5. 5. Aveces mepregunto sitanto nos gustan lashistorias de superación…. …¿Porque ninguna empresa o consultor publica suscasos deno éxitoycomolosuperaron?
  6. 6. Lacultura deléxito (Unfrenoparalainnovación ) Solemos reverenciarel éxito, el logro, la realización de lo que esperamos, pero qué pasaría con la humanidad si no existiera el intento, la falla, esa búsqueda permanente de ir más allá. El éxito en realidad "frena el proceso de aprendizaje" Aprendemos más de los fracasos que de los éxitos. Cuando algo sale como se esperaba, usamos ese proceso como una plantilla mental para futuros proyectos. El verdadero aprendizaje llega a través de la crisis. Si algo sale mal, tenemos que revolver, experimentar, hackear y seguir nuestro proceso. Ref: Epic Fail DevSecOsp
  7. 7. ¿Sepuede aprender del fracaso tanfácilmente? En realidad, no se aprende de fracasar, se aprende de superar los fracasos. Y eso es muy difícil en organizaciones que tiene el fracaso como algo negativo/sucio en vez de pasos esenciales para conseguir una innovación exitosa. Si queres mejorar tras un fracaso y tienes poco tiempo porque te persigue el “Time to Market” podes seguir esta técnica rápida de autoevaluación mediante cinco preguntas: 1. Qué puedo aprender? 2. Qué hubiera hecho diferente? 3. Qué competencias debo entrenar? 4. De quién puedo aprender? 5. Cuál es el próximo paso? El hedor del fracaso todavía está en mí.
  8. 8. ¡Fracasar esbueno! ¡Falla rápido, falla barato! • Fallamos rápido, fallamos a menudo y aprendemos a diario de forma continua. • Si no fuéramos desafiados y no aprendiéramos, nuestros trabajos y nuestro trabajo serían extremadamente aburridos. • El fracaso no se debe ver como algo negativo, sino como pasos esenciales para conseguir una innovación exitosa. Simplemente es experimentación y repetición constante. Prueba y error • El fracaso es inevitable: con eso en mente empecemos con la diversión….
  9. 9. Loscasos denoéxito deDevSecOps “Los casos que veremos en la presentación están en alto nivel y modificados para no exponer información sobre clientes o conocidos“ Soy Troy Mcclure,tal vez me recuerden de presentaciones tales como…. Para esta ocasión usaremos CALMS, el acrónimo en inglés de Culture, Automation, LeanIT, Measurement and Sharing, que es el pilar de DevOps / DevSecOps, para representar los casos en una modalidad de historias de café. ¿Qué salió mal y qué tan malo fue? ¿Cuáles fueron las lecciones aprendidas?
  10. 10. #1:Mono=One, Rail =Rail… (Sharing &Culture) Algunas empresas no logran comprender DevSecOps y como adoptarlo En este primer caso de no éxito, luego de hablar con varios clientes y consultores amigos, vemos un número importante de empresas combinando sus equipos de desarrollo y operaciones de TI, pero la integración de DevOps con las operaciones de seguridad se está quedando atrás ya que no logran comprender como integrarse. ¿Pero porque sucede esto?
  11. 11. #1:Mono=One, Rail =Rail… (Sharing &Culture) Luego de profundizar la cuestión con varios clientes sobre este fracaso de adopción (Si, fracaso) llegamos a la conclusión que uno de los grandes inhibidores de la confianza del mundo de Dev hacia DevSecOps son los anti-patrones generado por la necesidad de encajar o vender del mismo ecosistema, y estos generan múltiples discursos y dudas al momento de la adopción.
  12. 12. #1:Mono=One, Rail =Rail… (Sharing &Culture) Veamos algunos ejemplos: • DevSecOps es un proceso/metodología. • DevSecOps y DevOps son diferentes. • Cambio de nombre de equipo / titulo profesional. • Crea una nueva unidad de DevSecOps para proyectos agiles. • DevSecOps vs SecDevOps. • Venden DevSecOps como una bala de plata. • La adquisición hostil.
  13. 13. #1:Mono=One, Rail =Rail… (Sharing &Culture) Visión Nerd del caso Esta falta de confianzasobre la integraciónde la seguridad,conocidacomoDevSecOps podría conducira problemasde seguridady perdidade datos más adelante. Dados los frecuentes ciclos de desarrolloqueson una característica inherente deDevOps,tener a seguridadcomo una entidadseparadapuederalentizarlos procesos y reducirla eficiencia. Comprometerla agilidad que estan centralen cualquierfilosofíade DevOpso conducira ventanasde tiempodondese puedenliberarvulnerabilidadesque no serán detectadashastael próximociclo de pruebasde seguridad. Entregarun productode mier….a nuestrosclientes.Si, así es, si tu productono tiene seguridad no tiene CALIDAD, ya que sus atributosson: simplicidad,consistencia/completitud,robustez, flexibilidad,performance,usabilidad,constructibilidad,escalabilidady a ver si adivinan? “Seguridad”
  14. 14. #1:Mono=One, Rail =Rail… (Sharing &Culture) Lecciones aprendidas Un patrón que recomendamos en los caso de nos éxito de adopción de DevSecOps y que hemos visto funcionar con eficacia en varias ocasiones, es que uno o dos miembros de la 'torre de marfil' de seguridad se integren y se ubiquen en un equipo de productos por un período temporal, alrededor de tres meses funciona bien. La regla 80:20 parece aplicarse aquí; Se necesita el 20% del conocimiento en el 80% de las situaciones, por lo que la cantidad requerida de conocimiento se contagia rápidamente cuando un pequeño grupo de humanos trabaja en estrecha colaboración.
  15. 15. #1:Mono=One, Rail =Rail… (Sharing &Culture) Lecciones aprendidas A veces la colaboración de un tercero para la realización de este cambio cultural es recomendable (la visión externa siempre es la mejor), puede ser privado o con la contribución de las comunidades. Gamification: Compartir es una de las mejores forma de generar nuevas costumbre y si se hace jugando aun mejor. (Modelado de amenazas con cartas) una de las mejores formas de integrar Dev y Sec. Nuestra recomendación final para compartir es el DOJO. Popularizado por Target , los dojos ponen uno o dos equipos de productos nuevos en un nuevo entorno, en el mismo lugar durante unas semanas y establecen y persiguen un objetivo agresivo mientras practican nuevas formas de trabajo en conjunto.
  16. 16. #2: Herramientitis aguda(Automation & Culture) Centrarse en herramientas puede ser una receta peligrosa El caso de no éxito por excelencia en el mundo de TI y en nuestra experiencia el caso mas complicado de remediarse en las grandes empresas o las mas tradicionales (Donde usualmente hay billetera). “Este proyecto fue para mejorar lo que veníamos haciendo mal, no para automatizar la caga….piiiiiiiiii” Frase en plena reunión de seguimiento del proyecto de un CISO de uno de los grupos de empresas mas grande de Latinoamérica, creo que esta frase es la representación fiel para este tipo de casos de no éxito, ustedes se preguntaran porque?
  17. 17. 17 Muchos clientes y conocidos empezaron sus proyecto de DevOps/DevSecOps por las herramientas. Pronto se dieron cuenta lo difícil que fue encontrar las herramientas adecuadas para los procesos de cada equipo de la organización porque cada equipo (desarrolladores, operaciones de TI, seguridad, etc.) querrá usar una herramienta específica para sus prácticas en DevOps, incluso si esto dificulta la tarea. #2:Herramientitis aguda(Automation & Culture) ¿Quien no tiene un vendor amigo en el placard? Además, surgen nuevas herramientas todo el tiempo, incluso hay herramientas que ayudan a integrar otras herramientas. (Todo un tablero nuclear)
  18. 18. #2:Herramientitis aguda(Automation &Culture) Visión Nerd del caso Empezar DevSecOps por las herramientasnos puede traer consecuenciasa medida que avanzael proyectoy nos damos cuentaque no sirve pero tenemos que seguir porque ya se compro o a veces seguir invirtiendo (El collar sale mas caro que el perro) No tener las herramientasadecuadaspuede evitar que los equipos no vean el máximo beneficio de sus esfuerzosreflejados en el famoso “Time to market” Muchosequipos de seguridad fallan en la integracióncon DevOps porque no entienden las herramientas,intervienen demasiado tardey rápido influenciados por vendors e interrumpen el flujo de trabajode ingeniería. Si seguridadno se comprende en el procesode ingeniería, y las herramientasque permiten a los equipos de DevOps moverse rápidamenteantesde sumarse en el pipelinePreparen la casillade correo para recibirfalsos positivos(O el canal de Slack según sea elcaso)
  19. 19. #2:Herramientitis aguda(Automation &Culture) Lecciones aprendidas No vamos a negar que la Automatización basada en herramientas no sea buena, pero no comiences tu estrategia DevSecOps discutiendo y seleccionando un montón de herramientas sin conocer la madurez de tu organización. Es probable que escuches que algunos proveedores afirman tener la herramienta perfecta (Homero Tools) para las prácticas de DevSecOps, pero eso es un cuento infantil. Lo mejor es adoptar un enfoque agnóstico y tener en cuenta que no existe una herramienta única que pueda cubrir todo lo que necesita.
  20. 20. #2:Herramientitis aguda(Automation &Culture) Lecciones aprendidas Muchas empresas han empezado sus proyectos implementando típicamente SONAR, OWASP ZAP, ETC… porque querían tener mayor visibilidad. Tene cuidado con lo que deseas, porque podrías conseguirlo. Luego se dieron cuenta que era la caja de pandora, no solo por los posibles falsos positivos en algunos casos, sino que nunca habían estimado el esfuerzo de implementación y gestión de las metricas / alertas. No dejes al equipo de DevOps fuera de las decisiones importantes acerca de las herramientas. ¡Hazlos tu compañero!
  21. 21. #3:TreeHouse ofZombies (Measurement &Culture) Backup Tapes… Backup Tapes… Backup Tapes… En este caso de no éxito nos basaremos en una auditoria a una empresa del rubro financiero, donde el equipo de DevSecOps explico al auditor de la entidad reguladora su proceso de backup automático en la nube utilizando almacenamiento de objetos (Podes pensar en un Amazon Glacier….) y algunas “cositasmágicas” mas, pero… La reacción del equipo fue una sorpresa cuando el auditor seguía preguntando por las cintas de backups de forma reiterativa tal como un zombie buscando cerebro, y la sorpresa fue aun mas cuando recibieron el informe con un desvió por no poder evidenciar las mismas.
  22. 22. A menudo vemos a las empresas implementar nuevas técnicas o practicas sin tener en cuenta todo el ecosistema del negocio y sus partes interesadas, este caso de no éxito nos muestra un fracaso compartido: El auditor clasico, persona que sale a regar cuando llueve hace todo basado en un checklist, mantuvo su postura equivocada de Business as usual is good enough. El equipo de auditoria interna de la entidad por no lograr ser coacho nexo entre las partes (Recuerdenque en una auditoria ambas partes deben ser competentes) Podemos observar esta anécdota donde el equipo DevOps le escribe una carta al auditor. http://dearauditor.org/ #3:TreeHouse ofZombies (Measurement &Culture)
  23. 23. #3:TreeHouse ofZombies (Measurement &Culture) Visión Nerd del caso No prepararse para el cambio cultural, a nivel empresa puede resultar en problemascon las partes interesadas del negocio y hasta perdidas de puntosen una auditoriade cumplimiento. Falta de cumplimiento o multas por no lograr mostrar métricas y evidencias objetivas para presentar a entidades regulatorias. Requisitostecnológicos cambiantes, en base a las nuevas demandas del negocio, cuando mal implementado puede generar perdida de visibilidadytrazabilidad. Se debe identificar los requisitos de seguridad y cumplimiento de antemano y automatizar la mayor cantidad posible. Hemos visto algunas organizaciones donde los registros de auditoría van directamente a una consola donde solo en auditor interno tiene acceso.Si no cambias la forma de pensar de tu auditorinterno no lograras hacerlo con el externo.
  24. 24. #3:TreeHouse ofZombies (Measurement &Culture) Lecciones aprendidas Existen innumerables métricas posibles en el mundo DevSecOps, para todos los gustos y colores. La decisión de qué métricas seguir se basa en gran medida en las necesidades del negocio y en los requisitos de cumplimiento. “Todo lo que se hace se puede medir, solo si se mide se puede controlar, solo si se controla se puede gestionar y solo si se gestiona se puede mejorar” ¿Usted cuenta con Backup? Siiiiii
  25. 25. #4:Entra cuchillo salen lastripas (Lean,Sharing &Culture) Muri & Muda Este caso usaremos los términos japoneses Muri y Muda, para analizarlo. “lo hemos hecho siempre así” Creo que si nos pagaran por cada vez que escuchamos esta oración seriamos millonarios, La organización estatal en cuestión estaba en pleno proyecto de implementación de un pipeline DevOps de punta a punta, y alguien se acordó que deberían sumar a seguridad (tarde pero seguro…) se imaginan que pudo pasar no? ¿Se acordaron? o porque necesitan un usuario de servicio o de base de datos ☺ Enamorarse del proceso te nubla la visión
  26. 26. #4:Entra cuchillo salen lastripas (Lean,Sharing &Culture) Si pensamos en Muri, podemos decir que la postura del oficial de seguridad y muchas de sus políticas eran ineficientes (Criptonita para Lean) planillas, políticas y tareas que se podían automatizar sin ningún esfuerzo pero su irracionalidad se daba por no ser parte del proyecto desde el inicio nunca se sintió parte de mismo, prefiere lasobrecarga(falla en la comunicación) Pero otra postura típica que vemos en las empresas con seguridad tradicional se acerca mas a MUDA. Actividades que no añaden valor desde la perspectiva del cliente y que tampoco son necesarias para operar el negocio y desde seguridad nos brinda la sensación de nunca llegar a la meta.
  27. 27. #4:Entra cuchillo salen lastripas (Lean, Sharing &Culture) Visión Nerd del caso No cumplir con los plazos del proyecto por los tiempos del modelo de seguridad tradicional (si el sprint mas común en las empresas es de 2 semanas)como le podes explicar a seguridad que su pentests tradicionales no pueden durar lo mismo que la totalidaddel sprint? Pasajeros no deseados en producción generandoun alto esfuerzo de regresiones y re-trabajo por culpa de conocidos – conocidos. Ser noticia por un fallo de seguridad.No se trata solo si testeamos lo suficiente si no como se aprende y se elimina los desperdicios en el proceso de cada prueba, como impulsamos a las demás áreas a contar con campeones de seguridad. Por ejemplo, cuando las aplicaciones se prueban menos de tres veces al año los defectos persisten más de 3.5 veces más que una organizaciónque prueba de siete a doce veces al año.
  28. 28. #4:Entra cuchillo salen lastripas (Lean,Sharing &Culture) Lecciones aprendidas No importa de que área seas “Sec,Dev o Ops” nunca pierdas el Foco en la mejora continua, recomendamos a todas las organizaciones a que se vuelvan experimentales para impulsar la innovación al tiempo que reducen el riesgo. El uso del "kata" de lean es clave para que esto se convierta en algo habitual, alejándose de una cultura de reuniones y planificación, hacia pequeñas y frecuentes mejoras incrementales. ¿Quien no tuvo reuniones para planificar reuniones? Necesitas una cultura que estimule y recompense a los colaboradores a pensar como intra-emprendedores. A realizar pruebas y aprender en el camino.
  29. 29. #4:Entra cuchillo salen lastripas (Lean,Sharing &Culture) Lecciones aprendidas Comenzamos por considerar la visión o dirección a largo plazo, consideramos el estado actual y decidimos nuestro próximo estado objetivo. Luego, hacemos PDCA entre los dos estados, planificamos, hacemos y verificamos, y luego actuamos en un ciclo continuo. Para mí, el * do * más importante para implementar la seguridad dentro del ciclo de vida de DevOps es la comunicación (Sharing)
  30. 30. Errores típicos • Demasiadas empresas posterganla implementación de iniciativas DevSecOps.Hastaque "sospecharono validaron" una violación de datosvinculada a componentesde código para responder con una campañapropia de seguridad de datosen todala empresa. Esperaron demasiado para iniciar: • Los desarrolladoresde software generalmenteson conscientesde la necesidad de una mayor seguridad de software,simplemente no actúan de acuerdocon esa conciencia, ”No tienen tiempopara gastar" en temas de DevSecOps. No hacer que la seguridad sea una prioridad: • Otra razónprincipal por la que las compañíasluchan con los despliegues de DevSecOpses que sacrificanla seguridad y la calidad por la velocidad. Sí, sacar productosal mercado rápidamente es una base fundamentalpara el éxito de la organización. Centrarseen la velocidaden lugar de la seguridad y la calidad:
  31. 31. Errores típicos • DevOps implica más que simplemente unirlos equipos de desarrolloyoperaciones; Es un proceso continuo de desarrollo yautomatización de software, que incluye seguridad,auditoría ycumplimiento. Muchas empresas cometen el error de no seguir sus prácticas de seguridad con mucha antelación. No involucrar al equipo de seguridad: • Una vez que tenga las herramientas adecuadas para las prácticas de DevOps,probablemente enfrentará un nuevo desafío fundamental:tratar de hacer que sus equipos utilicen las herramientas paraun desarrollomás rápido,pruebas automatizadas,entregacontinua ymonitoreo. ¿Tu cultura de desarrolloo de operaciones está lista para los cambios? No prepararse para el cambio cultural: • La seguridad es vista pormuchos como un problema que solo puede ser resuelto por consultores altamente calificados y remunerados (Ojala fuera así),si bien existe una necesidad absolutade estas habilidadesal revisararquitecturas yrealizarauditorías,no se requiere este nivel de experiencia cuando se trata de controles de seguridad (conocidos – conocidos)se pueden automatizar Hacerlo complicado por default:
  32. 32. Como evitar omitigar? Cambio de mentalidad: El software se ha convertido en la piedra angular de la innovación y el crecimiento económico, incluso expandiéndose a industrias tradicionalmente no tan tecnológicas. Como tal, es una prioridad para los profesionales de TI que se elimine la fricción falsa entre seguridad y desarrollo (Recuerden Calidad) Requisitos tecnológicos cambiantes: Claramente existe la necesidad de que la seguridad de las aplicaciones se convierta en un aspecto integral del proceso DevOps. Pero ahora que hemos superado la barrera mental, necesitamos trabajar en la tecnología para que pueda funcionar conjuntamente sin problemas.
  33. 33. Como evitar omitigar? Shift Left para "fallar rápidamente“: Inspeccionar la calidad del código lo antes posible es parte de la filosofía de DevOps. Debería comenzar cuando el desarrollador comience a codificar, la integración de la seguridad en el IDE para escanear el código a medida que se escribe no solo alerta a los desarrolladores sobre los problemas a medida que se presentan, sino que también concientiza. “Como nos gusta decir, el código sale seguro desde los dedos de los Dev’s” Asegúrate de que no haya falsas alarmas en el proceso: Como la industria ha aprendido, una tecnología que informa demasiados falsos positivos será ignorada y no será adoptada, pierde demasiado tiempo valioso. Eso puede ser tolerable si el problema de seguridad es real, pero es intolerable si el hallazgo es falso positivo.
  34. 34. Como evitar omitigar? Construí campeones de seguridad: Normalmente los equipos de seguridad son pequeños en comparación con los equipos de desarrollo. Los campeones de seguridad ayuda a extender el alcance de seguridad . La capacitación de alguien del equipo de aplicaciones hace posible que la seguridad esté siempre en la sala. Mantiene la visibilidad operacional: La seguridad no debe detenerse después de la implementación. Al igual que con otros aspectos de DevOps, una solución bien diseñada debe tener un ciclo de retroalimentación cerrado desde producción, en caso de problemas de seguridad.
  35. 35. 35 Conclusión “Desarrolla tu grito de guerra para la transformación de DevSecOps”
  36. 36. Próximamente Lo que vimos hoy es solo la punta del iceberg Desde DevSecOps Latam - Squad de Argentina estuvimos relevando con muchos clientes y conocidos sus casos de no éxito en un método académico y con un narrativa neutral sin exponer la confidencialidad o exponer información del testimonio. Los caso están basado en experiencias reales pero llevados a la ficción para que todos podamos disfrutar y aprender de la superación de otros. Si tiene casos que te gustaría contar para un futura versión del estudio no dudes en contactarnos con gusto y vemos de adaptarlo y compartirlo con la comunidad.
  37. 37. 37 SITIENESPREGUNTAS DURANTE LACHARLA INGRESAALCODIGO QREINGRESA ESTENUMERO #22617qrco.de/preguntar
  38. 38. Gracias!
  • GabrielCastro115

    Sep. 27, 2020

Luciano Moreira da Cruz y Christian Ezequiel Ibiri nos comparten en el #DragonJARCON 2020 una charla titulada "DevSec-Oops!... "Los casos de no éxito en DevSecOps" cuya descripción es: Aprendemos más de los fracasos que de los éxitos. Cuando algo sale como se esperaba, usamos ese proceso como una plantilla mental para futuros proyectos. El verdadero aprendizaje llega a través de la crisis. Si algo sale mal, tenemos que revolver, experimentar, hackear y seguir nuestro proceso. ----------------------------------------------------------------------------------------------- Youtube: DragonJARtv (http://bit.ly/DragonJARtv) Facebook: La.Comunidad.DragonJAR (http://bit.ly/DragonJARfb) Twitter: @DragonJAR (http://bit.ly/DragonJARt) Instagram: Dragon.JAR (http://bit.ly/DragonJARig) Discord: https://invite.gg/DragonJAR Blog: Comunidad DragonJAR (http://bit.ly/DragonJAR) -----------------------------------------------------------------------------------------------

Views

Total views

1,281

On Slideshare

0

From embeds

0

Number of embeds

1,167

Actions

Downloads

17

Shares

0

Comments

0

Likes

1

×