Aplicación del enfoque del ciclo de vida de desarrollo de seguridad continua (SDL continuo)

La innovación es la esencia de una organización en la era digital y debe habilitarse y protegerse. La seguridad de la innovación protege los procesos y los datos de innovación frente a los ciberataques. La innovación en la era digital adopta la forma de desarrollar aplicaciones mediante el método DevOps o DevSecOps. Este enfoque permite a las organizaciones innovar rápidamente sin esperar a las programaciones tradicionales de lanzamiento en cascada que pueden tardar meses o años entre versiones.

Las funcionalidades y aplicaciones exitosas cumplen tres tipos de requisitos diferentes:

• Funcional (Dev): la aplicación debe satisfacer las necesidades empresariales y de usuario, que suelen evolucionar rápidamente.
• Segura (Sec): la aplicación debe ser resistente a los ataques de los atacantes que evolucionan rápidamente y aprovechar las innovaciones en las defensas de seguridad.
• Confiable (Ops): la aplicación debe ser confiable y tener un rendimiento eficaz.

Combinar estos tres requisitos y crear una referencia cultural compartida es muy importante, pero suele ser difícil. Los líderes de los equipos de desarrollo, TI y seguridad deben trabajar juntos para impulsar este cambio.

Vea el vídeo siguiente para más información sobre el método DevSecOps para una innovación segura y rápida.

Integración de la seguridad a lo largo del ciclo de vida de desarrollo

Es fundamental integrar la seguridad a lo largo del ciclo de vida de desarrollo para identificar y corregir rápidamente el diseño, el código y otros problemas al tiempo que las personas trabajan en esa parte del proceso. Este enfoque evita correcciones más costosas y difíciles más adelante que pueden provocar una gran cantidad de reprocesos.

Los riesgos de seguridad (y la necesidad de mitigarlos) pueden producirse en cualquier momento del ciclo de vida de desarrollo:

• Diseño: asegúrate de que el diseño no permite a los atacantes obtener fácilmente acceso no autorizado a la carga de trabajo, sus datos u otros recursos empresariales de la organización.
• Código: asegúrate de que la escritura (y reutilización) del código no permite a los atacantes tomar fácilmente el control de la aplicación para realizar acciones no autorizadas que dañan a los clientes, empleados, sistemas, datos u otros recursos empresariales. Los desarrolladores también deben trabajar en un entorno seguro que no permita a los atacantes tomar el control sin su conocimiento.
• Compilación e implementación: asegúrate de que los procesos de integración continua e implementación continua (CI/CD) no permiten a los usuarios no autorizados modificar el código y permitir que los atacantes lo pongan en peligro.
• Ejecutar: asegúrate de que el entorno que ejecuta el código (nube, servidores, dispositivos móviles, otros) sigue los procedimientos recomendados de seguridad en personas, procesos y tecnología para evitar que los atacantes comprometan y usen la carga de trabajo. Este proceso incluye la adopción de procedimientos recomendados bien establecidos, configuraciones de línea base de seguridad, etc.
• Arquitectura y gobernanza de Confianza cero: todas estas fases deben seguir principios de Confianza cero para asumir la vulneración (asumir peligro), comprobar explícitamente la confianza y conceder los privilegios mínimos necesarios para cada cuenta de usuario, identidad de máquina o servicio y componente de aplicación.

¿Qué es DevSecOps?

La innovación tecnológica se desarrolla con frecuencia en el contexto de un enfoque de desarrollo rápido, magro y ágil que combina el desarrollo y las operaciones en un proceso de DevOps y la integración de la seguridad en ese proceso es fundamental para mitigar los riesgos para el proceso de innovación, el crecimiento de la organización y los recursos existentes en la organización. La integración de la seguridad en el proceso crea un proceso de DevSecOps.

Protección por diseño y desplazamiento a la izquierda

A medida que las organizaciones adoptan DevOps y otras metodologías de innovación rápidas, la seguridad debe ser un entramado de subprocesos en toda la estructura de la organización y sus procesos de desarrollo. La integración de la seguridad al final del proceso es costosa y difícil de corregir.

Desplace la seguridad a la izquierda en la escala de tiempo para integrarla en la previsión, el diseño, la implementación y el funcionamiento de los servicios y productos. A medida que los equipos de desarrollo se desplazan a DevOps y adoptan tecnologías en la nube, la seguridad debe formar parte de esa transformación.

