Cultura DevSecOps

Notas, conceptos y principios sobre cultura DevSecOps para su adopción en SDLC

El objetivo de estas notas se enfoca en incorporar conceptos DevSecOps con lecturas rápidas.

Introducción

La ciberseguridad no se trata sólo de gestionar el riesgo, también es una cuestión estratégica que da forma a la capacidad del producto, la eficacia organizacional y las relaciones con los clientes. Sin embargo, resulta difícil llevar a cabo el tipo de transformación que incorpora consideraciones de seguridad en todos los productos y procesos empresariales manteniendo al mismo tiempo el ritmo de la innovación.

DevSecOps promueve la adopción de la seguridad en todo el ciclo de vida del desarrollo de software (SDLC). Favorece la automatización de la seguridad, la comunicación y la escalabilidad.

DevOps

Es habitual desplegar nuevo código en producción semanalmente. Esto hace que la automatización de la seguridad y la escalabilidad sea un requisito indispensable y ya no puede ser algo opcional.

Shift Left

DevSecOps por tanto, favorece la inclusión de las actividades relacionadas con la seguridad en las aplicaciones al inicio de las etapas del desarrollo.

Automatización

DevSecOps introduce la automatización de la seguridad. Consiste en añadir elementos de Seguridad al “pipeline” de Continuous Integration and Continuous Delivery (CI/CD).

Beneficios Inmediatos

Favorece la identificación y mitigación temprana de riesgos, lo que se traduce en un mejor “time-to-market” y como resultado, una reducción de los costos en desarrollo.

Cultura

Inculcar en la organización una cultura de colaboración proactiva entre los equipos involucrados en el SDLC. Es fundamental una correcta estrategia de comunicación.

Necesidades

Convencer al negocio para adoptar la cultura DevSecOps en SDLC.
Colectar datos, analizarlos y traducir conclusiones a tiempos (time-to-market), costos y reputación de marca.
Convencer al equipo de IT facilitando su tareas y operaciones para cumplir Compliance.
Convencer al equipo de Desarrollo (Squads) adaptando la gestión de vulnerabilidades a sus Sprints.
Inversión para Entrenamiento en Seguridad.
Generación de capacidades para todo el personal involucrado en el equipo de DevOps relacionadas a cyber-seguridad.
Fomentar y alentar Certificaciones para Seguridad Informática.
Diferenciar y entender como area de Seguridad Informática, cuando se debe Concientizar o Evangelizar.

S-SDLC

Seguridad en todo el ciclo de vida del desarrollo de software (SDLC)

A continuación listamos las Medidas de Seguridad en cada etapa de SDLC:

Planificación
- Evaluar los riesgos y el panorama de las amenazas a la seguridad.
- Evaluar el posible impacto de los incidentes de seguridad, como el riesgo para la reputación de la empresa
Análisis de los requisitos
- Incluir los requisitos de seguridad
- Comprender e incorporar los requisitos de cumplimiento normativo
Diseño
- Elaborar modelos de amenazas
- Incluir las consideraciones de seguridad como parte integral del plan de arquitectura
- Evaluar el impacto que tiene la seguridad en las decisiones de la etapa de diseño, como la plataforma y la interfaz de usuario
Desarrollo
- Capacitar a los desarrolladores sobre las prácticas de codificación seguras
- Incorporar herramientas de prueba de la seguridad en el proceso de desarrollo
- Evaluar las dependencias del software y reducir los riesgos de seguridad
Documentación
- Documentar los procesos y los controles de seguridad
- Reunir la información para preparase para las auditorías, los controles de cumplimiento normativo y las revisiones de seguridad
Pruebas
- Implementar procesos de revisión del código
- Realizar pruebas estáticas o dinámicas de la seguridad de las aplicaciones
Implementación
- Evaluar la seguridad del entorno de implementación
- Revisar las configuraciones de seguridad
Mantenimiento
- Supervisar el sistema para detectar amenazas
- Prepararse para eliminar los puntos vulnerables y solucionar las intrusiones

