Devsecops superstar un movimiento masivo

Un movimiento
masivo
DEV OPS
SEC

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.

Actualidad
2020 1Q COVID 2020 2 y 3Q Adaptación 2020 3 y 4Q Largas jornadas
2021 1 y 2Q Ansiedad 2021 3 y 4Q Vacunación 2022 N Qs Nuevo paradigma

Antes de DevOps, existía Agile
Para responder verdaderamente a la pregunta, "¿Qué es DevOps y de dónde vino?" primero
tendremos que hablar sobre Agile.
La palabra "ágil" se usa a menudo para describir a los atletas y bailarines que se mueven con
rapidez, gracia y precisión.
En un contexto de desarrollo, Agile se refiere a la metodología de desarrollo de software ágil que
surgió de la necesidad de mejorar el método tradicional de "cascada" en el que cada paso cae en
cascada desde el paso anterior.
Waterfall no se adapta a los requisitos cambiantes una vez que un proyecto está en marcha, y las
pruebas comienzan después de que se completa el desarrollo, lo que resulta en tiempos de
entrega lentos y una alta probabilidad de errores.
Esencialmente, Agile aborda la necesidad cada vez mayor de velocidad y precisión en el desarrollo
y la implementación de software.

El origen de DevOps
¿Cómo empezó todo?
• Para que podamos comprender totalmente, tenemos que ir al corazón de esta historia. El movimiento DevOPs no comenzó
en un solo lugar, hay muchos lugares que dan pistas sobre el origen del término, pero al parecer la información más concreta
sobre el origen de este movimiento nos lleva al año 2008. Nasce el término Infraestructura Ágil con foco en el desarrollo ágil.
• luego fue el foro de debate europeo con el nombre agile-sysadmin que empezó a abordar el tema con propiedad, con eso
ayudaron a colocar los primeros ladrillos en el puente que haría la conexión entre los developers y sysadmins. Un
participante de este foro Patrick Debois (@patrickdebois) the godfather, era uno de los más activos, también un gran
entusiasta del tema.
• El término DevOps fue creado solamente de hecho en 2009 durante la Conferencia Velocity da
O’Reilly, en esta conferencia John Allspaw (Etsy.com) y Paul Hammond (Typekit) presentaron el
trabajo 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr, ver en el link abajo los slides de
la presentación

SDLC Tradicional
• Recopilar los requisitos
del cliente/consumidor
Requirements
• Diseñar el software de
acuerdo con los
requisitos
Design
• Implementar el diseño
acordado
Implementation
• Desplegar el software en
la producción
Deploy
• Mantenimiento del
software en producción
Maintain

Secure SDLC
Training
Requirements Regulatory compliance Policies Industry Requirements
Design Threat Modeling Architecture Reviews Security Advisements
Implementation Code Reviews IDE Tools Training
Testing Static Analysis Dynamic Testing Interactive Testing
Deployment Hardening guidelines Network assessments
Maintenance Regulatory compliance Third party Pentesting Industry Requirements
En el Secure
SDLC,
se adapta la
seguridad en
cada
fase del modelo

Muro de la incertidumbre
Enfoque en cascada
DEV TEAM
REQUERIMIENTOS DEL NEGOCIO

Muro de confusión
DEV TEAM OPS TEAM

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 es...

Ciclo DevOps
Operate
(Monitor)
Plan
(Requirement)
Code
(Source Code
Management)
Build
(CI Tool)
Release
(Artefact Management)
Deploy
(CD Orchestration)
#1 Plan
Requisitos de la empresa y
planificación del Sprint en
función de los requisitos.
#2 Code
Codificar utilizando la gestión
del código fuente (SCM) y
desarrollar el código y las
pruebas, lo que la empresa
quiere.
#3 Build
Construir el código en un
artefacto desplegable y
probarlo en el entorno de
preproducción
#4 Release
Liberar el artefacto como listo
para la producción después de
la aprobación de los cambios
#5 Deploy
Despliegue del artefacto en el
entorno de producción..
#6 Monitor
Supervisar el rendimiento, la
seguridad y el cumplimiento de
la aplicación
Continuous Deployment
/ Delivery(CD)
Continuous
Integration (CI)

Muro del cumplimiento
DEVOPS TEAM INFO/APP SEC

Seguridad esta en desventaja
DEV / OPS / SECURITY
100 / 10 / 1

DevSecOps es...
La seguridad forma parte de
DevOps y antes de eso ya era
una atributo de calidad

