«Los riesgos asociados a vulnerabilidades en el software lo son también para la organización»

La seguridad es uno de los puntos más importantes para la mayoría de empresas en la actualidad. Esto implica no solo proteger sus sistemas, sino también hacer partícipe a toda la plantilla de la necesidad de protegerlos, y cuidar el acceso a los datos y la información sensible. También a determinados equipos y grupos de trabajo, como los dedicados a DevOps. Y desde el aumento del trabajo híbrido, que todo el mundo tome conciencia de que se necesitan medidas adicionales para proteger la infraestructura y la información sensible de la empresa. De todo esto, entre otras cosas, hemos hablado con Albert Tort, CTO & SogetiLabs Manager de Sogeti Spain MU.

[MCPRO] Los CEOs y responsables de seguridad de las empresas tienen que extender el cuidado de la seguridad y llevarlo también a los equipos de desarrollo. Especialmente, a los equipos DevOps, puesto que los hackers ya han conseguido acceder también a los espacios que utilizan los desarrolladores para su tarea y llenarlos de código malicioso, además de conseguir acceso a datos sensibles sobre los desarrollos en curso. ¿Cómo pueden atacar los ciberdelincuentes a los equipos DevOps y qué efectos pueden tener sus actividades en su trabajo?

[Albert Tort] El aseguramiento de los distintos atributos de calidad del software, y en especial la seguridad, deben gestionarse a lo largo de todo el proceso de desarrollo y entrega. Cualquier actividad que se realiza, así como las plataformas, herramientas y profesionales que las soportan, son fuentes de riesgo. Ser conscientes de estas potenciales vulnerabilidades es esencial para aplicar una estrategia de seguridad transversal a lo largo de estas actividades. Es un error pensar que podemos poner foco en la seguridad al final, ya que todas las actividades previas que se realizan de manera iterativa en un entorno DevOps para acabar entregando versiones de software son fuentes potenciales de vulnerabilidad.

De la misma forma que los ingenieros de software ponen foco en las aproximaciones shift-left (asegurar la calidad cuanto antes), también los hackers están haciendo este shift-left. En el reciente libro “Securing Enterprise DevOps Environments” publicado por Sogeti y Microsoft, se identifican tres áreas que requieren atención: el entorno de los desarrolladores (credenciales, dispositivos de trabajo, redes diversas…), la plataforma DevOps (repositorios de código, ramas, pipelines…) y el propio entorno de la aplicación (landing zones, subscripciones, despliegues, roles…).

Para cada área, se identifican potenciales ataques y buenas prácticas para constituir una estrategia transversal que aborde los riesgos de seguridad. Por ejemplo, en el entorno de los desarrolladores, pueden producirse secuestros de credenciales con privilegios, vulnerabilidades provocadas por extensiones, hackeos con conexión remota o vulnerabilidades por dependencias de terceros. En el entorno de la plataforma DevOps, se pueden producir intrusiones de malware en la propias pipelines o escalación de privilegios. Y en el entorno de la propia aplicación, se pueden producir también robo de secretos, escalación de privilegios y brechas de seguridad en los datos y accesos.

[MCPRO] A la vista de la importancia de los daños que los hackers pueden causar en los equipos de DevOps, proteger su entorno es cada vez más importante ¿cómo pueden las empresas proteger a sus equipos DevOps y sus desarrollos?

[Albert Tort] Efectivamente, los equipos que trabajan con una aproximación DevOps lo hacen a través de actividades bajo un ecosistema de plataformas de desarrollo, pipelines de puesta en producción, entornos pre-productivos y productivos, repositorios de código, etc. Por parte de los hackers no es necesario ir a producción cuando los entornos previos van a producción, los repositorios de código o las propias pipelines pueden tener vulnerabilidades.

Por ello proponemos tener en cuenta las siguientes buenas prácticas: (1) asegurar que los miembros de los equipos no guardan secretos en el código, en los repositorios o en los entornos, motivando así el uso de bóvedas de gestión de secretos; (2) implementar escaneos de los componentes de infraestructura como código (IaC) que constituyen las bases del desarrollo DevOps a través de plataformas inner-source (comunidades corporativas de componentes) como la Cloud Boost Library de Sogeti; (3) implementar rastreos automáticos (quién, qué, cuando, desde y dónde se realizan las acciones); y (4) automatizar los flujos de aprobación de las contribuciones de código. 

[MCPRO] Muchos temen que las medidas de protección a tomar para incrementar la seguridad pueden entorpecer el ciclo de desarrollo y ralentizarlo. ¿Cómo se pueden implementar medidas de seguridad de manera que esto no suceda, y que pueda además agilizarse el proceso de desarrollo? 

