Cuatro consejos para integrar la seguridad en tus prácticas de DevOps

No cabe duda de que, si todavía no te has planteado usar DevOps, el mercado no tardará en decidir por ti a medida que las empresas se orienten hacia ciclos de distribución de desarrollo de aplicaciones más rápidos. DevOps es una cultura, un movimiento y una práctica que fomenta la colaboración entre los equipos de desarrollo y de operaciones a lo largo de todo el ciclo de vida de distribución del software, desde el diseño y el desarrollo hasta el soporte de producción.  

No obstante, la creciente popularidad del modelo de distribución continuo también plantea nuevos obstáculos operativos y culturales cuando las organizaciones se preguntan cuál es la mejor manera de añadir la seguridad a la ecuación.

Aunque el proceso conlleva algunos problemas iniciales habituales, los beneficios compensan los inconvenientes, ya que las organizaciones entienden que incorporar la seguridad en el proceso mitiga muchos riesgos antes de que se produzcan daños. DevOps tiene que integrar plenamente la seguridad en sus procesos y, por su parte, la seguridad debe hacer la transición cultural a DevOps. 

 Muchas organizaciones ya están integrando la seguridad teniendo en cuenta los resultados empresariales, o tienen pensado hacerlo: el 55 % de las organizaciones encuestadas para el informe «El punto de inflexión de la seguridad en la web», que elaboramos junto con Enterprise Strategy Group (ESG), cuenta actualmente con varios equipos responsables de la seguridad de las aplicaciones web, pero tiene previsto unificar estas responsabilidades en el futuro. 

A esta integración la llamamos DevOps seguro (o DevSecOps), un movimiento que aúna la seguridad con DevOps en todo el ciclo de vida del servicio. Si tu organización es de las que pretende unificar las funciones de DevOps y de seguridad, conviene tener en cuenta ciertos aspectos:

1. Piensa más allá de las funciones de bloqueo

La cultura es la base de cualquier función empresarial, y esto es especialmente cierto en el caso de DevOps. A medida que la seguridad hace la transición cultural a DevOps, los profesionales de la seguridad deben reconocer que, si esta bloquea el progreso y la innovación, será desdeñada y relegada a un segundo plano. 

Crear o fomentar una cultura de funciones de bloqueo en torno a la seguridad no es un modelo sostenible ni con visión de futuro. La seguridad debe encontrar la forma de asociarse con el desarrollo para lograr la máxima sinergia. 

En definitiva, la resistencia cultural por ambas partes puede afectar de manera negativa a la transición de tu organización a DevOps seguro. Los equipos de seguridad y desarrollo necesitarán un gran nivel de colaboración interfuncional y de centralización de las herramientas, las políticas y los procesos.

2. Designa a defensores de la seguridad en todo el organigrama

La presión por un DevOps más seguro no tiene que ser exclusiva de tu equipo de seguridad. Piensa en todo el entorno de tu organización e identifica a los defensores de la seguridad que puedan convencer a los demás para que tengan en cuenta la seguridad a la hora de tomar decisiones. 

No puedes resolver la seguridad de la empresa simplemente contratando recursos adicionales: no hay talento suficiente para satisfacer las necesidades actuales (y eso por no hablar del crecimiento futuro). Por el contrario, las organizaciones centradas en la seguridad más eficaces están hallando nuevas vías para designar a defensores de la seguridad en todo el organigrama interno.

3. Mejora tus bucles de comunicación

En lo que respecta a la seguridad, el peor bucle de comunicación es el de las violaciones de seguridad, ya que pone el nombre de tu empresa en boca de todos, y no por un buen motivo. Los bucles de comunicación son fundamentales y, sin embargo, el desarrollo de software se resiste a este concepto. Para contar con una seguridad óptima en los nuevos ciclos de DevOps, que son más cortos, tus bucles de comunicación deben mejorar. Cuando tu organización se oriente en torno a un ciclo de distribución rápido, tu equipo de seguridad tendrá que poner en marcha bucles de comunicación veloces. 

La obtención de datos reveladores en un entorno de tiempo de ejecución que no deja de cambiar permite a los equipos de seguridad colaborar con DevOps para responder a los eventos antes de que se conviertan en incidentes. Al implementar la protección web proactiva, creas un bucle de comunicación para los equipos de seguridad y DevOps. Podrás responder a preguntas como las siguientes: 

• ¿Estás observando un mayor volumen de inicios de sesión? 

• ¿Qué ocurre con los cambios de contraseña? 

• ¿Se han creado en la última hora más cuentas de lo normal? 

Todas estas preguntas son subjetivas y específicas del mundo empresarial contemporáneo. De hecho, es posible que, a pesar de que ya se esté realizando un seguimiento de algunas de estas métricas en tu organización, estas no sean visibles en toda la empresa. Con un WAF (firewall de aplicaciones web) de última generación, el equipo de seguridad de tu empresa puede crear bucles de comunicación para comprobar comportamientos anómalos que indiquen señales de ataque que se estén produciendo en el momento o que ya hayan tenido lugar.

4. Considera las implicaciones para la seguridad de tratarlo «todo como código»

«Todo como código» (que también se conoce como «infraestructura como código») es la práctica que consiste en expresar como código todo lo que es necesario para crear, ejecutar, probar, cambiar, supervisar, proteger y destruir infraestructuras (y el sistema en su conjunto). Permite que los equipos de DevOps adopten un enfoque repetible y escalable para tareas que de otro modo serían manuales y ayuda a reducir los errores humanos. 

No obstante, los objetivos más generales de la infraestructura como código tienen implicaciones para la seguridad que hay que considerar:

Artefactos controlados por versión 

Los artefactos controlados por versión deben describir el sistema y todos sus componentes. Así, la configuración se mantiene en un estado que puede versionarse y consultarse, fuera de wikis y otros documentos. Además, la gestión de la configuración del sistema debe estar en marcha.

Desarrollo controlado por pruebas y pruebas de integración 

El desarrollo controlado por pruebas y las pruebas de integración deberían pasar a ser prácticas habituales. Escribe pruebas para el código de infraestructura y código de aplicación mientras están en desarrollo. Escribir pruebas mientras se crea la infraestructura garantiza un estado deseado y proporciona un conjunto de pruebas para cualquier esfuerzo en torno a CI/CD.

Informática distribuida y ajuste de escala

Si la infraestructura no se trata como código, es difícil ajustar la escala y la informática distribuida (nube) resulta casi insostenible. Pensar en la informática distribuida y en el ajuste de escala como resultados deseados orienta las prácticas de desarrollo. 

Cadenas de suministro de software

El software no son solo los cientos o miles de líneas de código que escriben los desarrolladores. Contiene mucho más, desde las dependencias del sistema operativo hasta el marco de virtualización. La infraestructura como código fomenta la gestión de la cadena de suministro del software aportando especificidad y un registro auditable al tiempo de ejecución real del sistema.

Ahora depende de ti

Si estás comenzando, lo mejor que puedes hacer para empezar es crear los bucles de comunicación de seguridad. Así estarás instrumentando la seguridad en tus aplicaciones en producción y crearás feedback para los equipos de desarrollo, operaciones y seguridad. Este nivel de instrumentación te ayudará a crear ciclos de desarrollo más rápidos y te puede servir para cambiar la percepción de la seguridad en tu organización: de inhibidor a acelerador de la innovación.

Descarga nuestro informe completo «El punto de inflexión de la seguridad en la web» para obtener más información sobre los problemas a los que se enfrentan las organizaciones con respecto a DevOps seguro y los tipos de herramientas que necesitan para triunfar.