DevSecOps Beneficios
Resiliencia: DevOps ayuda a las organizaciones en el diseño e
implementación de sistemas resistentes.
Flexibilidad: Con la tecnología en constante cambio, las empresas tienen
que ser flexibles y rápidas para ofrecer valor a sus clientes, de lo contrario
corren el riesgo de perder el negocio.
Velocidad: La velocidad es una ventaja competitiva y DevOps ayuda a salir al
mercado más rápido.
Fiabilidad: Los clientes necesitan sistemas más fiables y disponibles. DevOps
reduce las tasas de fallo y proporciona una retroalimentación más rápida
Automatización: La automatización ayuda a reducir la complejidad de los
sistemas modernos y puede escalar según las necesidades

Personas, procesos y tecnología
Personas
• Squads autónomos
• Equipos multifuncionales
• Personas con habilidades cruzadas
• Comportamiento del TDD
• Cambio revisado por pares
• Mob programming
• Financiación de la capacidad
• Product Owner backlog
• refinamiento
Procesos
• Enfoque incremental
• Cadencia de sprint
• Pruebas continuas
• TDD/BDD
• Integración continua
• Pruebas realizadas en el sprint
• Liberación autónoma
• Seguridad integrada
Tecnología
• Pruebas automatizadas
• Entrega/despliegue continuo
• Automatización de lanzamientos
• Aprovisionamiento de entornos
basados en la nube
• Entornos de prueba similares a los de
producción

CALMS & DEVSECOPS
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/

Cloud Legion / DevSecOps Framework

STAGE: PRE-COMMIT
Objetivos
Actividades De Seguridad Antes De Comprobar El Código En El Servidor De Control De Versiones
Tools
THREAT MODELING / ATTACK MAPPING: Microsoft Threat Modeling Tool (O), OWASP Threatdragon (O)
IDE SECURITY PLUGINS: Devskim (O), Findsecuritybugs (O), Puma Scan (L), Sonarlint (O) Veracode (L)
PRE-COMMIT HOOKS: Git-hound (O), Repo-supervisor (O), Thoughworks Talisman (O)
PEER CODE REVIEWS: Gerrit (O), Gitlab Merge Request, Tfscodereviewflow (O)
Role
Threat Modeling / Attack Mapping: All
IDE SECURITY PLUGINS: Developer, Security Analyst
PRE-COMMIT HOOKS: Developer, Security Analyst, Testers & QA
PEER CODE REVIEWS: Security Analyst, Functional Analyst, Testers & QA
Salidas
THREAT MODELING / ATTACK MAPPING: Modelo De Riesgo Real, Basado En El Flujo De La Aplicación A Desarrollar, Imput Para Crear El Security Test Plan
IDE SECURITY PLUGINS: Alertas Y Notificaciones Con Hallazgos De Seguridad En La Etapa De Codificación, Con Recomendación Y Referencias De Vulnerabilidades
PRE-COMMIT HOOKS: Resultados En Tiempo Real Sobre La Calidad De La Seguridad Del Código Cuando El Desarrollador Está Escribiendo El Código
PEER CODE REVIEWS: Tasa De Inspección: La Velocidad Con La Que Se Realiza Una Revisión
Tasa De Defectos: El Número De Errores Encontrados Por Hora De Revisión
Densidad De Defectos: El Número Medio De Errores Encontrados Por Línea De Código

