Las 5 mejores formas de ver que DevSecOps no es como el deporte

Está la Copa Mundial del Fútbol, la de Críquet, la de Béisbol, la de Rugby, Wimbledon, más competiciones deportivas de las que nos podemos imaginar. Soy un aficionado al deporte y suelo seguir varios de éstos a la vez. Se podría decir que es una actividad en la que destaco a diferencia de mis intentos fallidos por practicarlos. El deporte me apasiona tanto como la tecnología, una actividad a la que me dedico, y el otro día me preguntaba cómo el deporte puede tener tantas similitudes con el mundo del software, y más específicamente, con el DevOps, un proceso que se está volviendo cada vez más popular porque defiende la idea de que las personas están por encima de los procesos y las herramientas. Y cuando estaba haciendo esta reflexión me di cuenta de que lo que realmente no tiene similitudes con el deporte es DevSecOps. Para explicarlo, aquí tengo cinco ejemplos:

1. No puedes culpar al portero

Perdón por comenzar con un ejemplo tan específico, pero es uno que me concierne de lleno: principalmente porque cuando se elegían los equipos de fútbol en la escuela, a menudo era el último en ser elegido, y terminaba jugando de portero, la posición que no quería nadie. Cuando era abatido por el delantero y la pelota acababa entrando en la portería, aunque la rozara, yo siempre era el culpable.

Atribuir el fracaso a un solo miembro, no solo es malo para la moral del grupo, sino que tampoco representa el trabajo en equipo. Siempre tengo cuidado con la frase "con DevSecOps, la seguridad es responsabilidad de todos", ya que no todo el mundo es un experto en seguridad, pero todos deben asumir la responsabilidad de comprender los procesos correctos y seguirlos, y la culpa nunca debe ser atribuida a una sola persona cuando algo sale mal. Y no lo olvide: con DevSecOps se tienen todas las oportunidades para solucionar cualquier cosa que salga mal, arreglarlo rápidamente y realizar pruebas para garantizar que la misma vulnerabilidad nunca vuelva a exponerse.

2. No sabes quién es tu oponente

Cuando practicas deportes, generalmente está bastante claro quién es tu oponente, dónde está y qué está haciendo en cada momento. Es posible que no puedas detenerlo todas las veces que lo intentes, pero al menos sabes quién es y qué está tratando de conseguir. En el caso de DevSecOps, eso es incluso menos cierto que en el mundo normal de los proyectos de software, porque – “entre nosotros” – estarás desarrollando, probando y operando múltiples capas del montón, y eso hace que tus contrincantes pueden ser varios, con diferentes habilidades y recursos. La buena noticia es la frase "entre nosotros". Si realmente trabajas en equipo, el conocimiento conjunto de varios expertos puede ser aplicado a través de capas de abstracción de manera que sea difícil entrar en tu modelo estándar de "diseño, desarrollo, prueba, implementación", y a su vez te ofrece mayor y profundo conocimiento sobre las formas de mejorar la seguridad de tu proyecto.

3. No estás jugando con las mismas reglas que tus oponentes

Esto es algo duro. Cuando practicas deporte, hay reglas a seguir, y ambos equipos tienen que cumplirlas, para evitar sanciones por parte del árbitro. Es cierto que nos encantaría vivir en un mundo donde nuestros oponentes siempre fueran capturados y castigados cuando intentan atacar tu infraestructura y aplicaciones, pero lamentablemente, parece que eso no va a pasar a corto plazo. Dado que es poco probable que puedas perseguir a tu oponente en tiempo real con un contraataque activo, debes considerar qué mitigaciones puedes implementar, cómo aplicarlas y qué tan rápido puedes ser. Es importante destacar que este no debe ser un área exclusiva para los miembros de seguridad del equipo. Aunque los expertos en seguridad pueden dar buenas predicciones sobre qué ataques podrían ocurrir, son los ingenieros y operadores de la central quienes están mejor ubicados para anticiparse a cualquier posible impacto en el funcionamiento del sistema, y quienes deberían diseñar las mitigaciones apropiadas para cuando lleguen los problemas.

4. Todo el equipo puede jugar todos los partidos, todo el tiempo

En la mayoría de los deportes de equipo, solo puedes tener parte de tu equipo en el campo en un momento determinado. Una de las alegrías de DevSecOps es que todos pueden participar durante todo el proceso. El entrenador no tiene que permanecer al margen, y puede traer al psicólogo del equipo, al experto en rendimiento y a los técnicos cuando sea necesario. Como eres susceptible a ser atacado en cualquier momento, no pasará mucho antes de que cada miembro del equipo tenga algo que aportar a medida que surjan cambios en la aplicación, el entorno de implementación o los entornos de seguridad. Los equipos de DevSecOps tampoco deben estar aislados de otras partes de la organización: si necesitas llevar ayuda durante un día o dos, hazlo. No tengas miedo de moverte rápido y admitir que necesitas ayuda.

5. Está bien fallar… repetidamente

Cuando pensamos en el deporte, pensamos en cómo nuestros equipos deben ganar cada juego. De hecho, los mejores deportistas y los mejores equipos deportivos también saben cómo perder y cómo recuperarse de una derrota, y eso los fortalece. En DevSecOps, deberíamos alentar a nuestros equipos a fallar, porque es solo a través de la experiencia y la observación de fallos que nuestras aplicaciones y proyectos podrán mejorar. Ya nadie cree que los sistemas o aplicaciones son invulnerables: no se trata de un caso de ataque y violación, sino de cuándo sucederá. Diseña tus procesos en torno a eso: monitorea el comportamiento anormal, prepárate para mitigar, pero, sobre todo, asegúrate de tener procesos para aprender de los errores y construir un proyecto mejor, más robusto y más resistente para el próximo ataque.

Por último

No quiero decir que no haya similitudes entre DevSecOps y el deporte, hay muchas coincidencias por supuesto. Algunos de los ejemplos más obvios son cómo hacer un cambio importante que requiere un compromiso de arriba hacia abajo y de abajo hacia arriba; la importancia de formar un equipo cuyos miembros puedan comunicarse bien entre ellos; y la capacidad de reaccionar a las amenazas en tiempo real. Nunca voy a sugerir que todo se trate de la diferencia. Pero a veces es mejor comparar algo con algo que es opuesto y no un equivalente. Disfruta de tu verano deportivo y de DevSecOps.

Es una tribuna de opinión de Mike Bursell, Chief Security Architect, Red Hat