¿Por qué DevSecOps?

Existe la idea general de que cuanto más rápidos sean nuestros métodos de desarrollo e implementación, más propensos a tener problemas de seguridad. Y a medida que llegamos a un punto en el que el desarrollo es ágil, rápido y funcional, comenzamos a cuestionarnos: ¿Es todo esto seguro? Y lo que es más importante, ¿qué se necesitará para mejorar la seguridad de nuestros proyectos?

A medida que las prácticas de DevOps maduraron en la industria, la seguridad se dejó en la periferia y solo ahora estamos comenzando a ver mejoras. Con un desarrollo ágil e implementaciones de código rápidas, también vimos una ola de introducciones rápidas de vulnerabilidades en las aplicaciones. Y dado que la mayoría de las pilas de DevOps priorizan la funcionalidad y la velocidad sobre la seguridad, a los profesionales a menudo se les desaconseja pasar por controles de seguridad, ya que ralentiza el proceso. Sin embargo, brechas reveladoras como la de British Airways de 2018 , demostraron lo importante que es mejorar nuestras prácticas de DevOps e integrar tantos controles de seguridad como sea posible. Especialmente después de ver las consecuencias legales y las multas de GDPR a las que British Airways enfrentó recientemente.

DevOps “frente” DevSecOps

La fusión de desarrollo y operaciones es bastante natural. Los equipos de desarrollo y de operaciones siempre han tenido el mismo objetivo en mente: lanzar aplicaciones funcionales a los clientes lo más rápido posible. Sin embargo, la seguridad parece ser un obstáculo en el proceso. El desarrollo y las operaciones apuntan a una liberación rápida y funcional. Por otro lado, la seguridad, con todas las auditorías y pruebas que consumen mucho tiempo, parece estar ralentizando los lanzamientos, lo que dificulta el proceso de DevOps. Sabiendo esto, no sorprende que muchos desarrolladores consideren que la seguridad es un obstáculo en lugar de una parte necesaria y complementaria del ciclo de vida del desarrollo de software (SDLC). De ahí es de donde proviene esta dialéctica “DevOps vs. DevSecOps”. Sin embargo, últimamente hemos visto a muchos profesionales de la seguridad comenzar a comprender que si la seguridad no se desplaza hacia la izquierda en el SDLC, quedará fuera de la era DevOps. Cuanto antes ingrese la seguridad al SDLC, menos impedimento será para los desarrolladores ágiles. Aunque incorporar seguridad en DevOps podría ralentizar un poco el proceso de desarrollo, generalmente disminuirá el tiempo de comercialización y mejorará el bienestar de su empresa.

Entonces, ¿están DevOps y DevSecOps en lados opuestos?

Aunque parezcan serlo, los dos no se contradicen. Sabemos que la seguridad debe cuidarse de alguna manera, y cuál es una mejor manera de hacerlo que no sea fomentar la sinergia entre el desarrollo, las operaciones y la seguridad desde el principio. Hacer de la seguridad una parte crucial de su flujo de trabajo no es necesariamente un cambio de DevOps, sino un avance del sistema anterior.

Bueno, ¿cómo se puede convertir DevOps en DevSecOps?

Aquí hay algunas reglas o mejores prácticas para ayudarlo a lograrlo:

Regla 1: Empiece fácil y automatice

Cuando intentamos incorporar la seguridad en las prácticas de DevOps, nos encontramos con dos problemas: la velocidad y la falta de conciencia con respecto a la seguridad. Es por eso que, cuando comienza a convertir DevOps en DevSecOps, debe asegurarse de que el proceso sea rápido y fluido para los desarrolladores. Quiere “facilitar” la seguridad de su ciclo de vida de desarrollo. Para hacer eso, es importante evitar frustrar a los desarrolladores con molestias como falsos positivos, herramientas de seguridad que son difíciles de entender y revisiones largas de código. Al mismo tiempo, desea automatizar la seguridad lo más posible en su flujo de trabajo para que los problemas de seguridad se puedan encontrar desde el principio. Para colmo, dado que son los desarrolladores los que solucionarán las vulnerabilidades, querrá asegurarse de que sepan cómo solucionarlas correctamente o de que tengan la orientación correcta y relevante.

Entonces, ¿cuál es tu primer paso aquí?

Debe asegurarse de que la implementación de aplicaciones seguras sea fácil para los desarrolladores y que se pueda hacer rápidamente. Para hacer eso, necesitará una herramienta que sea comprensible e intuitiva para los desarrolladores, y que al mismo tiempo automatice su proceso de prueba de seguridad.

Ahí es donde entran en juego las herramientas de prueba de seguridad de aplicaciones (AST). Hay dos tipos principales de AST (hay más de dos, pero estos son los más comunes): AST D (dinámico) y AST S (estático). La diferencia entre los dos es que las herramientas SAST escanean el código en busca de vulnerabilidades y las herramientas DAST escanean la aplicación una vez que es funcional. Dado que las herramientas DAST intentan atacar la aplicación y encontrar problemas de seguridad como lo haría un pirata informático, informan hallazgos mucho más relevantes con evidencia sustancial sobre la vulnerabilidad. Un escáner SAST puede parecer la opción correcta aquí porque escanean el código antes en el flujo de trabajo. Sin embargo, el hecho es que los escáneres SAST informan muchos más falsos positivos y los hallazgos irrelevantes pueden rechazar a los desarrolladores. Por otro lado, los resultados de DAST son más fáciles de entender para los desarrolladores, y dado que muestran las consecuencias de una vulnerabilidad, el desarrollador tiene una idea de la gravedad del riesgo. La mayoría de los buenos escáneres DAST también tendrán complementos y potentes API que le permitirán integrarlos con herramientas populares de CI, como CircleCI. Algunos de ellos, como Probely , proporcionará a sus desarrolladores una guía personalizada sobre cómo solucionar los problemas encontrados.

