¿Por qué DevSecOps?

Existe una 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 necesita 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, los profesionales a menudo se desalientan a 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 que British Airways enfrentó recientemente (alrededor de $ 230 millones).

DevOps “frente” DevSecOps

La fusión de desarrollo y operaciones es bastante natural. Los equipos de desarrollo y 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 reducirá 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 además de 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 n. ° 1: comience 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 sobre 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 largas revisiones 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 una 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 al mismo tiempo automatice su proceso de prueba de seguridad.

That’s where Application Security Testing (AST) tools come into play. There are two major types of ASTs (there are more than two, but these are the most common ones): D(dynamic)AST and S(static)AST. The difference between the two is that SAST tools scan the code for vulnerabilities, and DAST tools scan the application once it’s functional. Since DAST tools try to attack the application and find security issues like a hacker would, they report a lot more relevant findings with substantial evidence regarding the vulnerability. A SAST scanner might seem like the right choice here because they scan the code earlier in the workflow. However, the fact is that SAST scanners report a lot more false positives and irrelevant findings might turn developers down. On the other hand, DAST results are easier for developers to understand, and since they show the consequences of a vulnerability, the developer gets an idea of how severe the risk is. Most good DAST scanners will also have plugins and powerful APIs that will let you integrate them with popular CI tools, like CircleCI. Some of them, like 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. Y los escáneres DAST se pueden integrar sin problemas en su canal de CI / CD .

Regla n. ° 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 se ocupa de información confidencial de los clientes. Además, querrá tomar el contexto de cada vulnerabilidad y asignarla al riesgo potencial que representa 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 es suficiente simplemente 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 al personal técnico y no técnico, aportan 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 haciendo 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 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, 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 el orbe de Probely . 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

Traducido al español de Ron Powell. Gerente de marketing de contenido técnico (2020)

https://circleci.com/blog/how-to-measure-devops-success-4-key-metrics/