STAGE: PRE-COMMIT
Actividades
THREAT MODELING / ATTACK MAPPING:
Comenzar con una evaluación de riesgos de alto nivel para los nuevos sistemas/servicios
• Clasificar los datos: requisitos legales y de cumplimiento, sensibilidad, etc.
• Centrarse en los riesgos de la plataforma, el lenguaje y el marco: ¿el equipo utiliza
herramientas bien conocidas o algo nuevo, novedoso?
• Determine una clasificación de riesgos y los siguientes pasos: modelado de amenazas,
requisitos de puertas de control, formación en seguridad...
Vuelva a realizar la evaluación de riesgos si/cuando el equipo realice un cambio importante en
el diseño o en los datos
• Cuestionario de riesgo de PayPal para nuevas aplicaciones/servicios
• Modelo de evaluación rápida de riesgos (RRA) de Mozilla
• Elevación de privilegios de Microsoft
Modelado de amenazas iterativo y ligero basado en el riesgo: al principio del diseño, o cuando
se realicen cambios importantes (Examinar los límites de confianza y las suposiciones en la
arquitectura)
Plantee estas preguntas cuando vaya a realizar cambios:
• ¿Está cambiando la superficie de ataque (nuevos puntos de entrada/salida, nuevo rol de
usuario...)?
• ¿Está cambiando la pila tecnológica o los controles de seguridad de la aplicación?
• ¿Está añadiendo datos confidenciales/sensibles?
• ¿Han cambiado los agentes de las amenazas? ¿Nos enfrentamos a nuevos riesgos?
IDE SECURITY PLUGINS:
La exploración inmediata e incremental en el IDE de cada desarrollador capta los errores de
seguridad a medida que el desarrollador cambia o guarda el código
• La seguridad se convierte en parte del flujo de trabajo de ingeniería
• Desplazamiento lo más a la izquierda posible en la cadena
• Debe tener bajas tasas de falsos positivos (importante)
• Ejecutar reglas de alto valor y desactivar las reglas ruidosas que distraen a los ingenieros
PRE-COMMIT HOOKS:
Ejecutar revisiones de seguridad antes de enviar el código al repositorio: (ejecutar
automáticamente scripts en diferentes puntos de los flujos de trabajo)
• Local: pre-commit, prepare-commit, commit, post-commit, post checkout, pre-
rebase
• Invoque escaneos adicionales de la CLI / comprobaciones de seguridad antes de
que el código llegue a la integración continua
• Utilizar para la gestión de secretos, claves, etc.
• Es importante tener en cuenta que estas protecciones del lado del cliente pueden
ser deshabilitadas por los ingenieros (el propietario del repositorio puede
alterar/desinstalar los hooks- así que los hooks no pueden ser forzados)
PEER CODE REVIEWS:
La disciplina de las revisiones de código por pares es una práctica de ingeniería
fundamental en DevSecOps
• Revisar la corrección funcional (especialmente en el código de alto riesgo) una
codificación defensiva
• Asegúrese de que el código aprovecha las capacidades del marco de trabajo seguro
y las bibliotecas de seguridad
• Tenga cuidado con los secretos hardcodeados, las puertas traseras y el cifrado
manual.
• Aproveche el análisis estático (SAST) para aplicar las buenas prácticas y detectar los
errores comunes de seguridad/codificación
PRECAUCIÓN: Los desarrolladores necesitan formación en codificación segura, para
saber qué buscar

STAGE: COMMIT (CONTINUOUS INTEGRATION)
Objetivos
Actividades de seguridad antes de comprobar el código en el servidor de control de versiones
Tools
STATIC CODE ANALYSIS: HP Fortify (L), FindSecurityBugs (O), NodeJsScan (O), Phan, Sonarqube (O/L), Veracode (L)
SECURITY UNIT TESTS: Junit (O), xUnit (O)
CONTAINER SECURITY / IAAC ANALYSIS: CIS Benchmarks (O), Grsecurity (O), Anchore (O), Clair (O), Docker-Bench (O), Kube-Bench (O), Kube-Hunter (O), Falco (O)
DEPENDENCY MANAGEMENT: GitHub Security Alerts (O), Node Security Platform (O), PHP Security Checker (O), Retire.JS (O), OWASP Dependency Check (O),
Terrascan (L)
Role
STATIC CODE ANALYSIS: Security Analyst, developers
SECURITY UNIT TESTS: Security Analyst, testers & QA
CONTAINER SECURITY / IAAC ANALYSIS: operations team, security Analyst
DEPENDENCY MANAGEMENT: Security Analyst, operations team
Salidas
STATIC CODE ANALYSIS: Informe con los hallazgos de seguridad en el código, con recomendación y referencias de las vulnerabilidades
SECURITY UNIT TESTS: casos de abuso, pruebas unitarias y documentación de cobertura de pruebas
CONTAINER SECURITY / IAAC ANALYSIS: Informes con hallazgos de seguridad en las imágenes de los contenedores
DEPENDENCY MANAGEMENT: Informe con vulnerabilidades, componentes desactualizados y riesgos o violaciones de licencias

