Keep CALMS and DevSecOps

KEEP
CALMS
AND
DevSecOps
Toda historia
tiene un inicio

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 y 9001:2015,
• Co-Fundador y Tribe lider de DevSecOps Argentina y Latam,
• Presidente del capítulo argentino de la CSA Cloud Security
Alliance.

Christian Ibiri
• CEO 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,
• Instructor acreditado de los cursos (DevSecOps
Foudation, DevSecOps Enginier y DevSecOps Master
Professional)
• Board Member - Argentina Chapter of Cloud Security
Alliance
• Seleccionado por la gente de peerlyst, como uno de
los "50 Influential DevSecOps Professionals“
• Co-Fundador y Tribe lider de DevSecOps Argentina y
Latam,

3
Toda historia tiene un inicio (LaaS)
….El cliente cambió
Cambiaron sus
expectativas.
No “compra” por
nuestro mensaje.
Busca
experiencias.
Después comunica
y multiplica su
experiencia por las
redes sociales.
….y es cada vez más exigente!
“La vida como servicio (LaaS): no más propiedades, solo la experiencia”

La propiedad es una carga, los clientes quieren experiencia.
Sleep as a Service (Airbnb,
Autonomous Car with beds)
Housing as a Service (Airbnb)
Mobility as a Service (Uber, Jump,
Waymo)
Software as a Service (Google Drive
etc..)
Hardware as a Service (Cloud
Computing, Cloud Storage, Drive,
Shadow PC)
Fooding as a Service (Greenchef,
Quitoque.fr, Deliveroo)
Work sa a Service (Gig economy: Uber,
Lyft, Fiver)
Hiring as a Service (IA, LinkedIn)
Social life as a Service (Facebook,
LinkedIn, Snapchat, Twitter)
Romance as a Service (Meetic)
Sex as a Service (Youporn, cam show,
online escort)
Casual sex as a Service (Tinder)
Music as a Service (Spotify)
Education as a Service (mooc,
Duolingo, podcast)
Memory as a Service (Wikipedia,
Iphone, Google, Neuralink)
Butler as as Service (Alexa, Ok Google)
Beliefs & political debate as a Service
(Cambridge Analytica, Facebook,
Twitter)
Intelligence as a service (Watson)
Health as a Service (IA, Watson, Health
App)
Style as a Service (Echo Look)
Security as a Service (PredPol)
Conversations as a Service (Chatbots,
Her)
Selling as a service (Chatbot e-
commerce, personalized UX)
Crime as a Service (Silk Road)
Trust as a Service (Blockchain)
“Las buenas experiencias generan nueva experimentación y demanda”

5
TIME TO MARKET
“Suban, los clientes quieren otro servicio para ayer”

ABURRIDO!!!!
¡TODOS YA SABEMOS ESTO! ¿POR QUÉ DEBERÍA DE
IMPORTARME?

EVOLUCION!!!
Simple…
La tecnología
y la sociedad
evolucionan
más rápido
que la
capacidad de
adaptación de
las empresas y
su
operaciones
“si, también
aplica a los de
seguridad”

Disrupción Digital
Nuestra vida definida por
la tecnología
“Empiezas con algo puro, algo
emocionante, y luego llegan los
errores, los compromisos” - Tony
Stark en Iron Man 3.
¿Como termina esta oración?
“Software”
“Nosotros creamos
nuestros propios
demonios”