En el modelo en cascada, la seguridad solía ser una prueba de calidad una vez finalizado el desarrollo.

DevOps amplió el modelo de desarrollo tradicional (personas, procesos y tecnología) para incluir equipos de operaciones. Este cambio redujo la fricción resultante de tener separados los equipos de desarrollo y operaciones. De forma similar, DevSecOps expande DevOps para reducir la fricción de equipos de seguridad independientes o dispares.

DevSecOps es la integración de la seguridad en todas las fases del ciclo de vida de DevOps desde el origen de la idea hasta la previsión, el diseño arquitectónico, el desarrollo iterativo de aplicaciones y las operaciones. Los equipos debe alinearse simultáneamente con los objetivos de velocidad de innovación, confiabilidad y resistencia de seguridad. Con una comprensión y un respecto mutuos de las necesidades de los demás, los equipos trabajan primero en los problemas más importantes, sea cual sea el origen.

La metodología organizativa de Cloud Adoption Framework proporciona un contexto adicional de las estructuras de DevSecOps en una organización. Para más información, vea Funciones de seguridad de las aplicaciones y DevSecOps.

¿Por qué DevSecOps?

DevOps aporta agilidad, y DevSecOps aporta agilidad segura.

Casi todas las organizaciones del planeta confían en el desarrollo de software para obtener una ventaja competitiva gracias a la innovación. La protección del proceso de DevOps es fundamental para el éxito de la organización. Los atacantes han tomado nota de este cambio en las aplicaciones personalizadas y se centran cada vez más en las aplicaciones personalizadas durante sus ataques. Estas nuevas aplicaciones suelen ser orígenes importantes de una potente propiedad intelectual que contiene nuevas y valiosas ideas que aún no están disponibles en marketplace como un producto básico.

La protección de esta innovación requiere que las organizaciones aborden posibles vulnerabilidades y ataques de seguridad tanto en el proceso de desarrollo como en la infraestructura que hospeda las aplicaciones. Este enfoque debe aplicarse a la nube y al recurso del entorno local.

Los atacantes pueden lograr sus objetivos aprovechando las debilidades en el proceso de desarrollo, la infraestructura subyacente para cargas de trabajo o ambas:

• Ataques de desarrollo que usan debilidades en el proceso de desarrollo y diseño de aplicaciones. Por ejemplo, los atacantes pueden encontrar código que no valide la entrada (lo que permite ataques comunes como la inyección de CÓDIGO SQL) o que podrían encontrar que la aplicación usa cifrado débil (o ningún cifrado) para las comunicaciones. Además, los atacantes podrían tener puertas traseras en el código que les permitan volver más tarde para acceder a activos de tu entorno o el del cliente.
• Ataques de infraestructura que pueden poner en peligro los elementos de infraestructura y punto de conexión en los que se hospeda el proceso de desarrollo mediante ataques estándar. Los atacantes también pueden realizar un ataque de varias fases que usa credenciales robadas o malware para acceder a la infraestructura de desarrollo desde otras partes del entorno.

Además, el riesgo de ataques a la cadena de suministro de software hace que sea fundamental integrar la seguridad en el proceso en estos dos casos:

• Protección de la organización frente a código malintencionado y vulnerabilidades en la cadena de suministro de código fuente
• Protección de los clientes frente a cualquier problema de seguridad en tus aplicaciones y sistemas, lo que podría provocar daños en la reputación, responsabilidades u otros impactos empresariales negativos en tu organización

Recorrido por DevSecOps

La mayoría de las organizaciones encuentran que DevOps o DevSecOps para cualquier carga de trabajo o aplicación determinada es realmente un proceso de dos fases. Las ideas primero incuban en un espacio seguro y posteriormente se publican en producción como un producto mínimo viable (MVP). A continuación, se actualizan de forma iterativa y continua.

En este diagrama se muestra el ciclo de vida de este tipo de enfoque de fábrica de innovación:

La innovación segura es un enfoque integrado para estas dos fases:

• Concepción de la idea, donde se crea, valida y prepara una idea inicial para su uso inicial en producción. Esta fase comienza con una nueva idea y finaliza cuando la primera versión de producción cumple los criterios de producto mínimo viable (MVP) para lo siguiente:
  • Desarrollo: la funcionalidad cumple los requisitos empresariales mínimos.
  • Seguridad: las funcionalidades cumplen los requisitos de cumplimiento normativo, seguridad y protección para su uso en producción.
  • Operaciones: la funcionalidad cumple los requisitos mínimos de calidad, rendimiento y compatibilidad para ser un sistema de producción.