STAGE: COMMIT (CONTINUOUS INTEGRATION)
Actividades
STATIC CODE ANALYSIS
Oportunidad limitada para proporcionar una retroalimentación rápida y clara durante
la confirmación y la construcción:
• Diferenciar y escanear automáticamente los cambios, proporcionar información
clara sobre los nuevos hallazgos a los desarrolladores, botón de
retroalimentación para rechazar los falsos positivos
• Escaneo incremental si es posible - el escaneo profundo lleva demasiado tiempo
para CI/CD, especialmente en bases de código grandes.
• Ejecutar escaneos profundos fuera de banda
• Ejecutar escaneos en paralelo con las pruebas unitarias para mayor velocidad
• Enviar los resultados directamente a los ingenieros (IDE / lista de pendientes)
• Minimizar los falsos positivos desactivando reglas / escribiendo reglas
personalizadas
SECURITY UNIT TESTS
Aproveche los equipos de ingeniería que están "obsesionados con las pruebas":
• ¡¡Salga del "camino feliz"!!
• Aprovechar "Evil User Stories", "Abuse Cases", y los requisitos de OWASP ASVS
para llegar a los casos de prueba
• Asegurar altos niveles de cobertura de pruebas unitarias para el código critico
• Rojo = STOP - asegúrese de que el equipo no ignora/elimina las pruebas rotas
• Escriba primero las pruebas unitarias cuando arregle las vulnerabilidades
• Utilice las pruebas unitarias para alertar sobre los cambios en el código critico
CONTAINER SECURITY / IAAC ANALYSIS
• Aislamiento ligero (¿Los contenedores contienen?)
• El espaciado de los nombres de usuario no está habilitado por defecto
• Contenido no fiable, imágenes comprometidas y vulnerables
• Docker Daemon presenta su propia superficie de ataque
• Despliegue de contenedores y visibilidad limitada, especialmente a escala
• El tiempo de ejecución efímero es difícil de rastrear y gestionar
Las discusiones en profundidad sobre la seguridad de los contenedores podrían durar
una semana. Aquí tienes algunos recursos para mantenerte ocupado:
• Docker Security Guidelines
• Docker Reference Architecture
• CIS Docker & Kubernetes Benchmark
• NCC Group: Understanding and Hardening Linux Containers
• NIST SP 800-190 Application Container Security Guide
DEPENDENCY MANAGEMENT
Las vulnerabilidades graves pueden heredarse de las bibliotecas de código abierto, las
imágenes Docker y las plantillas de infraestructura:
• Escanear automáticamente la base de código o construir artefactos e identificar
dependencias externas (construir una "lista de materiales")
• Identificar los componentes obsoletos
• Comprobar las vulnerabilidades públicas y conocidas en estos componentes
• Muchas herramientas también comprueban las violaciones de las licencias
• Hay que tener en cuenta que algunas herramientas pueden no comprobar las
dependencias transitivas dentro de los componentes
Suspender automáticamente en el CI/CD la compilación con problemas graves

STAGE: ACCEPTANCE (CONTINUOUS DELIVERY)
Objetivos
Aceptación de seguridad automatizada, pruebas funcionales y escaneo profundo fuera de banda durante la entrega continua
Tools
INFRASTRUCTURE AS CODE: Ansible (O/P), Chef (O), Puppet (O), SaltStack (O), Terraform (O/P), Vagrant (O)
CLOUD INFRASTRUCTURE: AWS CloudFormation (L), Azure Resource Manager (L), Google Cloud Deployment Manager (L)
DYNAMIC SECURITY TESTS: Arachni (O), Nmap (O), SqlMap (O), Ssh_scan (O), Sslyze (O), ZAP (O), Veracode (L)
SECURITY ACCEPTANCE TESTS: BDD-Security (L), Gauntit (O), Mittn (O)
Role
INFRASTRUCTURE AS CODE: Operations team
CLOUD INFRASTRUCTURE: Operations team
DYNAMIC SECURITY TESTS: Security Analyst
SECURITY ACCEPTANCE TESTS: Security Analyst, testers & QA
Salidas
INFRASTRUCTURE AS CODE: Playbooks y scripts de infraestructura definidos como Código
CLOUD INFRASTRUCTURE: Plantillas definidas y versionadas
DYNAMIC SECURITY TESTS: Informe de resultados de análisis guardado como artefactos
SECURITY ACCEPTANCE TESTS: Planificación y casos de prueba y documentación de apoyo