DevSecOps Tools landscape
Static Analysis (aka
SAST)
• Looks at source code
• Data/control flow analysis
• Prone to false positives
• Rapid feedback for developers
• Code fix suggestions
Dynamic
• Instruments app (to varying degrees)
• Exercises app via UI/API
• Zero? false positives
• Hard to instrument?
• High false negatives
• Report is an exploit
• Sometimes hard to find code to
remediate
IAST
• Combine dynamic/static
• Good false
positives/negatives
• Immature but getting there
Runtime Application
Security Protection
(RASP)
• Reports on “bad”
behavior
• Can abort transaction or
kill process to protect
Fuzzing
• Instruments app (to varying degrees)
• Sends unexpected input at API
• Looks at response and instrumentation
output
• Great for testing protocols like SIP
• Good for REST APIs
• Potentially long run times
• Hard to find code to remediate
Software
Composition Analysis
(SCA)
• Identifies dependency
and version
• Checks CVE/NVD + …
for reported
vulnerabilities
• Proposes version/patch
to remediate
• Checks license vs
policy
• Runs fast
• Some have firewall
mode
Seguro te ofrecieron alguna tool como la gallina de huevos dorado….

¿Hay alguna guía o modelo?
"¿Hay un marco para ¿Adopción de DevSecOps?" Ahora hay buenas razones para esta pregunta y una es que
muchas personas de operaciones empresariales conocen marcos como ITIL y Cobit. La respuesta a esa
pregunta es: ”CALMS”
Si nunca has oído hablar y no tienes idea de lo que podría
ser " CALMS ", debes saber que esta es la línea que separa
a un joven "Padawan" de un Maestro Jedi. Muchos ya
conocen los beneficios proporcionados por el concepto
DevOps y su importancia en el crecimiento sostenible de
cualquier negocio, pero pocos logran forzar
magistralmente la fuerza, aprovechando todo su
potencial.

21
DEVSECOPS y CALMS
Originalmente acuñado CAMS por John Willis y Damon Edwards después del primer evento DevOpsDays con sede en EE. UU. Celebrado en
Mountainview California en 2010, . Jez Humble luego agregó la L, para Lean, haciéndolo CALMS.

¿Que es CALMS?
CALMS es un acrónimo en inglés de Culture, Automation, LeanIT, Measurement
and Sharing. El término apareció entre 2008-2009 de la mano de John Willis y
Damon Edwards que acuñaron el acrónimo CAMS y en 2010, fue ampliado a
CALMS por Jez Humble coautor del "DevOps Handbook" , pero otras personas
participaron en el proceso de creación del marco, como Jene Kim
La idea en su concepción era romper la barrera existente entre los
Desarrolladores y la Operación, que a menudo tenía gerentes, objetivos, plazos e
indicadores totalmente diferentes. Debido a la constante fricción entre los dos
sectores, se creó el término DevOps .
Cada letra de CALMS representa un tema que debe ser trabajado en su
organización para implementar una verdadera cultura de DevOps en su empresa.

DevSecOps y CALMS
DevSecOps es el principio de que todos los equipos de tecnología son responsables de la seguridad cibernética en
una organización: la propiedad no está únicamente en la puerta de los profesionales y equipos de seguridad. La idea
de que la ciberseguridad es el trabajo de todos surgió en parte porque las habilidades de ciberseguridad están
limitadas, dentro del mercado en su conjunto y dentro de una organización específicamente.
Un informe reciente de (ISC)2 afirma que hay una escasez de personal de
ciberseguridad global de tres millones y que esto está aumentando. Vemos
la misma tendencia con las organizaciones con las que trabajamos en
Argentina y Latinoamérica.

DevSecOps y CALMS (Culture)
La limitación se ve exacerbada por el diseño organizacional
tradicional
Tener equipos de seguridad separados de Ops crea tensión
("no, no y no"), transferencias y retrasos en el proceso.
Una cultura de DevSecOps se define principalmente, por la
alta confianza. (altos niveles de confianza = bajos niveles de
fricción)
Es difícil hablar de cultura, pero más difícil para nosotros los
de tecnología, ya que estamos más acostumbrados hablar
en bits y bytes que en emociones y sentimientos.