Principios

Lemas

El nuevo mantra
- 🔩 You build it
- 🔧 You fix it
- 🏃 You run it
Security is a requirement and not an option

Principios de la Ingeniería del Caos

La Ingeniería del Caos es la disciplina de experimentar en un Sistema, con la finalidad de generar confianza en la capacidad del Sistema para soportar condiciones turbulentas en producción.

Los avances en sistemas de software distribuidos a gran escala están cambiando el juego para la ingeniería de software. Como industria, somos rápidos en adoptar prácticas que aumentan la flexibilidad de desarrollo y la velocidad de despliegue. Una pregunta urgente sigue de cerca a estos beneficios: ¿cuánta confianza podemos tener en los sistemas complejos que ponemos en producción?

Incluso cuando todos los servicios individuales de un sistema distribuido funcionan correctamente, las interacciones entre ellos pueden causar resultados impredecibles. Estos resultados impredecibles, agravados por los raros pero disruptivos eventos del mundo real que afectan a los entornos de producción, hacen que estos sistemas distribuidos sean inherentemente caóticos.

Necesitamos identificar las debilidades antes de que se manifiesten en comportamientos aberrantes en todo el sistema. Las debilidades sistémicas podrían tomar la forma de: fallbacks incorrectos cuando un servicio no está disponible; tormentas de reintentos debido a timeouts mal configurados; interrupciones cuando una dependencia downstream recibe demasiado tráfico; fallas en cascada cuando hay un crash en un punto único de fallo; Etc. Debemos abordar las debilidades más significativas de manera proactiva, antes de que afecten a nuestros clientes en producción. Necesitamos una manera de gestionar el caos inherente a estos sistemas, aprovechar la flexibilidad y la velocidad crecientes, y tener confianza en nuestros despliegues a producción a pesar de la complejidad que representan.

Un enfoque empírico basado en sistemas aborda el Caos en los sistemas distribuidos a escala y aumenta la confianza en la capacidad de esos sistemas para resistir condiciones realistas. Aprendemos sobre el comportamiento de un sistema distribuido observándolo durante un experimento controlado. Llamamos a esto Ingeniería del Caos. Última actualización: Enero de 2021

Principios para el desarrollo Digital

Desarrollo Digital - 9 Principios

En 2024, los Principios se actualizaron en consulta con un conjunto diverso de personas y organizaciones. A través de este esfuerzo, la comunidad expresó la necesidad de que los Principios reflejen mejor que hoy en día las personas interactúan en gran medida con la tecnología fuera de los programas de desarrollo. Hoy en día, todas las personas –incluso aquellas que aún no tienen acceso a la tecnología ni la utilizan– viven en sociedades cada vez más moldeadas por ecosistemas digitales que pueden traer inmensos beneficios y enormes daños. Por lo tanto, los Principios actualizados reconocen la necesidad de una inclusión radical y una apropiación local; plantear cuestiones derivadas de la generación y uso de datos digitales; y hablar intencionalmente a la audiencia original mientras resuena aún más con la diversidad total de individuos y organizaciones que ejercen poder sobre el diseño, implementación y gobernanza de sistemas y soluciones digitales. Los Principios se refuerzan mutuamente, ya que enfatizan las acciones necesarias para garantizar que nadie se quede atrás en un mundo cada vez más digital.

Nuevos Principios Digitales 2004

Actualización de los Principios para el desarrollo digital
Versión del sitio web para la revisión final del Grupo de trabajo antes del 9 marzo
Fecha: 4 de marzo de 2024

Comprender el ecosistema actual
Compartir, reutilizar y mejorar
Diseñar junto con la gente
Diseñar para la inclusión
Desarrollar con miras a la sostenibilidad
Establecer prácticas de datos que prioricen a las personas
Crear prácticas abiertas y transparentes
Prever y mitigar los daños
Usar evidencia para mejorar los resultados

Principio 8: Prever y mitigar los daños

