En primer lugar, consideremos DevOps. DevOps comenzó como un principio operativo que luego se cooptó en productos, equipos y otros elementos específicos. Originalmente, DevOps era algo que se hacía, no algo que se era. Se basaba en el principio de que para que el software funcione con eficacia es necesaria una comunicación abierta y compartida entre los que crean el software (desarrollo) y los que lo ejecutan (operaciones).
Está diseñado para romper los silos de "desarrollo" y "operaciones" y crear un vocabulario común, un conjunto de prácticas y un modelo de responsabilidad compartida para ayudar a estos dos equipos a ser un solo equipo. Parte de esto incluye ayudar a los desarrolladores a pensar como operarios y a los operarios a pensar un poco más como desarrolladores. La polinización cruzada conduce a una mejor instrumentación, registro y metodologías de despliegue por parte de los desarrolladores. Y aporta la infraestructura como código, la configuración como código y otras prácticas de automatización al lado de las operaciones.
El resultado neto es un software más fácil de desplegar y utilizar, con un menor coste operativo y ciclos de lanzamiento más rápidos.
La seguridad entra en juego cuando nos damos cuenta de que crear software más rápido y utilizarlo más barato puede crear nuevos riesgos. Tenemos que encontrar la forma de asegurarnos de que nuestro equipo de seguridad está incluido en el proceso unificado. Y asegurarnos de que los equipos de desarrollo y operaciones piensan en la seguridad cuando hacen su trabajo.
Y tenemos que hacerlo sin ralentizar el negocio.
DevSecOps nos ayuda aportando los mismos conceptos básicos de DevOps e incluye la seguridad. La seguridad se convierte en una parte integral de las prácticas de desarrolladores y operaciones. Para ello, incorpora varias prácticas y tecnologías específicas al ciclo de vida del software.
Desarrollo de software
Los equipos de desarrollo de software llevan décadas escribiendo software seguro. La formación OWASP y otras técnicas han ayudado a arquitectos y desarrolladores a evitar errores importantes en materia de seguridad. DevSecOps se basa en estas prácticas a través de la responsabilidad compartida y la automatización.
La responsabilidad es un principio clave de DevOps y del cambio cultural necesario para adoptarlo plenamente. La idea es que todo el equipo es responsable del funcionamiento de la tecnología en el entorno de producción y de aportar valor a la empresa. No sólo es responsable el equipo de operaciones, sino todo el mundo.
Del mismo modo, DevSecOps responsabiliza a todo el equipo de operar el producto de forma segura en producción. No es sólo el equipo de ciberseguridad el que incorpora la seguridad en el último minuto, sino que todo el mundo está pensando en cómo incorporar la seguridad. Al crear esta responsabilidad compartida, la seguridad ya no es el equipo que dice "no", sino el que responde "cómo".
Una de las formas más sencillas de hacer que el software sea más seguro sin sobrecargar el proceso es la automatización. Al igual que con la automatización del proceso de creación y despliegue, podemos utilizar herramientas y tecnologías para automatizar los requisitos de seguridad más comunes.
Las dos más comunes son las pruebas dinámicas de seguridad de aplicaciones (DAST) y las pruebas estáticas de seguridad de aplicaciones (SAST). Se trata de productos que se incorporan al ciclo de vida existente de creación y publicación. Las pruebas SAST se ejecutan durante el proceso de creación y buscan vulnerabilidades comunes en el código. DAST se ejecuta después del despliegue contra una aplicación en vivo (pre-producción por lo general) y las pruebas en busca de vulnerabilidades comunes.
No vamos a entrar en detalles sobre los productos o técnicas DAST o SAST. Dado que son tecnologías automatizadas, también están controladas por código. Como miembro del equipo DevSecOps, estás definiendo cómo probar y qué probar, incluyendo qué reglas aplicar, en tus archivos de configuración de "Seguridad como Código". Esto se une a las prácticas de Infraestructura como código y Configuración como código en el lado de la infraestructura y las operaciones.
La automatización ayuda a garantizar que podemos aplicar prácticas de codificación seguras sin ralentizar significativamente el ciclo de vida del desarrollo. La responsabilidad compartida ayuda a garantizar que todo el equipo adopte las mejores prácticas y responda a los resultados de las pruebas automatizadas.
DevSecOps es un cambio cultural
DevSecOps no se consigue comprando un producto o contratando a un especialista. Estos son componentes de un DevSecOps exitoso, pero no son suficientes para crear una cultura DevSecOps exitosa. En su lugar, todos los niveles de participación deben formar parte del plan, desde los equipos técnicos hasta la dirección empresarial.
Cada uno de los equipos técnicos debe comprender su función única en la creación de software seguro. Los propietarios de producto y otros autores de historias de usuario deben pensar en cómo encaja la seguridad en la funcionalidad del producto. El equipo de experiencia de usuario debe comprender el impacto de la seguridad en la usabilidad. Los arquitectos deben seleccionar tecnologías y arquitectos seguros. Los desarrolladores deben escribir software siguiendo patrones seguros. Los encargados de las pruebas tienen en cuenta tanto los requisitos funcionales como los de seguridad a la hora de desarrollar planes de pruebas y pruebas automatizadas. Los equipos de operaciones tienen la carga de proporcionar un entorno de alojamiento seguro.
La seguridad está entretejida en todo el equipo de producto. Pero si tampoco forma parte de la cultura de liderazgo, entonces fracasará inevitablemente. Cuando se acerca un plazo crítico, ¿buscará la dirección cosas que recortar para llegar a la fecha? ¿Se tendrá en cuenta la seguridad? Si es así, ¿se trata de una decisión basada en el riesgo, o simplemente de un recorte porque la cultura no está totalmente adoptada?
Poner en marcha DevSecOps
Como con cualquier cambio de cultura corporativa, la adopción de DevSecOps requiere un defensor. El campeón puede ser de seguridad, producto o liderazgo. Una vez que el campeón ha aceptado su papel, entonces deben comenzar su campaña de cambio de cultura.
La primera parte es entender dónde se encuentra la organización en la actualidad. ¿Qué prácticas DevSecOps están ya en marcha? ¿Realizan ya formación OWASP para desarrolladores? ¿Se aplican soluciones DAST o SAST? Tal vez ya se somete a una auditoría SOC 2 o tiene la certificación ISO 27001. Cualquier práctica segura existente es la base sobre la que se pueden construir las DevSecOps. Si todavía no hay ninguna, entonces hay más trabajo, pero adoptar DevSecOps puede ayudarle a priorizar algunas victorias rápidas a la hora de introducir la seguridad en su organización.
Partiendo de esta base, el esfuerzo consiste en reunir a todas las partes interesadas y ayudarles a comprender lo que se espera de ellas y, del mismo modo, cuál será su beneficio. Cada grupo se beneficiará de DevSecOps, y tendrá que ver que la recompensa merece el esfuerzo. Dé a cada grupo un asiento en la mesa y permítales compartir sus preocupaciones. ¿Será DevSecOps más caro? ¿Nos ralentizará? ¿Tenemos en cuenta nuestras obligaciones contractuales y legales? ¿Dificultará nuestro trabajo?
Prepárate para conocer las respuestas a preguntas como estas, o cómo harías para encontrar la respuesta. Lo más probable es que las preocupaciones de cada grupo deban abordarse con el tiempo. DevSecOps no puede suceder de la noche a la mañana, por lo que elegir qué preocupaciones abordar primero, y cuáles vendrán más tarde en su hoja de ruta de adopción, es la clave para hacer un esfuerzo exitoso y manejable.
DevSecOps es fundamental para crear y utilizar software seguro. Entendiendo qué es y qué aporta a una organización, puedes empezar a construir un plan para adoptarlo dentro de tu organización. Comprender que se trata de un cambio cultural y saber quién está preparado y quién se resiste ayudará a que tenga éxito. La recompensa merecerá la pena.
Si necesita ayuda para adoptar DevSecOps o decidir si debería hacerlo, el equipo de consultoría de Improving puede ayudarle. Póngase en contacto con nosotros para una conversación rápida sobre dónde estás hoy y hacia dónde te gustaría ir.
Erik habló sobre este tema durante un seminario web de Improving. Para ver la grabación del debate, HAGA CLIC AQUÍ