Para fomentar la confianza, necesitamos crear un lugar de seguridad
psicológica, un lugar donde las personas puedan ser sinceras y
experimentales sin temor a las consecuencias, especialmente si
experimentan una falla
Muchos líderes tradicionales, luchan con esta tolerancia a fallos.
Particularmente cuando su trabajo es administrar infraestructura críticas “es
entendible que vean una falla como catastrofe.” El fracaso es el primer
paso para la innovación”
Pero hay muchos matices de falla: desde un defecto en una rama de
desarrollo detectado durante la integración continua hasta un sistema
inactivo durante horas para todos los usuarios globales.
Cuando estamos en una situación, como estamos con seguridad, donde el
conocimiento, las habilidades y la experiencia son una limitación: parte de
la solución es mejorar el aprendizaje, no queremos una cultura de la
culpa, donde la gente tenga miedo a aprender por el miedo a fallar.

Cultura de la organización La mayoría de las organizaciones se ajustan a alguno de estos modelos
Patológico Burocrático
Baja cooperación Cooperación modesta
Disparan al Mensajeros Mensajeros descuidados
Responsabilidad eludida Responsabilidades estrechas
Cooperación desalentada Cooperación tolerada
El fracaso lleva al chivo
expiatorio
El fracaso lleva a la justicia
La novedad es minimizada La novedad conduce a
problemas
Generativo Practicas
Alta cooperación Equipos multifuncionales
Mensajeros entrenados Postmortems sin culpa
Los riesgos se comparte Responsabilidad compartida
Cooperación alentada Romper los silos
El fracaso lleva a la
investigación
Aprender de nuestros errores
Novedad implementada Tiempo de experimentación

"La cultura come la estrategia en desayuno, almuerzo o cena“ Depende quien haya traducido ☺
Una cita de Peter Drucker y hecha famosa por Mark Fields, presidente de Ford, es algo que suena muy
cierto hoy en día. Es algo que todos "sentimos" que es verdad, no solo por las estadísticas que lo
confirman, sino porque intuitivamente sabemos que sin una verdadera alineación de sus miembros, una
organización no es nada.

DevSecOps y CALMS (AUTOMATION)
En el The DevOps Handbook, Christopher Little diciendo:
"La automatización es para Dev/Sec/Ops como los telescopios son para la astronomía".
Nos encanta esta frase y la usaremos para la siguiente analogía.
• Las estrellas: son los clientes que estamos mirando o los resultados de valor que queremos ofrecerles.
• Los astrónomos: somos nosotros, los practicantes de DevOps.
• El planeta: es nuestra organización
• Los otros planetas: son nuestros socios y competidores.
• Los meteoritos: son amenazas e incidentes con los que tenemos que
lidiar.
• Los telescopios: son esenciales para permitirnos ver, recopilar datos y
comentarios y acelerar la entrega del cambio.

Pero no podemos, y no debemos, tratar de automatizar todo en la vida. Pasará bastante tiempo antes de que
todos podamos ir a tumbarnos en la playa, mientras las máquinas hacen todo el trabajo….
Pero podemos AUTOMATIZAR para dejar de hacer TRABAJOS REPETITIVOS Y ABURRIDOS y romper las
restricciones que vemos en nuestro trabajo: la seguridad, que es una de las restricciones clave cuando
pensamos en proyectos Agiles.
Todo esto se debe considerar en el
contexto de la entrega continua
(CD), es decir, la práctica de tener
siempre el software en un estado
liberable y seguro.

AST (Application Security testing tools)
Esta pirámide representa clases o categorías de Application
Security testing tools .
Application
Security testing
Orchestration
(ASTO)
Correlation Tools
Test-Coverage
Analyzers
Application
Security testing as
a Service (ASTaaS)
Mobile Application
Security testing
(MAST)
Interactive
Application
Security testing
(IAST)
Dynamic
Application
Security testing
(DAST)
Software
Composition
Analysis (SCA)
Database Security
Scanning
Static Application
Security testing
(SAST)
DAST
SAST
IAST
SCA
RASP
ASTO