• DevOps: esta fase es el proceso de desarrollo iterativo continuo de la aplicación o carga de trabajo que permite una innovación y mejora continuas.

Imperativo de liderazgo: combinar las referencias culturales

Para cumplir estos tres requisitos, es necesario combinar estas tres referencias culturales para garantizar que todos los miembros del equipo valoren todos los tipos de requisitos y trabajen juntos para lograr objetivos comunes.

Integrar estas referencias culturales y objetivos de forma conjunta en un verdadero enfoque de DevSecOps puede ser un desafío, pero la inversión merece la pena. Muchas organizaciones experimentan un alto nivel de fricción perjudicial entre los equipos de desarrollo, operaciones de TI y seguridad que trabajan de forma independiente, lo que plantea problemas en los siguientes casos:

• Poca aportación de valor y baja agilidad
• Problemas de calidad y rendimiento
• Problemas de seguridad

Aunque es normal y previsible que surjan algunos problemas con el nuevo desarrollo, los conflictos entre los equipos suelen aumentar drásticamente el número y la gravedad de estos problemas. Los conflictos se suelen producirse porque uno o dos equipos tienen una ventaja política e invalidan repetidamente los requisitos de otros equipos. Con el tiempo, el número y la gravedad de los problemas no resueltos suelen aumentar. Si no se resuelven, esta dinámica podría ser peor con DevOps a medida que aumenta la velocidad de la toma de decisiones para satisfacer la rápida evolución de las necesidades empresariales y las preferencias de los clientes.

Para resolver estos problemas, es necesario crear una referencia cultural compartida que valore los requisitos de desarrollo, seguridad y operaciones aprobados por los directivos. Este enfoque permitirá a los equipos trabajar mejor juntos y ayudar a resolver los problemas más urgentes en cualquier sprint concreto, ya sea para mejorar la seguridad o la estabilidad operativa o para agregar características empresariales críticas.

Técnicas de liderazgo

Estas técnicas clave pueden ayudar a los directivos a crear una referencia cultural compartida:

1. Nadie tiene la razón en todos los argumentos: los directivos deben asegurarse de que no sea solo una misma persona la que domine todas las decisiones, a fin de evitar un desequilibrio que afecte negativamente al negocio.
2. Previsión de mejoras continuas, no de la perfección: los directivos deben establecer una expectativa de mejora continua y aprendizaje continuo. Un programa de DevSecOps de éxito no se elabora de la noche a la mañana. Se trata de un proceso continuo con un progreso incremental.
3. Apreciar los intereses comunes y los valores individuales únicos: asegúrese de que los equipos puedan ver que están trabajando para obtener resultados comunes y que cada individuo proporciona algo que los demás no pueden. Todos los tipos de requisitos tratan de crear y proteger el mismo valor empresarial. El desarrollo intenta aportar un nuevo valor, mientras que las operaciones y la seguridad pretenden proteger y conservar ese valor, en distintos escenarios de riesgo. Los directivos de todos los niveles de la organización deben comunicar esta convergencia y lo importante que es cumplir todos los tipos de requisitos para un éxito inmediato y a largo plazo.
4. Desarrollo de conocimientos compartidos: todos los miembros del equipo deben tener una comprensión básica de lo siguiente:
   • Urgencia empresarial: el equipo debe tener una imagen clara de los ingresos en juego. Esta imagen debe incluir los ingresos actuales (si el servicio está sin conexión) y los posibles ingresos futuros afectados por un retraso en la entrega de aplicaciones y características. Esta imagen debe basarse directamente en las señales de las partes interesadas del equipo directivo.
   • Posibles riesgos y amenazas: en función de las consideraciones del equipo de inteligencia sobre amenazas, si procede, el equipo debe concebir una idea de las posibles amenazas a las que se enfrentará la cartera de aplicaciones.
   • Requisitos de disponibilidad: el equipo debe tener una idea compartida de los requisitos operativos, como el tiempo de actividad necesario, la duración esperada de la aplicación y los requisitos de solución de problemas y mantenimiento, por ejemplo, la aplicación de revisiones mientras el servicio está en línea.