Cuando se trata de tecnología, el daño siempre es posible. A fin de evitar los resultados negativos, se debe planificar para el peor escenario mientras se trabaja para generar los mejores resultados.

En la actualidad, la tecnología forma parte de nuestra vida diaria: ningún programa o solución tecnológica opera de manera aislada. Por lo tanto, para estar a la altura del compromiso de no hacer daño, los legisladores y profesionales deben anticiparse y trabajar para mitigar los daños, incluso aquellos que se originan fuera de una iniciativa determinada.
Hay diversos daños potenciales que pueden surgir de cualquier iniciativa digital determinada, y toda lista aquí incluida será incompleta. Entre los ejemplos de daños, se incluyen posibilitar la represión digital (que comprende la vigilancia y la censura ilegales); exacerbar las diferencias digitales actuales asociadas con, por ejemplo, la discapacidad, los ingresos o la ubicación geográfica; la violencia de género facilitada por la tecnología; socavar a la sociedad civil local y a compañías del sector privado; extender las normas sociales nocivas actuales; y generar nuevas desigualdades.
Aunque hay daños presentes en toda tecnología, estos daños son especialmente relevantes, y los efectos son menos conocidos, cuando se trata de aprendizaje automático e inteligencia artificial (IA).
La mitigación de daños es específica del contexto y requiere un enfoque multifacético que integre salvaguardas técnicas, regulatorias, de políticas e institucionales. La mitigación de daños eficaz exige un enfoque a largo plazo, que tenga en cuenta de qué modo los desafíos y desigualdades actuales se intensificarán por acontecimientos desconocidos.
Sin estos tipos de salvaguardas, grupos de personas específicos podrían decidir desvincularse o se podrían utilizar sistemas para apuntar deliberadamente a ciertos grupos de personas, socavando todos los objetivos de desarrollo sostenible.

Cultura DevOps

La cultura DevOps implica una colaboración más estrecha y una responsabilidad compartida entre el desarrollo y las operaciones de los productos que crean y mantienen.

Implica cultivar equipos multidisciplinarios que asuman la responsabilidad de todo el ciclo de vida de un producto.

Las mejores prácticas de DevOps incluyen gestión ágil de proyectos, cambio a la izquierda (shift left) con CI/CD, automatización, monitoreo, observabilidad y mejora continua.

El Cambio como Habilidad Organizacional

Muchas organizaciones dicen querer evolucionar, pero cuando llega el momento de tomar decisiones reales, frenan, postergan y se aferran a lo conocido. El cambio se siente incómodo, costoso y riesgoso.

Innovar exige cambiar. Y cambiar no es algo que ocurre una vez: es un ciclo continuo. Antes fue internet, luego las apps, más tarde la inteligencia artificial, ahora GenAI… y lo que venga después. La pregunta no es si habrá otra ola de cambio, sino cuán preparados estamos para navegarla.

La adaptación necesita ser parte de su ADN. Así como un atleta entrena cada día para mejorar su rendimiento, una empresa puede ejercitar su capacidad de cambio, reduciendo fricción y anticipándose a lo que viene. No es solo reaccionar rápido, sino desarrollar una cultura que abrace la transformación como parte de su identidad.

Jeff Bezos lo resumió bien: "Lo peligroso es no evolucionar." Y la evolución no ocurre sola. Depende de los líderes que facilitan el cambio, eliminando burocracia, fomentando autonomía y permitiendo la experimentación. También de la estructura: empresas con jerarquías rígidas y procesos lentos limitan su capacidad de adaptación. Es por eso que muchas compañías tecnológicas han optado por modelos más descentralizados, donde los equipos pueden moverse rápido sin perder alineación.

Cada desafío que enfrentamos es una oportunidad para fortalecer esta habilidad. Si ya estamos resolviendo un problema, ¿cómo podemos aprender de él para la próxima vez? Las crisis, la disrupción del mercado y los cambios regulatorios no son excepciones: son parte del juego. Y esto no es solo una teoría. Amazon no se conformó con ser un retailer: transformó su negocio con AWS y ahora con inteligencia artificial. Netflix no se quedó en el alquiler de DVDs ni en el streaming: apostó a la producción de contenido propio y sigue experimentando. Tesla no es solo una empresa de autos eléctricos; es una compañía que redefine industrias completas.