DevSecOps y CALMS (LEAN IT)
¿Cómo LeanIT mejora el rendimiento?
Lean tiene como principal objetivo la eliminación de los “desperdicios” con el fin de ofrecer al cliente la
mejor de las calidades con un servicio.
En DevSecOps se utiliza el pensamiento
optimizado y de flujo de valor para garantizar
que la seguridad no cause perdidas o retrasos en
el tiempo del ciclo de vida, que no sea una
limitación y no interrumpa el flujo completo.

Se trata fundamentalmente de crear una cultura de aprendizaje constante eliminando desperdicios o
demoras. Esto está en contraste con la naturaleza prescriptiva y muy planificada del pasado en seguridad.
En lugar de tratar de reunir todos los requisitos y comprender todos los casos de uso, y luego decirle a la
gente qué hacer, aprendemos a medida que avanzamos.
DevSecOps ya nace tomando la cultura de aprendizaje, invitando explícitamente a seguridad al juego de
ofrecer valor al cliente más rápido.
En la era del “Time to Market” la seguridad ya no puede mantenerse en secreto y ser vista
como una barrera para la entrega, sino que debe adoptar la automatización, el aprendizaje,
la medición, el intercambio y aprender a convertirse en un acelerador.

Existen varias herramientas de DevSecOps que pueden ayudar con la implementación de “LEAN” Estas tools
ayudan en la optimización del flujo de la idea a la realización, un marco de conectividad que le quita el dolor de
escribir y gestionar las integraciones y visualizar los tiempos de espera y los ciclos. nos muestra dónde están los
cuellos de botella.
En nuestra experiencia recomendamos Value Stream Mapping, como parte de su viaje a Lean ya que brinda
métricas increíblemente poderosas, pero difiere de las tools ya que no es manejado por datos sino por las ideas de
la gente.
No es que esto sea bueno o malo, pero una combinación de hombre y
máquina puede funcionar mejor en el clima de negocios que tenemos hoy
en día.
“Los seres humanos todavía necesitan interpretar las
tendencias y, en su mayoría, decidir cómo actuar sobre la
base de lo que los datos les dicen. Y a menudo los datos aún
no están disponibles.”

Necesitas una cultura que estimule y recompense a los empleados a pensar como intra-emprendedores. (no
tener miedo a la falla o al incidente)
Imagina que Sony no le hubiera dejado a Ken Kutaragi trabajar en su idea...
O que Google no dejara que Paul Buchheit trabajara en su idea...
En 1975, un empleado de Kodak inventó la cámara digital. Sus jefes le hicieron esconderla.

DevSecOps y CALMS (Measurement)
Medición para ahorrar tiempo y evitar infracciones.
Vimos que lean se preocupa por identificar y eliminar los errores de la línea de
producción, por lo que la métrica que más asociamos con ella es el tiempo total
del ciclo.
Es super eficaz para mostrarnos cuándo nuestro modelo de seguridad está
actuando como un cuello de botella, pero ¿qué otras medidas son útiles en el
mundo de DevSecOps?
Esencialmente, queremos resultados de valor en las manos de nuestros clientes
lo más rápido posible y este es el elemento clave de un caso de negocios de
DevSecOps, sin comprometer al mismo tiempo la integridad del sistema,
rendimiento y estabilidad.
Entonces "medir todas
las cosas" es el grito de
guerra (y un gran
meme).

Los requisitos de seguridad están incorporados en el backlog de desarrollo.
No se pierde tiempo esperando aprobaciones o las pruebas de seguridad.
Las pruebas de seguridad están integradas en el pipeline de CI/CD
Las pruebas de seguridad no requieren contacto ni tiempo de espera
Las acciones IT Ops/Sec Ops están disponibles como autoservicios homologados
para los DEVs
Si seguimos este patrón significa que la seguridad no representa desperdicio en el
flujo de valor, por lo que el tiempo de ciclo se optimiza desde esta perspectiva de
LEAN
En DevSecOps queremos seguridad incrustada en el pipeline del flujo de valor. Eso significa que:

