El proceso de DevSecOps

Hay distintas prácticas que deben integrarse en el entorno de DevSecOps y en puntos estratégicos del pipeline. Los procesos definidos para estas prácticas deben garantizar que la seguridad esté integrada en el desarrollo de una manera que facilite el trabajo de los desarrolladores y no genere obstáculos para implementar cambios a un ritmo acelerado.

Reducir las fricciones en la entrega

Un concepto que surgió del éxito de Netflix y que se está adoptando como estrategia para la cultura DevSecOps es la idea de la «ruta pavimentada». Este concepto consiste en enfocarse en crear una ruta con poca fricción para que el software pase de la idea a producción. Por lo tanto, al tomar decisiones que puedan afectar o influir de alguna manera en esos procesos de entrega, se debe considerar si facilitan el trabajo de los desarrolladores o crean obstáculos para la entrega. Estos últimos deben minimizarse o, idealmente, evitarse por completo.

Un aspecto importante para establecer una cultura DevSecOps es eliminar las fricciones entre los equipos fomentando la empatía.

Para adoptar este enfoque, se necesita el apoyo de muchas áreas de la organización, pero todo comienza en los niveles ejecutivos. Si los líderes del negocio no impulsan el cambio cultural, simplemente no habrá cambios. El liderazgo debe promover desde los niveles más altos la adopción de los principios de la ruta pavimentada en toda la empresa. Los valores corporativos deben dejar claro que todos son responsables de entregar productos seguros a los clientes con rapidez. A partir de ahí, es más fácil priorizar prácticas que reduzcan la carga del proceso de entrega de software.

Modelado de amenazas

El informe DevSecOps Insights 2020 reveló que el modelado de amenazas tiene un impacto significativamente positivo en la confianza general del equipo en la seguridad de su código. Lamentablemente, durante mucho tiempo se ha considerado que el modelado de amenazas requiere mucho trabajo. Como resultado, cuando las organizaciones adoptan un enfoque de DevOps/DevSecOps, suelen excluir el modelado de amenazas de las prácticas de seguridad que aplican. Sin embargo, no se debe pasar por alto el impacto del modelado de amenazas en el desarrollo. 

En esencia, el modelado de amenazas busca analizar el software planificado para identificar qué podría salir mal si un atacante lo eligiera como objetivo. El propósito de este análisis es informar al equipo de desarrollo qué controles de seguridad debería considerar como parte de la implementación. Tradicionalmente, el modelado de amenazas se ha realizado con un alcance amplio que abarca todo el contexto de la aplicación. En este proceso se suelen usar diagramas de flujo de datos, marcos detallados para el análisis de amenazas y metodologías prescriptivas para priorizarlas.

Sin embargo, en un modelo DevSecOps, las metodologías de modelado de amenazas que requieren mucho tiempo y recursos son un obstáculo. Aun así, se puede usar un enfoque simplificado dentro del pipeline. DevSecOps suele aprovechar prácticas del desarrollo ágil, como la gestión del backlog del producto. En lugar de diseñar un sistema completo, las nuevas funciones y mejoras se agregan al backlog mediante historias de usuario. Estos elementos manejables e independientes son fundamentales para facilitar el desarrollo a un ritmo acelerado. Las organizaciones pueden abordar el modelado de amenazas de la misma manera.

En lugar de considerar el modelado de amenazas un proceso que debe realizarse en una aplicación monolítica, se pueden implementar prácticas sencillas de modelado de amenazas en el backlog. Al redactar una historia de usuario, también se debe incluir una breve descripción de las amenazas que esta introduce o afecta. Se deben identificar las funciones o los datos confidenciales que forman parte de la historia. Si esta información está disponible para los desarrolladores en el backlog, se cumple el objetivo del modelado de amenazas de una manera que puede acelerar el desarrollo de cada historia.

Control de versiones, metadatos y orquestación

