Desmitificando DevSecOps @ RootedCON Málaga 2021-12-10

Slides de la presentación sobre "Desmitificando DevSecOps: pipelines CI/CD y detección de vulnerabilidades en la práctica" realizada para la conferencia RootedCON Málaga el 11 de diciembre de 2021.

Transcript

1. DESMITIFICANDO DEVSECOPS: Pipelines CI/CD y detección de vulnerabilidades en la práctica RootedCON Málaga – 11 de diciembre de 2021 Jorge Hidalgo @deors314 in/deors
2. SOBRE MÍ Jorge Hidalgo Senior Manager – Senior Technology Architect Accenture Advanced Technology Center in Spain Cloud First Architecture, DevOps & Cybersecurity Lead Global Java Practice Co-lead Certified Application Security Architect with MIT MálagaJUG Co-lead Father of two, husband, whistle player, video gamer, sci-fi *.*, Lego, LOTR, Star Wars, Star Trek, Starcraft, Destiny, Halo, Borderlands, Raspberry Pi, Arduino… LLAP!
3. 1. Introducción 2. Infraestructura 3. Datos 4. Identidades 5. Aplicaciones 6. Umbrales ÍNDICE
4. 1. Introducción 2. Infraestructura 3. Datos 4. Identidades 5. Aplicaciones 6. Umbrales ÍNDICE
5. DevSecOps == DevOps << no puede haber DevOps sin prácticas de seguridad >>
6. DEV quiere CAMBIO OPS quiere ESTABILIDAD Pero, ¿qué quiere Seguridad? “ese gran desconocido” (por no hablar de los estereotipos J)
7. NOSOTROS, SERES LUMINOSOS SOMOS
9. D E V ( S E C ) O P S “ D R A M A T I S P E R S O N A E ” Image adapted from Burr Sutter’s ”8 Steps to Becoming Awesome with Kubernetes” SEC BIZ QA SRE DEV INF DEV SRE INF DBA BIZ QA SEC DBA
10. S P I D E R - M A N Y A D E F I N I Ó D E V ( S E C ) O P S J
11. Ø Toman decisiones Ø Se responsabilizan Ø Miden y mejoran continuamente Ø Sin asumir que “otro lo hará” L O S E Q U I P O S D E V ( S E C ) O P S
12. Ø Infraestructura y plataforma Ø Protección de datos Ø Gestión de identidades y accesos Ø Seguridad de las aplicaciones Ø Umbrales de calidad D E C I S I O N E S Y R E S P O N S A B I L I D A D E S , ¿ S O B R E Q U É ?
13. 1. Introducción 2. Infraestructura 3. Datos 4. Identidades 5. Aplicaciones 6. Umbrales ÍNDICE
14. Ø Hardening Ø Proceso periódico de patch/upgrade Ø Detección de vulnerabilidades asistido por herramientas (vs. revisar el CVE manualmente) Ø Vulnerabilidades cloud native Ø Vulnerabilidades en recetas de infra como código Ø Vulnerabilidades de día cero S E G U R I D A D E N I N F R A E S T U C T U R A Y P L A T A F O R M A
15. Ø Sin olvidar la infraestructura de los usuarios finales Ø Acceso desde un sistema operativo sin soporte Ø Uso desde un navegador sin actualizar Ø Uso desde dispositivos Rooted S E G U R I D A D E N I N F R A E S T U C T U R A Y P L A T A F O R M A
16. https://www.cve.org/
24. A G R E G A R E V E N T O S D E M Ú L T I P L E S F U E N T E S
25. N I N G Ú N P R O C E S O N I H E R R A M I E N T A E S P E R F E C T O Identificar y gestionar excepciones a la norma Identificar y gestionar falsos positivos
26. Ø Qualys Ø Tanium Ø Prisma Cloud Ø Sysdig Ø Falco Ø Clair Ø TFLint Ø Checkov H E R R A M I E N T A S T Í P I C A S
27. 1. Introducción 2. Infraestructura 3. Datos 4. Identidades 5. Aplicaciones 6. Umbrales ÍNDICE
28. Ø Encriptación en tránsito y en reposo Ø Clasificación de los datos Ø Políticas de retención y borrado (ojo a RGPD) Ø Modelado de los accesos a los datos según su clasificación, ya sea en aplicaciones o informes Ø Accesos por áreas funcionales Ø Bloques de información en pantallas Ø Catálogo de informes disponibles a cada rol S E G U R I D A D D E L O S D A T O S
29. Ø Al clasificar, puedes compartimentar Ø Enfoques más actuales como las arquitecturas orientadas a microservicios nos ayudan a mantener la compartimentación y aislar lo usos de conjuntos de datos Ø Más difícil en enfoques tradicionales como bases de datos monolíticas o data lakes donde se vuelca toda la información relevante de una compañía Ø Mitigar con acceso segmentado con RBAC, p.ej. no hay acceso directo al lake, sino mediante un data mart con plataformas como PowerBI, Qlikview, etc. S E G U R I D A D D E L O S D A T O S
30. S E G U R I D A D D E L O S D A T O S Monolith Data Storage Data Repository Business Logic API Interface Presentation Layer Data Storage Data Repository Business Logic API Interface Presentation Layer Data Storage Data Repository Business Logic API Interface Data Storage Data Repository Business Logic API Interface Data Storage Data Repository Business Logic API Interface Order Service Shipping Service Payment Service Catalogue Service
31. Ø Crear casos de prueba para todo lo anterior, que formarán parte de los criterios de aceptación Ø Usar los casos para la batería de pruebas de regresión S E G U R I D A D D E L O S D A T O S given como usuario del grupo de finanzas when estoy autentificado en el sistema then tengo acceso a la página de consulta de nóminas
32. 1. Introducción 2. Infraestructura 3. Datos 4. Identidades 5. Aplicaciones 6. Umbrales ÍNDICE
33. Ø Gestión de certificados y transporte seguro Ø Autentificación y autorización de usuarios Ø Modelo diferenciado para usuarios finales Ø Autentificación de múltiple factor (MFA) Ø Gestión de acceso privilegiado (PAM) Ø Identidades “de aplicación” (m2m) Ø Service principal / service account Ø Managed identity que se asocian a pods específicos Ø Control de acceso basado en roles (RBAC) Ø Granularidad de permisos en plataformas multi-tenant (compartidas) G E S T I Ó N D E I D E N T I D A D E S Y A C C E S O S
34. Ø Más sencillo en entornos con pocos nodos Ø Emisión de certificados ‘wildcard’ y DNS interno para gestionar el acceso a los subnodos Ø Más complejo en entornos cloud native, e.g. Kubernetes, con cientos o miles de nodos que se generan de forma elástica → Necesitamos un sistema de gestión automatizada: Ø cert-manager integrado con un emisor como Let’s Encrypt Ø Una malla de servicios como Istio, que gestiona el mTLS entre los nodos del clúster y la configuración del tráfico de entrada (ingress gateway) G E S T I Ó N D E C E R T I F I C A D O S Y T R A N S P O R T E S E G U R O
35. C O N T R O L D E A C C E S O B A S A D O E N R O L E S Despliegue físico en una plataforma de contenedores – Presencia de cargas de trabajo no relacionadas compartiendo recursos en la misma infraestructura Cluster MANAGER GUEST OS MANAGER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS PERSISTENT STORAGE GUEST OS PERSISTENT STORAGE GUEST OS IMAGE REGISTRY GUEST OS IMAGE REGISTRY GUEST OS Internet Gateway MANAGER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS WORKER GUEST OS PERSISTENT STORAGE GUEST OS PERSISTENT STORAGE GUEST OS
36. C O N T R O L D E A C C E S O B A S A D O E N R O L E S Despliegue lógico en la plataforma – Cargas de trabajo segregadas lógicamente según namespaces que aislamos y protegemos con RBAC Internet Gateway ns A ns C ns B ns D pod pod pod pod ingress pod pod pod pod pod ingress pod pod pod pod pod pod pod pod pod ingress pod ingress pod pod
37. C O N T R O L D E A C C E S O B A S A D O E N R O L E S ns A ns C ns B ns D pod pod pod pod ingress pod pod pod pod pod ingress pod pod pod pod pod pod pod pod pod ingress pod ingress pod pod RO RW super-admin (platform admin) admin en el namespace C user en el namespace C
38. C O N T R O L D E A C C E S O B A S A D O E N R O L E S
39. Ø Complejo en entornos compartidos (multi-tenant), ya sea con servicios gestionados en cloud pública o en plataformas de contenedores (Kubernetes) Ø Definir una adecuada granularidad en los permisos, más allá del simple admins vs. users Ø Particionar el entorno, ya sea con múltiples cuentas en cloud pública, o en los clústers de Kubernetes asignando distintos namespaces por equipos, aplicaciones, entornos o cualquier otro nivel de abstracción necesario Ø Segregar los usuarios por grupos según el modelo granular definido Ø Extender el modelo a otros servicios relacionados, e.g. el registro de imágenes Docker, el repositorio de artefactos binarios, para delimitar quién (o qué) puede hacer push, quién (o qué) puede hacer pull. Ø Extender el modelo también a la gestión de secretos, e.g. Hashicorp Vault, Azure Key Vault, para delimitar quién puede crear o cambiar secretos, y quién (o qué) puede obtenerlos y utilizarlos. C O N T R O L D E A C C E S O B A S A D O E N R O L E S
40. 1. Introducción 2. Infraestructura 3. Datos 4. Identidades 5. Aplicaciones 6. Umbrales ÍNDICE
41. Ø Static Application Security Testing (SAST) Ø Dynamic Application Security Testing (DAST) Ø Pasivo (web proxy) Ø Activo (web spider) Ø Software Composition Analysis (SCA) Ø Gestión de secretos y configuración sensible S E G U R I D A D E N A P L I C A C I O N E S
42. Ø Inyección de SQL Ø Inyección de rutas de ficheros Ø Inyección de XPath Ø Inyección de expresiones regulares Ø Inyección de comandos Ø Inyección de código Ø Inyección de objetos Ø Información expuesta Ø Cross-Site Scripting (XSS) Ø Server-Side Request Forgery (SSRF) Ø Redirección abierta Ø Autentificación errónea Ø Control de acceso erróneo Ø Credenciales hard-code Ø Criptografía débil o mal configurada Ø Desbordamiento de buffer T I P O S D E D E T E C T O R E S
43. Ø Inyección de SQL Ø Inyección de rutas de ficheros Ø Inyección de XPath Ø Inyección de expresiones regulares Ø Inyección de comandos Ø Inyección de código Ø Inyección de objetos Ø Información expuesta Ø Cross-Site Scripting (XSS) Ø Server-Side Request Forgery (SSRF) Ø Redirección abierta Ø Autentificación errónea Ø Control de acceso erróneo Ø Credenciales hard-code Ø Criptografía débil o mal configurada Ø Desbordamiento de buffer T I P O S D E D E T E C T O R E S Inyección de logs
49. H E R R A M I E N T A S E N L O S P I P E L I N E S D E C I / C D (*) El mapa no es exhaustivo de todas las opciones disponibles, pero es representativo de herramientas habitualmente usadas en proyectos ENVIRONMENT PREPARATION COMPILE UNIT TESTS MUTATION TESTS CODE INSPECTION PACKAGE BUILD CONTAINER IMAGE SOFTWARE COMPOSITION ANALYSIS RUN TEST CONTAINER INTEGRATION TESTS PERFORMANCE TESTS PROMOTE/ DEPLOY IMAGE
50. H E R R A M I E N T A S E N L O S P I P E L I N E S D E C I / C D
51. Ø SonarQube Ø SpotBugs (FindSecBugs) Ø PMD Ø Nikto Ø OWASP ZAP Ø OWASP Dependency Tracker Ø Snyk Ø Black Duck Ø Burp Suite Ø Veracode Ø Coverity Ø Fortify Ø Detectify Ø Checkmarx Ø Kiuwan H E R R A M I E N T A S T Í P I C A S
52. 1. Introducción 2. Infraestructura 3. Datos 4. Identidades 5. Aplicaciones 6. Umbrales ÍNDICE
53. Ø Cada control, cada validación, debe tener su correspondiente umbral de calidad Ø Los umbrales deben estar incorporados en los pipelines para no permitir avanzar si no se cumplen Ø Para la infraestructura y plataforma, deberían existir políticas claras respecto a tiempos de resolución de vulnerabilidades, que de no respetarse desemboquen en la no disponibilidad de un servicio o aplicación (p.ej. eliminando su despliegue o eliminando las rutas tanto internas como externas) Ø Incorporar al modelo gestión de excepciones y falsos positivos U M B R A L E S D E C A L I D A D
54. Ø ¿Umbrales generales/globales en la organización, o umbrales por dominio/aplicación? Ø DevSecOps implica lo segundo: independencia y responsabilidad Ø Lo anterior se acompaña de transparencia y trazabilidad Ø Algunas herramientas tienen su propia funcionalidad para umbrales, p.ej. SonarQube Ø Utilidad limitada porque no incluye todas las validaciones en su alcance y obliga a una evaluación del umbral en un solo punto Ø Un umbral definido en un pipeline, representa una especificación clara y trazable Ø Mucho mejor externalizar valores configurables para ser aun más transparentes como equipo, y aportar una trazabilidad más clara U M B R A L E S D E C A L I D A D
55. U M B R A L E S D E C A L I D A D BUENO ¡MEJOR!
56. U M B R A L E S G E S T I O N A D O S P O R H E R R A M I E N T A S
57. ¿ P R E G U N T A S ?