DevSecOps no es otra cosa que, un conjunto de patrones de formas de trabajo que mejoran el
desempeño organizacional.
Entonces, ¿cómo medimos la eficacia de DevSecOps y la entrega de valor? ¿Cómo determinamos
cuándo DevSecOps ya no es una 'cosa’ ?
Existen innumerables métricas posibles en una
plataforma DevSecOps.
La decisión de qué métricas seguir se basa en
gran medida en las necesidades del negocio y
en los requisitos de cumplimiento.
Para facilitar esta visión podemos verlas en
dos grupos:
• Métricas de alto valor
• Métricas de apoyo

Métricas de alto valor
Estas métricas deben implementarse primero en una nueva plataforma. No todas las plataformas tendrán estas métricas
disponibles de inmediato, pero un entorno completamente maduro generalmente tendrá todas estas métricas disponibles.
Métrica Descripción
Frecuencia de implementación Número de implementaciones en producción en un período de tiempo determinado
Tiempo de cambio (para aplicaciones) Tiempo que transcurre entre la confirmación de un código y el despliegue en producción de dicho código
Volumen de cambios (para aplicaciones) Número de historias de usuario desplegadas en un plazo determinado
Tasa de fracaso de los cambios Porcentaje de implantaciones en producción que han fracasado
Tiempo medio de recuperación (MTTR) Tiempo entre un despliegue de producción fallido y la restauración completa de las operaciones de producción
Disponibilidad Cantidad de tiempo de actividad/tiempo de inactividad en un periodo de tiempo determinado, de acuerdo con el SLA
Volumen de solicitudes de los clientes Número de problemas comunicados por los clientes en un periodo de tiempo determinado
Tiempo de resolución de problemas del cliente Tiempo medio para resolver un problema informado por el cliente
Time to value
Tiempo que transcurre entre la solicitud de una función (creación de una historia de usuario) y la realización del valor
comercial de esa función
Time to ATO Tiempo entre el inicio del Sprint 0 y la consecución de un ATO
Hora de parchear vulnerabilidades
Tiempo entre la identificación de una vulnerabilidad en la plataforma o aplicación y la implementación exitosa de la
producción de un parche

Métricas de apoyo
Estas métricas proporcionan información útil y se recomienda que las métricas en esta categoría se implementen después
de que se hayan implementado las métricas de alto valor.

https://riesenfeld.com.mx/bsc-para-devsecops

En resumen, las mediciones DevSecOps buscan hacer tres cosas:
Mostrar tiempo / costo adicional en el flujo de cadena de valor para
actividades de seguridad
Evite todas las infracciones o tenga remedio casi instantáneo
Optimice y automatice todas las actividades de seguridad a través
de la canalización de extremo a extremo
Cuando se logran estas tres cosas, ya no necesitamos hablar sobre
DevSecOps . Es solo DevOps, o incluso mejor, solo la forma de
trabajar

DevSecOps y CALMS (Sharing)
El poder de Dojos y ChatOps en el intercambio de conocimientos de seguridad
En resumen, DevSecOps tiene dos impulsores principales: La seguridad es una restricción en la mayoría de las
organizaciones y ha sido una ocurrencia tardía en el mundo de DevOps.
Como vimos antes podemos abordar esta restricción con las prácticas de
automatización, pero también esta el enfoque cultural para abordar este
problema también, y todo se centra en el intercambio efectivo de
conocimientos.
“DevOps busca optimizar el flujo de resultados de valor
desde la idea hasta la realización mediante la eliminación de
cuellos de botella y la amplificación de la retroalimentación”

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.
Los expertos en seguridad pueden pasar a más equipos de productos: el conocimiento que
habrán adquirido durante este proceso acelerará el intercambio de conocimientos en los
nuevos equipos que visiten.
Esto requiere tener seguridad a bordo con la visión de DevOps y necesita algunas
personas de mente abierta dispuestas a cambiar sus prácticas de trabajo cotidianas.
El liderazgo tiene que ponerle un sello de goma y tenemos que hacer un intercambio entre
"no podemos encontrar tiempo para ahorrar tiempo"