STAGE: ACCEPTANCE (CONTINUOUS DELIVERY)
Actividades
INFRASTRUCTURE AS CODE
Definir toda la infraestructura como un código, minimizando la configuración manual
• La infraestructura como código proporciona una infraestructura automatizada, reproducible,
comprobable y autodocumentada.
• Le permite desplegar toda una infraestructura/arquitectura ejecutando un script
• Puede lanzar bbdd preconfiguradas, infraestructura de red, sistemas de almacenamiento,
balanceadores de carga y cualquier otro servicio
CLOUD INFRASTRUCTURE:
Definir plantillas y stacks de configuración para plataformas en la nube
• Podrá desplegar, gestionar y supervisar todos los recursos de la nube para una aplicación, o
una solución, como un grupo.
• Podrá desplegar como una unidad, pero no sólo una vez. Capacidad de desplegar varias veces
a lo largo del ciclo de vida de su app, así como de gestionar ese proceso de despliegue
• Podrás definir las dependencias para asegurarte de que se despliega en el orden correcto.
Mantener todo esto en orden puede ser una de las cosas más difíciles de hacer.
DYNAMIC SECURITY TESTS:
Incluir el análisis dinámico automáticamente en el pipeline
• DAST puede determinar diferentes vulnerabilidades de seguridad que están directamente
relacionadas con el despliegue operativo de una aplicación.
• No es necesario acceder al código, ya que ayuda a encontrar diferentes vulnerabilidades en
las aplicaciones web mientras se están ejecutando en el entorno de producción.
• Puede realizar las acciones/escenarios de un atacante real, lo que ayuda a descubrir
diferentes vulnerabilidades que normalmente se pierden con otras técnicas de prueba.
• Ayuda a un equipo de pruebas a encontrar las vulnerabilidades que existen fuera del código
fuente y en las interfaces de aplicaciones de terceros.
SECURITY ACCEPTANCE TESTS:
Involucra directamente a los key users del software. UAT puede llevarse a cabo
poniendo el software a disposición de una prueba beta en Internet o a través de un
equipo de pruebas interno formado por usuarios reales del software.
• Planificación
• La estrategia de UAT se define durante la etapa de planificación.
• Diseño de las pruebas:
• Los casos de prueba se diseñan para cubrir todos los escenarios
funcionales del software en el uso del mundo real. Se diseñan en un
lenguaje y una forma simples para facilitar el proceso de prueba a los
testers.
• Selección del equipo de pruebas
• El equipo de pruebas está formado por usuarios finales del mundo real.
• Ejecución de los casos de prueba y documentación
• El equipo de pruebas ejecuta los casos de prueba designados. A veces
también ejecuta algunas pruebas aleatorias relevantes. Todos los errores
se registran en un documento de pruebas con los comentarios
pertinentes.
• Corrección de errores
• En respuesta a los errores encontrados por el equipo de pruebas, el
equipo de desarrollo de software realiza los ajustes finales en el código
para que el software esté libre de errores.
• Cierre de la sesión
• Cuando se han corregido todos los errores, el equipo de pruebas indica
la aceptación del software

STAGE: PRODUCTION (CONTINUOUS DEPLOYMENT)
Objetivos
Comprobaciones de seguridad antes, durante y después de que el código se despliegue en producción
Tools
SECURITY SMOKE TESTS: ZAP Baseline Scan (O), Nmap (O), SSLabs-Scan (O)
SECRETS MANAGEMENT: AWS KMS (L), AWS Secrets Manager (L), Azure Key Vault (L), Google Cloud KMS (L), Ansible Vault (L), Blackbox, Chef Vault, CyberArk Conjur
(L), Hashicorp Vault (O/L), Pinterest Knox (O) Manage Engine Privileged access management (L)
SECURITY CONFIGURATION: AWS Config (L), AWS Trusted Advisor (L), Microsoft Azure Advisor (L), Security Monkey (O), OSQuery (O)
SERVER HARDENING: FunctionShield, CIS, Dev-Sec.io, SIMP, Fail2ban (O), OSSEC, Sanhain, Wazuh
Role
INFSECURITY SMOKE TESTS: Security Analyst, testers & QA
SECRETS MANAGEMENT: Security Analyst, developers, testers & QA and operations team
SECURITY CONFIGURATION: Security Analyst, operations team
SERVER HARDENING: Security Analyst, operations team
Salidas
SECURITY SMOKE TESTS: Gestión de casos de prueba y documentación de casos
SECRETS MANAGEMENT: Informe de utilización y acceso a los diferentes secretos dentro de la bóveda
SECURITY CONFIGURATION: Automation rules defined, Recommendation and best practices document
SERVER HARDENING: Versioned baselines per operating system