Los escáneres DAST son un buen primer paso para convertir DevOps en DevSecOps. Hacen que sea menos frustrante para los desarrolladores lidiar con el escaneo de vulnerabilidades y más fácil para ellos comprender el riesgo de seguridad.

Regla 2: Priorizar

La velocidad es clave cuando se trata de DevSecOps y la priorización es clave para la velocidad. Cuando se trata de integrar la seguridad en sus prácticas DevOps establecidas, la automatización y la velocidad no deberían verse afectadas. Para lograrlo, debes priorizar. Debe asignar cada aplicación y cada vulnerabilidad a un riesgo. Por ejemplo, desea prestar más atención a la seguridad de una aplicación que trata con información confidencial de los clientes. Además, querrá tomar el contexto de cada vulnerabilidad y asignarla al riesgo potencial que tiene para su negocio o empresa. Cuando haga eso, priorice las vulnerabilidades con una puntuación de alto riesgo. Probely, como escáner DAST, automáticamente hace parte del trabajo por usted. Clasifica las vulnerabilidades, dado el contexto, en tres categorías: alta, media y baja.

La priorización lo ayuda a concentrarse en lo que importa y evita que cargue demasiado trabajo a sus desarrolladores. Esto le ayudará con la sinergia Dev-Sec.

Regla 3: Demuestre y eduque

Al integrar la seguridad en su empresa, no basta con incorporar las prácticas de DevSecOps, establecer reglas y pedir a las personas que las sigan. DevSecOps tiene mucho más que ver con la cultura de la empresa que con un conjunto de prácticas de procedimiento. Es una forma de organizarse y pensar. Puede comenzar por educar a sus desarrolladores y otros empleados sobre la seguridad. Puede comenzar proporcionándoles esta lista de verificación de seguridad de aplicaciones web . A menudo, los desarrolladores y el personal de su empresa no comprenderán la importancia de la seguridad y subestimarán muchos de los riesgos. Para educarlos adecuadamente, querrá demostrar el proceso y los riesgos.

Educar a los desarrolladores sobre la codificación segura y el conocimiento no es suficiente. La cultura de su empresa debe abarcar la seguridad como un todo. Además de demostrar la evidencia de vulnerabilidades y exploits proporcionados por su herramienta DAST a su personal técnico, también debe hacer demostraciones en toda la empresa. Los ataques de phishing e ingeniería social falsos, pero bien elaborados, dirigidos tanto al personal técnico como al no técnico, brindan mucha visibilidad y participación. Por tanto, la educación y la sensibilización sobre este tema son fundamentales. Puede comenzar demostrando las implicaciones de un ataque de phishing realizando usted mismo un ataque de phishing “simulado”. Envíe un correo electrónico malicioso y vea cuántos empleados de su empresa hacen clic en el enlace y emiten datos clasificados. Esto le ayudará a presentar el riesgo de ataques como este y a educar al personal no técnico.

Regla de bonificación: las reglas están destinadas a romperse

La belleza de DevOps y DevSecOps es que puede modificar las reglas existentes o crear las suyas propias. Entonces, si algunas de estas reglas no son compatibles dentro de su empresa, no se preocupe, siempre hay una forma de evitarlo. No dude en adaptar las prácticas de DevSecOps a su propio caso. Juegue con diferentes herramientas, vea si puede permitirse pentesting o recompensas por errores, invierta tiempo y dinero en seguridad de la red, etc. No existe una “forma correcta” de hacer las cosas con un conjunto estandarizado de reglas de seguridad.

¿Qué herramienta DAST debo utilizar?

Existen muchas buenas herramientas DAST y escáneres de vulnerabilidades, pero ¿cuál debería usar? La respuesta depende de sus preferencias personales, presupuesto y tamaño de la empresa, pero en general, querrá una herramienta DAST que sea rápida, se integre fácilmente con herramientas de CI y otras aplicaciones el orbe de Probely . nes, tenga una API poderosa y proporcione a sus desarrolladores una interfaz de usuario intuitiva y con información relevante sobre las vulnerabilidades que encontró (cómo solucionarlo, evidencia, descripción). Si está utilizando CircleCI, querrá tener una herramienta DAST que tenga un orbe coincidente . De esta manera, podrá integrar fácilmente la seguridad en su flujo de trabajo de CircleCI.

Para ello, puede utilizar  Probely le permite escanear su aplicación web en busca de más de 1000 vulnerabilidades y tiene todas las características mencionadas anteriormente. Los desarrolladores aprecian Probely porque es intuitivo y muestra información relevante. Además de mostrar evidencia de que la vulnerabilidad es real, Probely detecta el lenguaje o la tecnología utilizada para construir la aplicación y, en base a eso, proporciona a los usuarios instrucciones personalizadas sobre cómo corregir las vulnerabilidades.

Referencia

Davor Petreski Circle CI (2019) Three rules for turning DevOps into DevSecOps. Recuperado de: https://circleci.com/blog/three-rules-for-turning-devops-into-devsecops/