Estos ágiles, DevOps, defensores de DevSecOps, llámalos como quieras,
también pueden ser alentados a hacer otras cosas para ayudar a compartir el
conocimiento.
Por ejemplo, podrían comenzar una comunidad DevSecOps de interés / práctica
o gremio donde inviten a las personas (cualquier persona interesada) a
participar en talleres, reuniones, espacios en línea o incluso hackatones y
compartir sus ideas de esa manera.
La mayoría de las organizaciones con las que trabajamos usan algún tipo de
wiki, ya sea Confluence o Teams u otra cosa. Sin embargo, un error común en
este tipo de plataformas es que se vuelven extensas y difíciles de navegar si no
se mantiene en el tiempo.

Nuestra recomendación final para compartir en DevSecOps es el
dojo. Popularizado por Target , los dojos ponen uno o dos equipos
de productos nuevos (ish) en un nuevo entorno con PYME (como
la seguridad) en el mismo lugar durante unas semanas y
establecen y persiguen un objetivo agresivo mientras practican
nuevas formas de trabajo.
Disfruté especialmente la charla de Capital One de DevOps
Enterprise Summit London en 2018, donde John, el propietario
del producto, establece el tono para la seguridad psicológica, con
la declaración 'las cosas se van a poner desordenadas' que nos
lleva al círculo completo en la primera publicación en este serie,
sobre los elementos culturales de DevSecOps.
https://itrevolution.com/devops-dojo-captial-one/
https://dojo.target.com/

CALMS MATURITY MODEL
Práctica Cultura Automatización Soporte/Apoyo Medidas Comunicación
NIVEL
5:
OPTIMIZACIÓN
El "POR QUÉ" en las
organizaciones, está
enfocado y sostenido en el
cliente, día a día junto con
la tecnología involucrada y
apropiada.
Los procesos empresariales
de soporte tecnológico
tienen un esfuerzo mínimo
de TI. La innovación y
soporte de flujos de valor
son automatizados.
El enfoque está en el
cliente, la resolución de
problemas es una norma, el
"management coaching" y
el aprendizaje son
continuos.
Medición del valor de las
ideas para su futura
realización.
Intercambio asertivo de
conocimientos y
fortalecimiento individual.
NIVEL
4:
NATURALIZACIÓN
La cultura es vista como
un activo a gestionar. Se
establece la capacidad
para adaptar cambios
empresariales según las
necesidades.
La automatización respalda
los objetivos y procesos
comerciales, no solo los
procesos tecnológicos.
La atención al cliente como
pauta, el personal está
comprometido para apoyar
la innovación y la mejora
constante.
Monitoreo desde el enfoque
del cliente hasta el flujo de
valor, con una
retroalimentación adecuada
y ciclos de mejoras.
La comunicación se dirige
hacia la cooperación y la
mejora basada en
indicadores y objetivos
acordados.
NIVEL
3:
EVOLUCIÓN
La actitud y el
comportamiento deseados
se identifican, la gerencia o
los entrenadores
comienzan a apoyar los
cambios.
Los procesos están
automatizados y centrales
en todo el ciclo de vida del
flujo de valor. La tecnología
es asignada a las áreas o
procesos de negocio de los
silos.
Comienza el interés hacia la
atención del cliente. El
personal se capacita para
aprender en un entorno "sin
culpa/faltas".
Monitoreo de recursos
(personas, procesos,
herramientas, proveedores)
vinculados a indicadores del
desempeño esencial.
Existen algunas alertas e
incrementos.
La colaboración, la toma de
decisiones compartidas y la
rendición de cuentas
comienzan y se chequean
para encontrar formas de
avanzar.
NIVEL
2:
MEJORAS
Estar al tanto de los
aspectos culturales que
pueden ayudar u
obstaculizar el valor
centrado en el cliente. La
ayuda solicitada o la
gestión lidera los esfuerzos
del cambio.
Los procesos de
automatización del silo
permiten una integración
mínima o una comunicación
de flujo de valor cruzado.
El organigrama tradicional
empieza a ser cuestionado,
se considera cambiar la
estructura organizativa del
enfoque del valor o del
producto.
Las medidas se centran en
el proyecto, las decisiones
son reactivas o no son lo
suficientemente "alertas".
Comienzo de la gestión
visual, la cual no está
integrada para permitir el
conocimiento del flujo de
valor o el intercambio de
decisiones.
NIVEL
1:
COMIENZO
La estrategia no está
alineada, (roles de
personas, KPls,
herramientas, valores)
impactando así en el
negocio diario.
No hay automatización por
lo que varias herramientas
similares no están
integradas.
El enfoque es
reactivo/irreflexivo en la
resolución de problemas,
hay poca o nula
participación directa en la
gestión, el aprendizaje es
ad-hoc.
Toma de medidas
vanidosas, no reactivas o
simplemente informes
básicos, estas medidas no
guían el desarrollo, el
cambio o mejora alguna.
Mala o escasa comunicación
y coordinación. Muchas
reuniones e informes no son
leídos o tenidos en cuenta.