En un mundo automatizado, lo único constante es el cambio, y este debe ser uniforme y rastreable. Para llevar un registro de todos los cambios, DevSecOps debe garantizar que haya un control de versiones adecuado e inmutable. Cada acción debe tener una versión, al igual que el código, para permitir una recuperación rápida. Una vez convertidos en metadatos, los equipos de operaciones pueden hacer un seguimiento eficiente de los cambios y medirlos.

El software de orquestación no solo ofrece una forma repetible de implementar la infraestructura, sino que también proporciona una gran cantidad de metadatos sobre cada tarea. A su vez, esos metadatos pueden ser utilizados no solo por el propio software de orquestación, sino también como fuente confiable para las herramientas integradas. Al combinarse con el control de versiones, el software de orquestación se convierte en una fuente de información poderosa para todos los equipos de operaciones.

Cumplimiento normativo

Implementar iniciativas de cumplimiento normativo no tiene por qué ser un ejercicio basado en documentos. En su lugar, las organizaciones pueden crear metadatos que representen los requisitos de cumplimiento e integrarlos directamente en sus recursos. También se pueden usar para automatizar las políticas de seguridad mediante etiquetas en los recursos, que a su vez permiten implementar la arquitectura de seguridad deseada, por ejemplo, la segmentación por zonas.

Este enfoque permite cumplir con los requisitos a escala. Por ejemplo, puede hacer realidad la capacidad de responder a una filtración de datos en un plazo de 72 horas, según las nuevas reglas del RGPD. Al codificar los requisitos de cumplimiento en DevSecOps, el proceso de desarrollo pasa a facilitar el programa de cumplimiento.

Arquitectura de seguridad

La arquitectura de seguridad se basa en un conjunto de principios específicos de cada empresa. Estos principios dependen del tipo de datos que se procesan, aunque un conjunto de principios de alto nivel puede guiar la entrega de software hacia prácticas más seguras. Las organizaciones que adoptan un modelo DevSecOps deben garantizar que existan procesos para establecer y actualizar continuamente estas arquitecturas. Esto permite desarrollar software con mayor rapidez y seguridad.

Codificar estos principios como parte de la cultura DevSecOps y tenerlos disponibles e incluidos en el backlog permite a los gerentes de producto integrar la seguridad sin problemas en sus planes y en la arquitectura correspondiente. Si se producen desviaciones debido a procesos del negocio o a la falta de recursos, se registran y se tiene en cuenta el riesgo asociado. En última instancia, estas desviaciones pueden abordarse como cualquier otro error y monitorearse hasta su resolución.

Gestión de incidentes

La respuesta a los incidentes de seguridad no debe improvisarse ni dejarse al azar. Es fundamental crear de antemano flujos de trabajo, planes de acción, playbooks y runbooks. Esto garantiza que la respuesta a un incidente sea uniforme, repetible y medible. La gestión de incidentes debe aprovechar los metadatos para simplificar este proceso y cambiar las métricas para destacar el tiempo que toma volver a implementar un recurso comprometido. Al desarrollar los playbooks, los procesos que se definan deben contemplar todo tipo de incidentes. Así como DevSecOps integra distintas funciones, también deben hacerlo los procesos que lo implementan. Por eso, los procesos de gestión de incidentes deben tener un nivel de abstracción que permita tratar los incidentes operativos y de seguridad con el mismo marco de trabajo. Este es otro paso eficaz para reforzar la cultura de responsabilidad compartida, crucial para DevSecOps.

Una vez que los playbooks se hayan codificado, se pueden integrar en el pipeline de CI/CD para automatizarlos. En un entorno DevSecOps, la búsqueda proactiva y preventiva de amenazas, junto con la detección y respuesta continuas ante amenazas y vulnerabilidades, se traducen en menos incidentes graves y más medidas de mitigación. Las pruebas de penetración, los ejercicios de red team y los programas de recompensas por errores ofrecen una capa adicional de mitigación frente al riesgo de filtraciones. Si bien la detección continua es muy útil, las organizaciones deben estar atentas a la fatiga por alertas. Para evitarla, deben establecer ciclos de retroalimentación que impulsen la mejora continua del monitoreo y una mayor automatización en la evaluación y respuesta a las alertas.