5. Demostrar y modelar el comportamiento deseado: los directivos deben modelar públicamente el comportamiento que desean de sus equipos. Por ejemplo, mostrar la humildad, centrarse en el aprendizaje y valorar las otras materias. Otro ejemplo es que los administradores de desarrollo analizan el valor de las aplicaciones de seguridad y de alta calidad, o bien los administradores de seguridad analizan el valor de la innovación rápida y del rendimiento de las aplicaciones.
6. Supervisar el nivel de fricción de seguridad: la seguridad crea de forma natural una fricción que ralentiza los procesos. Es fundamental que los directivos supervisen el nivel y el tipo de fricción que genera la seguridad:
   • Fricción sin problemas: al igual que la resistencia en el ejercicio fortalece un músculo, la integración del nivel adecuado de fricción de seguridad en el proceso de DevOps fortalece la aplicación forzando el pensamiento crítico en el momento adecuado. Si los equipos están aprendiendo y usando esos conocimientos para mejorar la seguridad, por ejemplo, teniendo en cuenta cómo y por qué un atacante podría intentar poner en peligro una aplicación y encontrar y corregir errores de seguridad importantes, entonces van por buen camino.
   • Fricción con problemas: intente identificar la fricción que impide más valor del que se protege. Esta fricción a menudo ocurre cuando los errores de seguridad generados por las herramientas tienen una alta tasa de falsos positivos o falsas alarmas, o cuando el esfuerzo de seguridad para corregir las incidencias supera el posible impacto de un ataque.
7. Integrar la seguridad en el planeamiento de presupuestos: asegúrese de que el presupuesto de seguridad se asigne proporcionalmente a otras inversiones en seguridad. Este concepto es similar a un evento físico como un concierto en el que el presupuesto del evento incluye la seguridad física como norma. Algunas organizaciones asignan el 10 % del costo total de la seguridad como regla general para garantizar una aplicación coherente de los procedimientos recomendados de seguridad.
8. Establecer objetivos compartidos: asegúrese de que las métricas de rendimiento y éxito de las cargas de trabajo de las aplicaciones reflejan los objetivos de desarrollo, seguridad y operaciones.

Nota:

Lo ideal es que estos equipos creen estos objetivos compartidos de forma conjunta para maximizar la compra, ya sea para toda la organización o para un proyecto o una aplicación determinados.

Identificación del MVP de DevSecOps

Durante la transición de una idea a producción, es fundamental asegurarse de que la funcionalidad cumple los requisitos mínimos, o el producto mínimo viable (MVP), para cada tipo de requisito:

• Los desarrolladores (dev) se centran en representar las necesidades empresariales para la entrega rápida de funcionalidades que satisfacen las expectativas de los usuarios, clientes y líderes empresariales. Identifique los requisitos mínimos para asegurarse de que la funcionalidad ayuda a que la organización tenga éxito.
• La seguridad (sec) se centra en cumplir las obligaciones de cumplimiento y en ofrecer protección contra los atacantes que buscan continuamente aprovecharse de forma ilícita de los recursos de la organización. Identifique los requisitos mínimos para cumplir los requisitos de cumplimiento normativo, mantener la posición de seguridad y asegurarse de que las operaciones de seguridad puedan detectar un ataque activo y actuar rápidamente.
• Las operaciones (ops) se centran en el rendimiento, la calidad y la eficacia, lo que garantiza que la carga de trabajo pueda seguir aportando valor a largo plazo. Identifique los requisitos mínimos para asegurarse de que la carga de trabajo puede ejecutarse y ser compatible sin necesidad de realizar cambios masivos en la arquitectura o el diseño en un futuro próximo.

Las definiciones de MVP pueden cambiar con el tiempo y con diferentes tipos de cargas de trabajo, a medida que el equipo aprende de forma conjunta de su propia experiencia y de otras organizaciones.

Integración nativa de la seguridad en el proceso

Los requisitos de seguridad deben centrarse en la integración nativa con el proceso y las herramientas existentes. Por ejemplo:

• Las actividades de diseño, como el modelado de amenazas, deben integrarse en la fase de diseño.
• Las herramientas de análisis de seguridad deben integrarse en los sistemas de integración continua y entrega continua (CI/CD), como Azure DevOps, GitHub y Jenkins.
• Los problemas de seguridad deben notificarse con los mismos sistemas y procesos de seguimiento de errores (por ejemplo, el esquema de priorización) que se usan para otros errores.

