La Automatización en la Auditoría de Seguridad

Transcript

1. La Automatización en la Auditoria de Seguridad Calidad, Auditoria y Seguridad de Procesos, Servicios, Recursos y Productos Software Samuel Alfageme Sainz 2 de Diciembre de 2019
2. $whoami Alumno de esta Escuela (2012-2016) Ingeniero de Calidad (QA) en SolidGEAR (2016-2018) DevOps en Telefónica I+D: Network InnovaNon (2018-???) In ❤ w/ automaNon – GitLab Hero " @alfageme en TwiVer & GitLab @SamuAlfageme en GitHub samuel@alfage.me
3. Outline de las Sesiones 2018 1. El Papel de la Automatización en la Auditoria de Seguridad 1. Introducción 1. Evolución del perfil del ingeniero de QA 2. Necesidad de actualizar el concepto clásico de seguridad 2. Seguridad – mini-glosario 3. GitLab – nociones básicas de Integración continua 4. Técnicas de Análisis de Seguridad en Aplicaciones Web 1. SAST 2. Aplicaciones Deliberadamente Inseguras 3. DAST 2. Estado del arte en materia de análisis de seguridad (13/12)
4. ! Outline de las Sesiones 1. El Papel de la Automatización en la Auditoria de Seguridad 1. Introducción - Contexto 1. Necesidad de actualizar el concepto clásico de seguridad 2. Evolución de los roles en el proceso de desarrollo: Dev(Sec)Ops 2. GitLab – nociones básicas de Integración continua y developer journey 3. Técnicas de Análisis de Seguridad en Aplicaciones Web 1. SAST: proyectos analizadores, ejemplos 1. Análisis de Dependencias 2. Container Scanning 2. DAST: ZAP baseline analysis 2. Estado del arte en materia de análisis de seguridad (13/12)
5. Introducción
6. Necesidad de Abrazar el Cambio CG7 - Capacidad para la puesta en marcha, dirección y ges7ón de procesos de fabricación de equipos informá7cos, con garan=a de la seguridad para las personas y bienes, la calidad final de los productos y su homologación. Ingeniero de QA: f(x) Requisitos → Plan de Pruebas Aún se discute en la universidad
7. Introducción • Aceleración del sector [informá5co] en los úl5mos 10 años: “So$ware is ea,ng the world” - Marc Andreessen h8ps://on.wsj.com/33D6SIi • ¿Cómo ha repercu5do este cambio en los roles del desarrollo? • Desarrollador • Calidad (QA) • Sistemas • Seguridad Verify Automate security testing Implement a defense strategy Secure Mitigate the next security threat Analyze Defend Detect a9acks and prevent exploit
8. Security is made all the time by everyone • La seguridad +ene que ser mucho más presente y con+nuada en el proceso de desarrollo • Cambio de mentalidad asociado a metodologías ágiles: Dev(Sec)Ops • Evaluándose con frecuencia para que aporte valor al propio proceso … de forma automá+ca, para que el coste-beneficio lo jus+fique • No supone una ruptura con el pasado • No sus+tuye la labor del auditor externo • hEps://support.1password.com/security-assessments/
9. Entre las Tareas del DevSecOps 1. Detectar y medir el impacto de los riesgos 2. Mi5gar los problemas de seguridad introducidos en el desarrollo - Que se resuelvan lo antes posible es clave para cualquier proyecto - En estas dos sesiones nos vamos a centrar en la detección (1) - En la segunda sesión trataremos referencias a las líneas de mi5gación (2) - Así como la retroalimentación al proceso de desarrollo
10. Introduciendo seguridad en los procesos de CI
11. ¿Por qué GitLab (CI)? • Herramienta Open Source y On Premise: gitlab.inf.uva.es • Ambiciosa: “idea to production” abraza la filosofía DevOps • Reflejo de la evolución y tendencias del sector • Buen marco de referencia para comprobar el estado del arte • ! Curva de aprendizaje muy reducida
12. El funnel de madurez de GitLab
13. Concepto y Definición de Pipelines h"ps://www.youtube.com/watch?v=OK9rwJbXBTE
14. Developer Journey para el taller 1. Mirror de un proyecto en GitLab: 2. GitLab Runners – Group Runners: desac:vando el genérico 3. Usando las Security features en el proyecto importado: 1. GitLab web IDE & git workflow (creación de un MR) 2. Revisión del impacto de seguridad del cambio 3. Detalle de las vulnerabilidades: referencias y bases de datos (CVE/HO) 4. Aceptando el cambio – Security Dashboard & Dependency List
15. El toolbox del DevSecOps
16. Taxonomía del Análisis de Seguridad Tradicionalmente, se clasificaban en 2 grandes categorías: • SAST – Técnicas Pasivas o Estáticas • Analizando el Código Fuente contra una base de conocimiento (QB) • Similares al análisis de calidad de código / bad smells (e.g. SonarQube) • DAST – Técnicas de Pentesting o Dinámicas • Observando el comportamiento de la aplicación ante diferentes tipos de acciones: • Usuarios reales utilizando la aplicación (recientemente re-clasificada como IAST) • Predefinidas en una base de datos generada para este propósito • Fuerza bruta: fuzzing.
17. Taxonomía del Análisis de Seguridad Applica'on Security Running the Application Analyzing the Source Code Fuzzing IAST DAST SAST Dependency Scanning Container Scanning Secret Detection License Compliance Randomizing the possible inputs Feeding DAST with Automated Tests Common Insecure Paths Analyzing the Code itself for security issues Analyzing Application Manifests Inspecting the OCI that packages the application Looking for passwords on the usual places Comparing dependency license compliance with the project’s
18. GitLab Secure Roadmap Status • Planned: • Interac(ve Applica(on Security Tes(ng • Fuzzing • Minimal: • Secret Detec(on • License Compliance • Viable: • SAST • DAST • Container & Dependency Scanning
19. Taxonomía del Análisis de Seguridad Applica6on Security Running the Application Analyzing the Source Code Fuzzing IAST DAST SAST Dependency Scanning Container Scanning Secret Detection License Compliance Randomizing the possible inputs Feeding DAST with Automated Tests Common Insecure Paths Analyzing the Code itself for security issues Analyzing Application Manifests Inspecting the OCI that packages the application Looking for passwords on the usual places Comparing dependency license compliance with the project’s
20. SAST: Static Analysis Security Testing • Extrínseco: 1. Análisis de Dependencias: Gemnasium & Retire.js https://docs.gitlab.com/ee/user/application_security/dependency_scanning/ 2. Container Scanning: Clair + Klar ← Sesión #2 https://docs.gitlab.com/ee/user/application_security/container_scanning/ • Intrínseco: Análisis del Código de nuestra aplicación • https://docs.gitlab.com/ee/ci/examples/sast.html
21. Análisis de Dependencias: Caso Equifax • Una de las mayores agencias de crédito de EEUU • 145.5 Millones de usuarios afectados por el ataque • Información personal expuesta, incluyendo: • Numeros de la SS • Fechas de Nacimiento • Direcciones • ! 200.000 Números de tarjetas de crédito
22. Análisis de Dependencias: Caso Equifax https://www.wired.com/story/equifax-breach-no-excuse/ The vulnerability that attackers exploited to access Equifax's system was in the Apache Struts […] The Apache Software Foundation said in a statement that, though it was sorry if attackers exploited a bug in its software, it always recommends that users regularly patch and update their platforms. "Most breaches we become aware of are caused by failure to update software components that are known to be vulnerable for months or even years. This vulnerability was disclosed back in March. There were clear and simple instructions of how to remedy the situation. The responsibility is then on companies to have procedures in place to follow such advice promptly"
23. Análisis de Dependencias • Negocio con crecimiento a doble dígito • Máximo exponente: Dependabot comprado por GitHub en 2019 Escanea los proyectos en busca de bibliotecas desactualizadas y genera PR con su actualización. Aporta visibilidad a un proceso tradicionalmente ignorado para buscar la atención de los desarrolladores