[Albert Tort] Cualquier actividad para poner atención en el aseguramiento de la calidad y la seguridad requiere foco, esfuerzo e inversión. No estoy de acuerdo en que estas actividades ralenticen o entorpezcan, ya que son actividades clave del desarrollo y entrega del software, como lo es la codificación. Tenemos que ver la eficiencia no solo hacia adelante, sino también considerando el retrabajo que se pueda producir y el impacto de la no calidad en los procesos de desarrollo.

Una analogía: de nada sirve avanzar con un coche sin ir aplicando medidas de monitorización y seguridad por el camino y en el propio coche, si lo que se pretende es llegar y hacerlo de manera eficiente. En los procesos de ingeniería del software pasa lo mismo. Cuando estas actividades se aplican, el riesgo de retrabajo y de esfuerzos de gran impacto para resolver las vulnerabilidades lo más prematuramente posible también se reduce.

[MCPRO] El aumento del teletrabajo y el trabajo híbrido ha hecho que los miembros de los distintos equipos de trabajo de las empresas accedan a Internet, y a datos y entornos de las empresas desde redes WiFi que no son seguras. Esto puede llevar a situaciones donde las empresas pueden sufrir brechas de seguridad y que los hackers accedan a datos sensibles a través de, por ejemplo, robos de identidad. ¿Cómo evitarlo y proteger a los desarrolladores para que puedan trabajar en remoto con seguridad?

[Albert Tort] Hoy en día, la velocidad de los desarrolladores está directamente asociada a esta capacidad de realizar el trabajo en entornos, redes y localizaciones diversas, ya sea en la oficina, en casa o en cualquier otro espacio. El trabajo en remoto es por tanto una realidad evidente con la que los responsables de ciberseguridad deben convivir y contemplar. 

Desde Sogeti proponemos buenas prácticas como: (1) facilitar un entorno de desarrollo cloud corporativo con capacidad de self-service de plantillas, máquinas virtuales y recursos pre-formateados provistos con facilidad y seguridad integrada (OneShare de Sogeti es una de estas soluciones); (2) securizar el entorno de desarrollo con contenedores que faciliten las fronteras de seguridad y las actividades de validación; (3) implantar una política de “least privileges”, en la que solo se accede un nivel mayor de acceso/autorización puntualmente (just-in-time access); (4) limitar quien puede aprobar/cambiar el código con una política adecuada de gestión de ramas; y (5) tener un catálogo de extensiones, herramientas e integraciones confiables por parte de la organización.

En definitiva, más que restringir de manera limitante, el objetivo debería ser proveer el uso de componentes que faciliten el trabajo de desarrollo con calidad y seguridad, evitando otras vías no confiables fuera de la política de la organización.

La mejora de la seguridad en los entornos de desarrollo del software, de principio a fin, es clave también en entidades gubernamentales. La acción dañina de un hacker puede poner en jaque el proceso de desarrollo y entrega del software, con las consecuencias políticas, sociales y económicas que ello supone. Por eso los gobiernos están cada vez más preocupados por la mejora de la seguridad de la cadena de suministro y entrega del software ¿Cómo conseguirlo, y cómo educar a este tipo de organizaciones y a las entidades relacionadas con la cadena de suministro para que refuercen su seguridad? 

[Albert Tort] Hoy en día, no se me ocurre casi ninguna organización que no dependa del software para las operaciones en su día a día, con lo que los riesgos asociados de vulnerabilidades en su software lo son directamente también para la organización. Por ejemplo, una reciente orden ejecutiva de la Casa Blanca, pone el foco en la necesidad de percibir el desarrollo de software como una cadena de suministro del software con vulnerabilidades potenciales de extremo a extremo con un capítulo denominado “Enhancing Software Supply Chain Security”.

Por ello es importante alinear el framework de aseguramiento de la seguridad a esta realidad, con buenas prácticas como: (1) el uso de componentes y librerías previamente analizadas y confiables en la organización; (2) el uso exclusivo de integraciones confiables de la plataforma de trabajo DevOps; (3) la implantación de landing zones seguras y con elementos automatizados en base a lo que llamamos un Well Architected Framework (WAF) como base para el desarrollo seguro; (4) aplicar segmentaciones (grupos de gestión en las subscripciones cloud, aislar entornos y cargas de trabajo…); y (5) dar visibilidad a los equipos de seguridad de escaneos automatizados sobre los componentes y las pipelines.