Cambiar la seguridad en DevOps implica cambiar la mentalidad.

Hace mucho tiempo, cuando era un joven y tonto administrador de sistemas UNIX (ahora solo soy una de esas cosas), cometí un error de seguridad bastante grave en uno de los servidores que ejecutaban nuestros sistemas de respaldo. No entraré en detalles, pero tenía que ver con el comando sudo, un editor de texto y la ignorancia.

Afortunadamente, uno de los administradores de sistemas más experimentados (y, francamente, más inteligentes) me respaldaba. Se dieron cuenta de mi nuevo procedimiento, lo investigaron… y luego, cortésmente, me llevaron aparte para explicarme el error de mis métodos. Luego dedicaron tiempo a ayudarme a encontrar una solución que aún brindara a las personas la función de autoservicio que necesitaban, pero con menos posibilidades de catástrofe. En mi memoria autoeditada y poco confiable, estaba agradecido por las mejoras, tanto para mí como para mi configuración.

Ese comportamiento de compartir, colaborar y resolver problemas sin culpar a nadie se ha mantenido conmigo a través de los años y espero haber podido ocasionalmente ayudar a alguien con sus errores de seguridad.  

En esa línea, no fue ninguna sorpresa al leer el informe Puppet State of DevOps descubrir que cuando se integra la seguridad en una etapa más temprana del ciclo de vida de la entrega de software, el resultado es (espere) una mejor seguridad.

Al observar el informe, queda claro que las ventajas de trasladar la seguridad al ciclo de vida del software dependen tanto de trasladar los principios de comportamiento de DevOps a los equipos de seguridad como, si no más, de trasladar las herramientas de seguridad a las tuberías.

Mientras que las prácticas operativas de seguridad más tradicionales se centran en las pruebas y los controles (la mayoría de los equipos de aplicaciones habrán recibido un informe de seguridad generado por una herramienta que muestra múltiples problemas que deben abordarse), un enfoque basado en los principios de DevOps fomenta la colaboración temprana, el intercambio y la responsabilidad conjunta.

Al observar la sección “Mejorar la postura de seguridad” del informe (que comienza en la página 31), es importante apreciar cuánto depende de la inyección sin fricciones de pensamiento de seguridad en el diseño y la construcción de software e infraestructura, en lugar de simplemente implementar los controles y la tecnología adecuados.

Si los beneficios dependen de compartir e integrar las habilidades y la mentalidad de los profesionales de seguridad en el núcleo del proceso de distribución de software, entonces algunos de los cambios más significativos serán de comportamiento.

Sumergir a un equipo de seguridad en las primeras etapas del ciclo de vida del desarrollo de software sin duda requerirá que se adapte, pero estos cambios deberán darse en ambas direcciones. Si bien los profesionales de seguridad tendrán que adoptar nuevas formas de trabajar (y probablemente aprender a hablar más "dev" que en la actualidad), el equipo de desarrollo probablemente tenga que adoptar el Tao del cable Andon .

Si no ha investigado el cable Andon y su lugar en el proceso de fabricación de control de calidad iniciado por Toyota, entonces vale la pena dedicarle tiempo. Hay artículos, trabajos académicos, libros completos e incluso cursos de educación superior que cubren el tema. Pero antes de que abandones tu carrera tecnológica para cursar ese MBA que siempre te prometiste, termina de leer este artículo, porque creo que el hecho más significativo del cordón Andon es a la vez el más sencillo y el más difícil de conseguir.

Cuando un trabajador de una línea de producción tira de su cordón Andon para detener la producción debido a un defecto, lo primero que hacen sus compañeros y el equipo directivo es correr a agradecerle. Y tienen que decirlo en serio. Tirar del cordón Andon se considera algo positivo, ya que supone un paso hacia la mejora de la calidad. Los gerentes y compañeros de trabajo están agradecidos de que la línea de producción se detenga debido a un problema, porque esa es una oportunidad para mejorar.

¿Puede su equipo de desarrollo aceptar con gratitud que el equipo de seguridad encuentre defectos y tire del cable (virtual)? ¿Puede un equipo de DevOps aprender a valorar las compilaciones o implementaciones que no superan las pruebas de seguridad tanto como las que las superan?

¿Podrán los futuros dueños de negocios aprender que, para crear un excelente software, debemos buscar fallas de pruebas más frecuentes a medida que desarrollamos pruebas cada vez mejores que identifiquen los problemas antes de que se vuelvan evidentes en una implementación?

Esa puede ser una adaptación mental difícil.

Si bien agradezco las inevitables correcciones de edición que se habrán aplicado a este artículo en el momento en que lo lea, no siempre es fácil ver lo que usted creó diseccionado por otros. Tu cerebro racional sabe que ofrece un mejor producto, pero tu chimpancé interior sólo quiere agitar los brazos.

Por lo tanto, si bien puede ser una mentalidad difícil de adoptar, es fundamental para el éxito en la integración de la seguridad en las primeras etapas del ciclo de vida del software, y es mucho mejor que las revisiones posteriores y las remediaciones apresuradas existentes.

El cambio de actitudes es un área de estudio totalmente distinta, pero los líderes y profesionales de TI deben dominarlo, especialmente en estos tiempos de revolución en las formas de trabajar. A menudo es (mucho) más difícil que simplemente adoptar una nueva tecnología. Si desea avanzar con éxito hacia la izquierda en materia de seguridad (y los datos de este informe indican que debería hacerlo), tómese el mismo tiempo que dedica a los elementos humanos y a los técnicos.