El cambio no es fácil, pero se debe transitar con placer, incluso cuando la incomodidad es inevitable.

fuente: LinkeIn - Diego Salma

Manifesto

Through Security as Code, we have and will learn that there is simply a better way for security practitioners, like us, to operate and contribute value with less friction. We know we must adapt our ways quickly and foster innovation to ensure data security and privacy issues are not left behind because we were too slow to change.

By developing security as code, we will strive to create awesome products and services, provide insights directly to developers, and generally favor iteration over trying to always come up with the best answer before a deployment. We will operate like developers to make security and compliance available to be consumed as services. We will unlock and unblock new paths to help others see their ideas become a reality.

We won't simply rely on scanners and reports to make code better. We will attack products and services like an outsider to help you defend what you've created. We will learn the loopholes, look for weaknesses, and we will work with you to provide remediation actions instead of long lists of problems for you to solve on your own.

We will not wait for our organizations to fall victim to mistakes and attackers. We will not settle for finding what is already known; instead, we will look for anomalies yet to be detected. We will strive to be a better partner by valuing what you value:

Leaning in over ~~Always Saying “No”~~
Data & Security Science over ~~Fear, Uncertainty and Doubt~~
Open Contribution & Collaboration over ~~Security-Only Requirements~~
Consumable Security Services with APIs over ~~Mandated Security Controls & Paperwork~~
Business Driven Security Scores over ~~Rubber Stamp Security~~
Red & Blue Team Exploit Testing over ~~Relying on Scans & Theoretical Vulnerabilities~~
24x7 Proactive Security Monitoring over ~~Reacting after being Informed of an Incident~~
Shared Threat Intelligence over ~~Keeping Info to Ourselves~~
Compliance Operations over ~~Clipboards & Checklists~~

De DevOps a DevSecOps

7 puntos Claves para gestionar (también llamados puntos de dolor - Pain Points)

Pain Point 1: Ineficiente puesta a punto de los SAST y falsos positivos. | Pipe optimizado. En la ejecución inicial es necesaria la verificación de Falsos+.
Pain Point 2: Falta de coordinación entre los equipos de Seguridad y Desarrollo. | Rol Security Champion.
Pain Point 3: Despliegue de aplicaciones continuo caótico. | Automatizar tareas manuales - IaC + GitOps.
Pain Point 4: El “Pen-testing” manual se convierte en un cuello de botella. | Gestión de Findings desde el inicio y Review de Documentación para disponer de los datos necesarios.
Pain Point 5: Poca visibilidad sobre el histórico de seguridad. | Gestión y registro en DefectDojo.
Pain Point 6: Falta de soporte para Cloud. | IaC + GitOps.
Pain Point 7: Los sistemas no son escalables. | IaC + GitOps

Gestión y Mejora Continua

Modelo de Madurez

OWASP DSOMM

OWASP DevSecOps Verification Standard

The OWASP DevSecOps Verification Standard (DSOVS) is an open source framework that defines baseline requirements for any software project or organisation. You can use the DSOVS for:

🧐 Gap Analysis

DSOVS can be used to identify gaps that exist within a single or multiple software projects by providing internal or external analysts' with a clearly defined standard that cover all areas of the secure software development lifecycle.

🗺️ Maturity Roadmap

DSOVS can be used by developers, architects, security people and anyone else to identify existing DevSecOps maturity levels whilst mapping a clear path to work towards heightened maturity.

⚠️ During Third-party Risk Asessments

DSOVS can be used to audit the software development lifecycle (SDLC) maturity of third-parties which is important as it ensures that their software development processes are resilient and helps identify any potential vulnerabilities that exist due to people, processes or software.