La forma en que la seguridad se integra en el proceso debe mejorarse continuamente a medida que los equipos aprenden y los procesos maduran. Las revisiones de seguridad y las evaluaciones de riesgos deben garantizar que las mitigaciones se integren en los procesos de desarrollo de manera integral, en el servicio de producción final y en la infraestructura subyacente.

Para más información sobre DevSecOps, vea Controles técnicos de DevSecOps.

Sugerencias sobre cómo navegar por el recorrido

La transformación requiere mejorar este estado ideal de forma incremental a lo largo del recorrido. Muchas organizaciones tienen que navegar por la complejidad y los desafíos de este recorrido. En esta sección se describen algunos de los desafíos comunes a los que se enfrentan las organizaciones.

• Los cambios en la educación y la cultura son pasos iniciales críticos: vaya a la guerra con su ejército. Su equipo a menudo necesitará desarrollar nuevas aptitudes y adoptar nuevas perspectivas para comprender las otras partes del modelo de DevSecOps. Este cambio en la educación y la cultura conlleva tiempo, focalización, patrocinio ejecutivo y seguimiento regular para ayudar a las personas a comprender completamente y ver el valor del cambio. El cambio drástico de las culturas y las aptitudes a veces puede sacar el máximo provecho de la identidad profesional de los individuos, lo que permite desarrollar una resistencia sólida. Es fundamental comprender y expresar el por qué, el qué y el modo del cambio para cada individuo y su situación.
• El cambio lleva tiempo: puede moverse tan rápido como el equipo pueda adaptarse a las implicaciones de hacer las cosas de maneras nuevas. Los equipos siempre tendrán que hacer los trabajos en curso mientras cambian. Es fundamental priorizar cuidadosamente lo que es más importante y administrar las expectativas de la rapidez con la que se puede producir este cambio. Centrarse en un rastreo, un recorrido y una estrategia de ejecución, donde los elementos más importantes y fundamentales son prioritarios, servirá muy conveniente para su organización.
• Recursos limitados: un desafío al que normalmente se enfrentan las organizaciones al principio es encontrar recursos humanos y aptitudes en el desarrollo de aplicaciones y seguridad. A medida que las organizaciones comienzan a colaborar de forma más eficaz, pueden encontrar recursos humanos ocultos, como desarrolladores con conocimientos de seguridad o profesionales de seguridad con experiencia en desarrollo.
• Cambiar la naturaleza de las aplicaciones, el código y la infraestructura: la definición técnica y la composición de una aplicación están cambiando fundamentalmente con la introducción de tecnologías, como sin servidor, servicios en la nube, API en la nube y aplicaciones sin código, como Power Apps. Este cambio está cambiando las prácticas de desarrollo, la seguridad de las aplicaciones e incluso capacita a quienes no son desarrolladores para que creen aplicaciones.

Nota:

Algunas implementaciones combinan las responsabilidades de seguridad y operaciones en un rol de ingeniero de confiabilidad de sitios (SRE) .

Aunque combinar estas responsabilidades en un único rol podría ser la situación final ideal para algunas organizaciones, suele ser un cambio extremo con respecto a las prácticas empresariales, la cultura, las herramientas y los conjuntos de aptitudes actuales.

Aunque tenga como destino un modelo de SRE, se recomienda empezar por insertar la seguridad en DevOps mediante el uso de logros rápidos prácticos y el progreso incremental descrito en esta guía, para asegurarse de que obtiene una buena rentabilidad de la inversión (ROI) y de que se satisfacen las necesidades inmediatas. Esto agregará de forma incremental responsabilidades de seguridad al personal de operaciones y desarrollo, lo que acercará a los usuarios a la situación final de SRE (si su organización planea adoptar ese modelo más adelante).

Pasos siguientes

Revise los controles técnicos de DevSecOps para obtener instrucciones más detalladas sobre DevSecOps.

Para obtener información sobre cómo la seguridad avanzada de GitHub integra la seguridad en las canalizaciones de integración continua y entrega continua (CI/CD), vea Acerca de la seguridad avanzada de GitHub.

Para obtener más información y herramientas sobre cómo la organización de TI de Microsoft implementó DevSecOps, vea Conjunto de herramientas de seguridad de DevOps.