(M&T)-. Nuevos servicios surgen todo el tiempo, al igual que nuevas soluciones, productos y formas más rápidas de hacer el trabajo, de ahí nacen los DevOps. Un ejemplo de esto es el uso generalizado de métodos ágiles para el desarrollo de software, los cuales han sido utilizados y mejorados durante años. Nuestro mundo es mucho más dinámico que hace cinco años.
Por Fabio Gallego, consultor de Ingeniería de Sistemas de Nube Pública de Fortinet para América Latina
Hoy en día, los consumidores quieren nuevas características, desean mejoras en los productos que utilizan y quieren que salgan cosas nuevas constantemente. Las empresas lo saben y trabajan duro para que esto suceda. Pero cualquiera que tenga o apoye un equipo de desarrollo sabe que esta área está llena de desafíos diarios, así como es difícil encontrar programadores, profesionales de UX, arquitectos y expertos en seguridad.
Y el reto de la seguridad de la información es uno de los protagonistas. Anteriormente, la ciberseguridad era resuelta con la implementación de proyectos de seguridad y listo. El equipo de seguridad estaba acostumbrado a implementar soluciones como IPS, NGFW, Sandbox, EDR, WAF etc. Estos proyectos servían para proteger datos y aplicaciones, pero eran más estáticos, no sufrían cambios y con limitaciones protegían algunos productos desarrollados por terceros, como SAP, PeopleSoft, entre otros.
Pero la realidad hoy es distinta y requiere de integración entre los equipos. Entonces, ¿cómo lleva el desarrollador al personal de seguridad a la etapa de desarrollo?, ¿cómo puede el profesional de seguridad participar en la etapa inicial sin ser un impedimento para el despliegue de productos?, ¿cómo reúne el profesional de estrategia de ventas a estos equipos para lanzar la funcionalidad o el producto a tiempo?
Así como la cultura DevOps ha roto muchos silos, también lo hace DevSecOps. Todos son responsables de la seguridad, no un equipo solamente. Los riesgos deben ser conocidos, compartidos y abordados. Y ese abordaje puede incluir solucionar, compensar de alguna forma o simplemente aceptar que ese riesgo existe.
Le puede interesar El petróleo Ruso y la perspectiva desde el G7
Para que esta integración funcione, recomiendo el uso de algunas herramientas que harán una gran diferencia en las etapas de desarrollo y operación de DevOps
Durante el desarrollo:
Escanee el código con herramientas SAST, DAST y SCA para tener visibilidad de posibles vulnerabilidades en lo escrito.
Use una solución de Workload Protection para verificar si la imagen de contenedor tiene vulnerabilidades conocidas. No se puede reinventar la rueda todos los días, usar imágenes/librerías/contenedores públicos es inevitable (“fail fast, learn faster”), pero tampoco es práctico que el equipo seguridad evalúe cada uno de ellos.
Una solución de Workload Protection valida la configuración del contenedor y dirige a las herramientas de Sandbox que confirman que no hay amenazas de día cero integradas allí.
Durante la operación:
¿Encontraron alguna vulnerabilidad en el código, el riesgo es conocido, pero tiene fecha de entrega y retrasará la divulgación? Compruebe si las soluciones como un NGFW y un WAF avanzado (con ML e integrado con sistemas de inteligencia de amenazas), pueden mitigar su riesgo, brindando la capa de protección que necesita para acceder al producto. Este tipo de solución mitiga la mayoría de los grandes riesgos, como Log4Shell, MiTB, Bots, Virtual Patching, fuga de datos, entre muchos otros. Además de validar la configuración de los servicios en la nube.
La conclusión es que una vez que se conocen los riesgos, es posible minimizar su exposición y también el trabajo en su corrección. Con planificación e integración es posible responder a las demandas de desarrollo del negocio sin retrasar las entregas y sin estar expuesto.
コメント