Top 10 CI/CD Security Risks

alt_text

Introduction

CI/CD environments, processes, and systems are the beating heart of any modern software organization. They deliver code from an engineer’s workstation to production. Combined with the rise of the DevOps discipline and microservice architectures, CI/CD systems and processes have reshaped the engineering ecosystem:

The technical stack is more diverse, both in relation to coding languages as well as to technologies and frameworks adopted further down the pipeline (e.g. GitOps, K8s).
Adoption of new languages and frameworks is increasingly quicker, without significant technical barriers.
There is an increased use of automation and Infrastructure as Code (IaC) practices.
3rd parties, both in the shape of external providers as well as dependencies in code, have become a major part of any CI/CD ecosystem, with the integration of a new service typically requiring no more than adding 1-2 lines of code.

These characteristics allow faster, more flexible and diverse software delivery. However, they have also reshaped the attack surface with a multitude of new avenues and opportunities for attackers.

Adversaries of all levels of sophistication are shifting their attention to CI/CD, realizing CI/CD services provide an efficient path to reaching an organization’s crown jewels. The industry is witnessing a significant rise in the amount, frequency and magnitude of incidents and attack vectors focusing on abusing flaws in the CI/CD ecosystem, including -

The compromise of the SolarWinds build system, used to spread malware through to 18,000 customers.
The Codecov breach, that led to exfiltration of secrets stored within environment variables in thousands of build pipelines across numerous enterprises.
The PHP breach, resulting in publication of a malicious version of PHP containing a backdoor.
The Dependency Confusion flaw, which affected dozens of giant enterprises, and abuses flaws in the way external dependencies are fetched to run malicious code on developer workstations and build environments.
The compromises of the ua-parser-js, coa and rc NPM packages, with millions of weekly downloads each, resulting in malicious code running on millions of build environments and developer workstations.

While attackers have adapted their techniques to the new realities of CI/CD, most defenders are still early on in their efforts to find the right ways to detect, understand, and manage the risks associated with these environments. Seeking the right balance between optimal security and engineering velocity, security teams are in search for the most effective security controls that will allow engineering to remain agile without compromising on security.

The "Top 10 CI/CD Security Risks" initiative

This document helps defenders identify focus areas for securing their CI/CD ecosystem. It is the result of extensive research into attack vectors associated with CI/CD, and the analysis of high profile breaches and security flaws.

Numerous industry experts across multiple verticals and disciplines came together to collaborate on this document to ensure its relevance to today’s threat landscape, risk surface, and the challenges that defenders face in dealing with these risks.

We would like to thank and acknowledge all experts which took part in reviewing and validating this document.

Top 10 risks

Presented below are the top 10 CI/CD security risks. All risks follow a consistent structure -

Definition - Concise definition of the nature of the risk.
Description - Detailed explanation of the context and the adversary motivation.
Impact - Detail around the potential impact the realization of the risk can have on an organization.
Recommendations - A set of measures and controls recommended for optimizing an organization’s CI/CD posture in relation to the risk in question.
References - A list of real world examples and precedents in which the risk in question was exploited.

The list was compiled on the basis of extensive research and analysis based on the following sources:

Analysis of the architecture, design and security posture of hundreds of CI/CD environments across multiple verticals and industries.
Profound discussions with industry experts.
Publications detailing incidents and security flaws within the CI/CD security domain. Examples are provided where relevant.

List of the top 10 CI/CD security risks:

CICD-SEC-1: Insufficient Flow Control Mechanisms

CICD-SEC-2: Inadequate Identity and Access Management

CICD-SEC-3: Dependency Chain Abuse

CICD-SEC-4: Poisoned Pipeline Execution (PPE)

CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)

CICD-SEC-6: Insufficient Credential Hygiene

CICD-SEC-7: Insecure System Configuration

CICD-SEC-8: Ungoverned Usage of 3rd Party Services

CICD-SEC-9: Improper Artifact Integrity Validation

CICD-SEC-10: Insufficient Logging and Visibility