STAGE: PRODUCTION (CONTINUOUS DEPLOYMENT)
Actividades
SECURITY SMOKE TESTS
Las pruebas de humo desempeñan un papel importante en el desarrollo de software, ya que garantizan la
corrección del sistema en las etapas iniciales. De este modo, podemos ahorrar el esfuerzo de las pruebas.
Como resultado, las pruebas de humo llevan el sistema a un buen estado. Una vez que se completan las
pruebas de humo, se inician las pruebas funcionales.
• Todos los problemas de la compilación se identificarán mediante la realización de smoketest.
• Las smoketest se realizan después de que la compilación se libera a QA. Con la ayuda de las smoketest,
la mayoría de los defectos se identifican en las etapas iniciales del desarrollo.
• Con las pruebas de humo, simplificamos la detección y corrección de los principales defectos.
• Mediante las pruebas de humo, el equipo de control de calidad puede encontrar defectos en la
funcionalidad de la aplicación que pueden haber surgido por el nuevo código.
• Las pruebas de humo encuentran los defectos de mayor gravedad, incluidos los aspectos de seguridad
SECRETS MANAGEMENT
Permite guardar y generar secretos de forma segura
Los secretos pueden incluir:
• Contraseñas de usuario o autogeneradas
• Claves/credenciales de la API y de otras aplicaciones (incluso dentro de los contenedores)
• Claves SSH
• Contraseñas de base de datos y otras contraseñas de sistema a sistema.
• Certificados privados para la comunicación segura, transmisión y recepción de datos (TLS, SSL, etc.)
• Claves privadas de cifrado para sistemas como PGP
• RSA y otros dispositivos de contraseña de un solo uso
Los riesgos más comunes para los secretos y algunas consideraciones incluyen
• Visibilidad y conocimiento incompletos
• Credenciales codificadas/incorporadas
• Credenciales privilegiadas y la nube
SECURITY CONFIGURATION
Permite a los administradores determinar el cumplimiento de las normas
corporativas y de seguridad. También funciona para determinar los
cambios en el ecosistema que pueden haber dado lugar a problemas de
rendimiento y funcionalidad.
• Centralizar la administración
• Estandarizar el etiquetado de todos los recursos
• Automatización
• Recomendaciones y mejores prácticas
SERVER HARDENING
La "superficie de ataque" es la combinación de todos los posibles fallos y
puertas traseras de la tecnología que pueden ser explotados por los
Delincuentes. Estas vulnerabilidades pueden producirse de múltiples
maneras, entre ellas:
Contraseñas predeterminadas y codificadas
• Contraseñas y otras credenciales almacenadas en archivos de texto
plano
• Vulnerabilidades de software y firmware sin parchear
• BIOS, cortafuegos, puertos, servidores, conmutadores, routers u otras
partes de la infraestructura mal configurados
• Tráfico de red o datos en reposo sin cifrar
• Falta de acceso privilegiado
Mejores prácticas para el endurecimiento de los sistemas:
• Cree una estrategia para el fortalecimiento de los sistemas
• Parchee inmediatamente las vulnerabilidades
• Fortalecimiento de la red
• Endurecimiento del sistema operativo
Eliminar las cuentas y privilegios innecesarios

STAGE: OPERATIONS
Objetivos
Supervisión continua de la seguridad, pruebas, auditorías y controles de conformidad
Tools
BLAMELESS POSTMORTEMS: Etsy Morgue (O)
CONTINUOUS MONITORING: ElastAlert (O), Grafana (O), Graphite (O), Prometheus (O), Seyren (O), CloudWatch (L), CloudTrail (L), Reddalert (O), Azure Security Center (L) Manager
Engine Application Performance Monitoring, Applications Manager y Log360 (L)
PENETRATION TESTING: Bug Bounties (O), Netflix Aardvark (O), Acunetix (L), Qualys (O/L), Faraday (O), DefectDojo (O) Vulnerability Manager Plus (L)
OpenSCAP (O), OpenWAS (O)
THREAT INTELLIGENCE: Diamond Model, Kill Chain, STIX, TAXII (O),
Role
BLAMELESS POSTMORTEMS: All team
CONTINUOUS MONITORING: Operations team
PENETRATION TESTING: Security Analyst
THREAT INTELLIGENCE: Security Analyst
Salidas
BLAMELESS POSTMORTEMS: Documentación con el detalle del problema, la resolución y la propuesta de mejora para evitar que se repita
CONTINUOUS MONITORING: Monitorización en tiempo real con métricas basadas en diferentes dimensiones, posibilidad de exportar la información de rendimiento en rangos de
tiempo
PENETRATION TESTING: Informe con los hallazgos, la clasificación de los mismos y la recomendación para subsanarlos.
THREAT INTELLIGENCE: Inteligencia táctica evalúa en tiempo real los eventos, investigaciones y/o actividades relacionadas con el apoyo operativo diario