Evaluaciones de seguridad proactivas

Sin importar cuánto avance la metodología DevSecOps de una organización, sigue siendo necesario identificar vulnerabilidades de forma activa.  El término pruebas de penetración suele referirse a los esfuerzos por identificar exhaustivamente las vulnerabilidades dentro de un alcance determinado. El red team se diferencia porque suele enfocarse más en imitar las motivaciones y tácticas reales de un atacante. Por ejemplo, mientras una prueba de penetración puede buscar todas las páginas de una aplicación vulnerables a un ataque de inyección SQL, una evaluación de red team quizá identifique solo una o dos páginas vulnerables y use esas vulnerabilidades para explotar aún más la aplicación.

Pruebas de penetración

Las pruebas de penetración suelen ser la primera etapa de madurez en la gestión de vulnerabilidades en las aplicaciones. El objetivo de estas pruebas es identificar las áreas de una aplicación que podrían ser vulnerables a algún tipo de ataque. Lo ideal es que estas evaluaciones proporcionen una visibilidad integral de la postura de seguridad general y permitan corregir las vulnerabilidades de riesgo. Sin embargo, obtener una visión completa de las vulnerabilidades de la aplicación puede llevar mucho tiempo. Por eso, en DevSecOps, aunque estas pruebas son un requisito básico de higiene de seguridad, suelen realizarse después de la etapa de producción.

Red team

Las evaluaciones de red team suelen realizarse en organizaciones con un alto nivel de madurez. Son un paso adicional a las pruebas de penetración. En un enfoque de red team, el objetivo no es identificar tantas vulnerabilidades como sea posible. En cambio, se basa más en objetivos y se parece más al enfoque que adoptaría un atacante. Por lo general, el alcance no se limita a una sola aplicación, sino que abarca todos los sistemas del entorno. Esto permite a la organización comprender cómo se pueden combinar las vulnerabilidades de varios sistemas para llevar a cabo un ataque. También brinda más contexto sobre el impacto previsto de un ataque exitoso. Por lo tanto, estas evaluaciones requieren más habilidades y una mayor diversidad de conocimientos que las pruebas de penetración tradicionales. A medida que madura el enfoque DevSecOps de una empresa, puede explorar la posibilidad de incluir ejercicios de red team como parte de sus prácticas regulares de higiene de seguridad.

Programas de recompensas por errores

En los últimos años, los programas de recompensas por errores han recibido mucha atención, en parte gracias a los programas colaborativos disponibles. Estos programas definen el alcance, los requisitos y los métodos de reporte para que hackers externos intenten identificar vulnerabilidades en el entorno de una organización. A cambio de respetar estas reglas, reciben una «recompensa» por las vulnerabilidades que reportan a la organización.

Aunque los programas de recompensas por errores son una excelente manera de incentivar a terceros a divulgar vulnerabilidades de forma responsable y ofrecen una capa adicional para identificarlas, no deben reemplazar las pruebas de penetración. Por lo general, los investigadores de seguridad que participan en estos programas no tienen como prioridad los intereses de la organización. No buscan identificar todas las vulnerabilidades de forma exhaustiva y la mayoría busca solo los hallazgos de mayor gravedad, que les permiten obtener las recompensas más altas.

Inteligencia de amenazas

A medida que se definen y documentan más componentes del entorno en código, también aumenta la visibilidad de la inteligencia de amenazas. A muchas organizaciones les cuesta identificar sus recursos de TI de una manera que les permita vincular eficazmente la inteligencia de amenazas recibida con los recursos de su entorno. Si establecen procesos para enviar metadatos desde el pipeline de DevSecOps a las capacidades de inteligencia de amenazas, pueden garantizar que se recopile la inteligencia adecuada y que se aplique y se utilice para responder según la prioridad de riesgo correspondiente.