Devsecops superstar un movimiento masivo
0 recomendaciones454 vistas
Este documento describe la evolución de las prácticas de TI desde los enfoques tradicionales hasta los enfoques ágiles y DevOps. Explica que DevOps surgió para mejorar la colaboración entre los equipos de desarrollo y operaciones. También describe cómo DevSecOps integra la seguridad en todas las fases del ciclo de vida del desarrollo de software de una manera ágil y automatizada.
Devsecops superstar un movimiento masivo
- 2. Luciano Moreira • Chief DevSecOps strategy Officer en Cloud Legion • seleccionado por la gente de peerlyst como uno de los "50 Influential DevSecOps Professionals“ • Embajador del DevOps Institute • Instructor acreditado de los cursos (DevSecOps Foudation, DevSecOps Enginier y DevSecOps Master Professional) • Master en Ciberseguridad por la Universidad Camilo José Cela. • Primer Auditor CSA STAR certificado en la región SOLA • Elegido Cybersecurity Consultant of the Year en los premios Cybersecurity Excellence Awards del 2016 al 2019, • MVP - Most Valuable Professional Microsoft Azure • Auditor Líder ISO 27001:2013, 27018, 27017 y 9001:2015, • Co-Fundador y Tribe lider de DevSecOps Argentina y Latam, • Presidente del capítulo argentino de la CSA Cloud Security Alliance.
- 3. 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
- 4. Dev Sec Ops
- 6. 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.
- 7. 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
- 9. 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
- 10. 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
- 11. Muro de la incertidumbre Enfoque en cascada DEV TEAM REQUERIMIENTOS DEL NEGOCIO
- 12. Ciclo Agile
- 13. Muro de confusión DEV TEAM OPS TEAM
- 14. 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...
- 15. 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)
- 16. Muro del cumplimiento DEVOPS TEAM INFO/APP SEC
- 17. Seguridad esta en desventaja DEV / OPS / SECURITY 100 / 10 / 1
- 18. DevSecOps es... La seguridad forma parte de DevOps y antes de eso ya era una atributo de calidad
- 19. 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
- 20. 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
- 22. Tabla periódica DevOps Tools
- 23. CI / CD
- 24. 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/
- 25. Cloud Legion / DevSecOps Framework
- 26. 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
- 27. 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
- 28. 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
- 29. 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
- 30. 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
- 31. 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
- 32. 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
- 33. 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
- 34. 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
- 35. 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.
- 36. 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.
- 37. Marco de conocimientos de seguridad https://www.securityknowledgeframework.org/
- 38. 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
- 40. OWASP Vulnerability Management Guide (OVMG)
- 41. 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
- 42. 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.
- 43. Modelo de madurez DevSecOps (DSOMM) SDOMM DSOMM
- 44. DevSecOps (Measurement) • https://riesenfeld.com.mx/bsc-para-devsecops
- 45. DevSecOps • Para profundizar los principios y la temática en DevSecOps, súmate a DevSecOps Latam https://devsecops-latam.org/
- 47. DEV OPS SEC