STAGE: OPERATIONS
Actividades
BLAMELESS POSTMORTEMS
Debe centrarse en la identificación de las causas que contribuyen al incidente sin acusar a ningún
individuo o equipo de comportamiento malo o inapropiado.
Los desencadenantes más comunes de la postmortem son:
• Tiempo de inactividad visible para el usuario o degradación más allá de un determinado
umbral
• Pérdida de datos de cualquier tipo
• Intervención de un ingeniero de guardia (reversión de la liberación, redireccionamiento del
tráfico, etc.)
• Un tiempo de resolución por encima de algún umbral
• Un fallo de supervisión (que suele implicar la detección manual de incidentes)
La redacción de un postmortem también implica una revisión y publicación formal. En la práctica,
los equipos comparten el primer borrador internamente y solicitan a un grupo de ingenieros que
evalúen el borrador para ver si está completo. Los criterios pueden incluir:
• ¿Se han recogido los datos de los incidentes clave para la posteridad?
• ¿Están completas las evaluaciones de impacto?
• ¿Se ha profundizado lo suficiente en la causa raíz?
• ¿Es apropiado el plan de acción y las correcciones de errores resultantes tienen la prioridad
adecuada?
• ¿Se ha compartido el resultado con las partes interesadas?
CONTINUOUS MONITORING
En entornos dinámicos y escalables, el proceso de monitorización de microservicios debe
adaptarse a los cambios sin necesidad de intervención y configuración manual.
Las capacidades críticas son las siguientes
• Descubrimiento automático y correlación de la pila completa y las dependencias
• Instrumentación y supervisión automáticas de los componentes de la aplicación
• Visualización automática de todos los componentes y sus dependencias
• Alerta automática de los problemas de rendimiento de la infraestructura y la aplicación
PENETRATION TESTING
Las pruebas de penetración (o pen testing) son un ejercicio de seguridad en el que
un experto en ciberseguridad intenta encontrar y explotar las vulnerabilidades de un
sistema informático. El propósito de este ataque simulado es identificar cualquier
punto débil en las defensas de un sistema que los atacantes podrían aprovechar.
Es como si un banco contratara a alguien para que se disfrazara de ladrón e
intentara entrar en su edificio y acceder a la cámara acorazada. Si el "ladrón" tiene
éxito y entra en el banco o en la cámara acorazada, el banco obtendrá información
valiosa sobre cómo debe reforzar sus medidas de seguridad.
White box pen test
• En una prueba de caja blanca, el pirata informático recibirá con antelación
cierta información sobre la seguridad de la empresa objetivo.
Black box pen test
• También conocida como prueba "a ciegas", es aquella en la que el pirata
informático no recibe más información que el nombre de la empresa objetivo.

STAGE: OPERATIONS
Actividades
PENETRATION TESTING
Covert pen test
• También conocida como prueba de penetración "doblemente ciega", se trata de
una situación en la que casi nadie en la empresa es consciente de que la prueba de
penetración está ocurriendo, incluidos los profesionales de TI y de seguridad que
responderán al ataque. En el caso de las pruebas encubiertas, es especialmente
importante que el hacker tenga el alcance y otros detalles de la prueba por escrito
de antemano para evitar cualquier problema con las autoridades.
External pen test
• En una prueba externa, el hacker ético se enfrenta a la tecnología externa de la
empresa, como su sitio web y sus servidores de red externos. En algunos casos, el
hacker ni siquiera puede entrar en el edificio de la empresa. Esto puede significar
realizar el ataque desde una ubicación remota o llevar a cabo la prueba desde un
camión o furgoneta aparcada en las cercanías.
Internal pen test
• En una prueba interna, el hacker ético realiza la prueba desde la red interna de la
empresa. Este tipo de prueba es útil para determinar cuánto daño puede causar un
empleado descontento desde detrás del firewall de la empresa.
THREAT INTELLIGENCE
Las soluciones de inteligencia sobre amenazas recopilan datos sin procesar sobre actores y
amenazas emergentes o existentes a partir de una serie de fuentes.
A continuación, estos datos se analizan y filtran para producir fuentes de información sobre
amenazas e informes de gestión que contienen información que puede ser utilizada por las
soluciones de control de seguridad automatizadas.
El objetivo principal de este tipo de seguridad es mantener a las organizaciones informadas
de los riesgos de las amenazas persistentes avanzadas, las amenazas de día cero y los
exploits, y cómo protegerse contra ellos.
Garantizar que se mantiene al día con el volumen, a menudo abrumador, de las amenazas,
incluidos los métodos, las vulnerabilidades, los objetivos y los malos actores.
Ayudarle a ser más proactivo sobre las futuras amenazas a la ciberseguridad.
Mantener informados a los líderes, las partes interesadas y los usuarios sobre las últimas
amenazas y las repercusiones que podrían tener en la empresa.