Tres maneras de cerrar la brecha cultural
1 2 3
Codificar y recompensar los
comportamientos correctos
Desarrollar habilidades blandas Valore la seguridad tanto como la
velocidad de transformación
digital
• Para cambiar el comportamiento,
cambiar hábitos
• Introducir patrones en todo el
entorno para que con el tiempo, las
personas se acostumbre a trabajar
de cierta manera
• Con el tiempo, su mentalidad
también se adapta y la cultura
comienza a cambiar
• Desarrollar habilidades más suaves
será esencial
• Las organizaciones también podrían
considerar la búsqueda de tipos de
personalidad específicos que no
tengan las habilidades técnicas
perfectas para DevSecOps, pero
podrían ser
• No todos los que trabajan
actualmente en DevOps y equipos de
seguridad se adaptarán
• DevSecOps reposiciona la seguridad
más arriba en la cadena de valor
• Refuerza esto en toda la organización
• Asegúrese de que DevSecOps se
incluye en los casos de inversión para
la transformación
El pensamiento de sistemas requiere un enfoque diferente para las habilidades
51

Tres maneras de cerrar la brecha cultural
1 2 3
Codificar y recompensar los
comportamientos correctos
Desarrollar habilidades blandas Valore la seguridad tanto como la
velocidad de transformación
digital
• Para cambiar el comportamiento,
cambiar hábitos
• Introducir patrones en todo el
entorno para que con el tiempo, las
personas se acostumbre a trabajar
de cierta manera
• Con el tiempo, su mentalidad
también se adapta y la cultura
comienza a cambiar
• Desarrollar habilidades más suaves
será esencial
• Las organizaciones también podrían
considerar la búsqueda de tipos de
personalidad específicos que no
tengan las habilidades técnicas
perfectas para DevSecOps, pero
podrían ser
• No todos los que trabajan
actualmente en DevOps y equipos de
seguridad se adaptarán
• DevSecOps reposiciona la seguridad
más arriba en la cadena de valor
• Refuerza esto en toda la organización
• Asegúrese de que DevSecOps se
incluye en los casos de inversión para
la transformación
El pensamiento de sistemas requiere un enfoque diferente para las habilidades
52

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

Keep CALMS and DevSecOps

Más contenido relacionado

La actualidad más candente (20)

Similar a Keep CALMS and DevSecOps (20)

Más de Luciano Moreira da Cruz (15)

Último (20)

Keep CALMS and DevSecOps