Marco de conocimientos de seguridad
https://www.securityknowledgeframework.org/

https://github.com/c0rdis/security-champions-playbook
Identificar equipos
• Enumerar los productos
y servicios
• Enumerar los equipos
por cada producto
• Identificar al jefe de
producto (responsable
del producto) y al jefe de
equipo (que trabaja
directamente con los
desarrolladores)
• Escribir las tecnologías
(lenguajes de
programación) utilizadas
por cada equipo
Defina el rol
• Mida el estado actual de
la seguridad entre los
equipos y defina los
objetivos de seguridad
que planea alcanzar a
corto plazo (por ejemplo,
utilizando Owasp Samm)
• Identificar los lugares
donde los campeones
podrían ayudar (como la
verificación de las
revisiones de seguridad
que plantean problemas
de riesgo en el código
existente, la realización
de escaneos
automáticos, etc.)
• Anote las funciones
claramente definidas, ya
que estos serán los
nuevos campeones
designados para trabajar
Nomina campeones
• Presentar la idea y las
descripciones de las
funciones y obtener la
aprobación de todos los
niveles, tanto de los
directores de producto y
de ingeniería como de la
alta dirección
• Junto con el jefe de
equipo, identificar a los
candidatos
potencialmente
interesados
• Nombrarlos oficialmente
como parte de su meta-
equipo de seguridad
Canales de
comunicación
• Asegúrese de tener una
forma fácil de difundir la
información y obtener
comentarios
• Aunque difiere de una
empresa a otra, esto
suele incluir chats (canal
Slack/IRC, Teams,...) y
listas de correo
separadas
• Establecer
sincronizaciones
periódicas - dos veces a
la semana debería estar
bien para empezar
Base de
conocimientos sólida
• Construir una sólida base
de conocimientos sobre
seguridad interna, que se
convertiría en la principal
fuente de inspiración
para los champios
• Debería incluir la página
de los meta-equipos de
seguridad con la
definición de los roles,
las mejores prácticas de
desarrollo seguro, las
descripciones de los
riesgos y
vulnerabilidades y
cualquier otra
información relevante
• Preste especial atención
a la creación de listas de
comprobación claras y
fáciles de seguir, ya que
suele ser la forma más
sencilla de poner en
marcha las cosas.
Mantener el interés
• Desarrolla tus formas o
elige una de las
siguientes para
mantener el contacto y
mantener el interés de
los campeones
• Realice talleres
periódicos y fomente la
participación en
conferencias sobre
seguridad
• Comparta las noticias
recientes sobre
seguridad de las
aplicaciones a través del
canal de comunicación
• Envíe boletines
mensuales de seguridad
internos con
actualizaciones, planes y
reconocimientos por el
buen trabajo
• Crear el rincón de los
campeones con el
calendario de
conferencias de la
biblioteca de seguridad y
otros materiales
interesantes
Security Champions playbook

Security PIN
https://github.com/wurstbrot/security-pins

OWASP Vulnerability Management Guide
(OVMG)

Dev-Sec Hardening Framework
• Endurecimiento automático del servidor. La buena
noticia es que la gente ya ha hecho el 80% del trabajo y
tú sólo tienes que hacer el 20% restante para ajustarlo
a tu entorno. Así que sólo tienes que aprender a
modificar los perfiles existentes para adaptarlos a tus
necesidades.
• Dev-Sec Project tiene un montón de buenos ejemplos
sobre cómo crear roles de Ansible y utiliza un montón
de mejores prácticas que podemos utilizar como línea
de base en nuestros perfiles.
• https://github.com/dev-sec/cis-docker-benchmark

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.

Modelo de madurez DevSecOps (DSOMM)
SDOMM DSOMM

DevSecOps (Measurement)
•
https://riesenfeld.com.mx/bsc-para-devsecops

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

Devsecops superstar un movimiento masivo

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Devsecops superstar un movimiento masivo

Similar to Devsecops superstar un movimiento masivo (20)

More from Luciano Moreira da Cruz

More from Luciano Moreira da Cruz (15)

Recently uploaded

Recently uploaded (11)

Devsecops superstar un movimiento masivo