¿Cómo será el equipo de seguridad del futuro?

“Voy a decir algo que sospecho que mucha gente ya está pensando: por sí solo, cambiar la seguridad hacia la izquierda no está resolviendo los problemas que queremos.” Nicholas Evans, analista de investigación

La construcción de un ciclo de vida de desarrollo de software seguro es un bien universal. Conduce a mejores productos. Pero si no se realizan otros cambios, no solucionará los problemas de seguridad en el entorno de desarrollo. Para eso, necesitamos examinar cómo se ejecutan las operaciones de seguridad.

Solo llegué a darme cuenta de esto hace muy poco tiempo. Como la mayoría de la gente, había asumido que cambiar la seguridad hacia la izquierda era un proceso que llevaría más tiempo. Donde no estaba funcionando, le habría dicho que se requería más esfuerzo para permitir que una cultura de seguridad impregnara el desarrollo de software. Pero luego comencé a hablar con profesionales de seguridad de todas las industrias en las que trabaja F-Secure, y algo se hizo evidente rápidamente. Aunque los desarrolladores están escribiendo código mucho más seguro, la seguridad de los entornos de desarrollo no parece mejorar. Y eso a pesar del esfuerzo concertado.

De hecho, mi propia investigación de la industria mostró que los entornos de desarrollo son una de las principales preocupaciones de seguridad para los CISO que intentan proteger sus propiedades en la nube, independientemente del tiempo que su organización haya estado desplazando la seguridad hacia la izquierda.

Todos hemos intentado cambiar a la izquierda durante casi media década. Si, en ese tiempo, las instituciones financieras maduras cibernéticas no han logrado hacerlo, entonces diría con seguridad que nadie llegará pronto.

Los socorristas en el frente lo saben desde hace un tiempo. Joani Green, que dirige el equipo de respuesta a incidentes de F-Secure en el Reino Unido, dice que “las configuraciones erróneas causadas por equipos DevOps descentralizados han sido la razón principal de las brechas en la nube que investigamos en los últimos dos años. Principalmente, se trata de canalizaciones de DevOps que contienen claves, organizaciones que no tienen control sobre secretos y también registro y seguimiento de configuración “.

Entonces, ¿qué puede explicar esto? ¿Y cómo podemos mejorar las cosas?

He estado pensando mucho en estas preguntas recientemente. Al hacerlo, me di cuenta de que aquí hay una historia más amplia. Esta es una historia sobre cómo cambiaron nuestras superficies de ataque, pero nuestro enfoque para protegerlas se retrasó, y sobre cómo todos pensamos que los cambios culturales podrían solucionar problemas organizacionales.Esta es una historia sobre cómo todos pensamos que los cambios culturales podrían solucionar problemas organizacionales.

Creciendo desde TI

Para comprender por qué nos encontramos en esta situación, debemos mirar la historia de la función de seguridad corporativa. La seguridad de la información comenzó como una parte segmentada del negocio porque se la veía como una función especializada que protegía a la TI (que ya era una parte especializada del negocio). La seguridad de la información fue, y por lo general sigue siendo, una consecuencia de la TI.

Uno de los expertos de F-Secure en el área, Matthew Pendlebury, resume la situación: “por lo general, las operaciones de seguridad se asocian con las operaciones de TI, porque de ahí viene cuando se trataba de firewalls y pruebas de penetración”. Y, por supuesto, este modelo tenía mucho sentido cuando la seguridad de la información se trataba de esos firewalls y pruebas de penetración.

Pero luego, hace aproximadamente una década, las cosas comenzaron a cambiar de una manera con la que todos estamos familiarizados. Las organizaciones comenzaron a trasladarse a la nube. Los procesos se volvieron escalables de una manera que nunca antes había sido el caso. El trabajo de desarrollo se aceleró mucho.

Como tal, los desarrolladores de software se volvieron cada vez más responsables de crear un gran porcentaje de las vulnerabilidades que constituyen la superficie de ataque de una organización empresarial típica.

“Tiene este objetivo realmente grande que está en la nube, y fuera del perímetro de su edificio, y está bajo el control de su equipo de desarrollo en lugar de bajo el control de su equipo de TI”, explica Matthew. Y debería saberlo. Matthew trabajó durante 17 años como desarrollador y en ejecución de equipos de desarrollo entregando código seguro en entornos seguros, antes de unirse a F-Secure como consultor especializado en insertar ‘Sec’ en DevSecOps. Ahora dirige gran parte de nuestras operaciones de seguridad interna. Cuando pregunta, ¿quién protege a los especialistas en seguridad? – El nombre de Matthew es la respuesta.”Tiene este objetivo realmente grande que está en la nube, y fuera del perímetro de su edificio, y está bajo el control de su equipo de desarrollo en lugar de bajo el control de su equipo de TI”.

Las palabras de Mateo realmente apuntan al meollo del problema. Los profesionales de Infosec todavía están en gran parte alineados con TI. Se ubican en el perímetro de las redes, sobre las que ejercen un control notable. Pero las redes locales son la fuente de los problemas de ayer. La nube ha destruido esa idea del perímetro y ha hecho obsoletas la mayoría de las viejas técnicas para defenderlo.

En resumen, los equipos de Infosec ya no están organizados de una manera que los coloque en la mejor posición para hacer frente a las vulnerabilidades emergentes. No es de extrañar que muchas personas que trabajan en los centros de operaciones de seguridad, así como los equipos de liderazgo centrados en la seguridad, vean a los desarrolladores como pasivos rebeldes. Un líder de seguridad informática me dijo que “DevOps sigue siendo el salvaje oeste”. Este juicio puede no ser particularmente justo para los desarrolladores, pero ¿alguien puede realmente culparlo por pensar de esta manera, cuando los desarrolladores permanecen completamente fuera de su control?

Cada vez más a la izquierda

Un blog de 2001 de Larry Smith a menudo se acredita como la primera declaración sobre el cambio de seguridad hacia la izquierda. Smith estaba hablando de pruebas en un sentido estricto, y también estaba escribiendo más de una década antes de que la mayoría de las organizaciones pensaran siquiera en la nube. No obstante, en la última década, su conocimiento básico se ha convertido en el medio dominante para que las organizaciones intenten controlar los problemas de seguridad que surgen con el desarrollo descentralizado.

En esta década, se ha avanzado mucho en la seguridad de los procesos de desarrollo. Los desarrolladores que piensan en la seguridad como una característica central de sus productos escriben código que es más estable, robusto y resistente. Han demostrado claramente que hay casos de negocios para adoptar un proceso DevSecOps que va más allá de simplemente ‘asegurar el producto’. Pero también hay cosas que simplemente no han sido abordadas por la mayoría de las organizaciones que siguen este camino.

Fundamentalmente, muchas organizaciones aún no tienen en cuenta el costo de la seguridad en las funciones comerciales individuales. El resultado, dice el director de consultoría Jesper Gerved, “es que la seguridad no se implementa porque no está en las listas de prioridades de las organizaciones”. Si una organización desea distribuir las operaciones de seguridad en sus funciones comerciales, debe convertir la seguridad en un producto medible para los empleados, igual a los demás objetivos que persigue. Los desarrolladores están bajo una intensa presión. Un estudio reciente(con un tamaño de muestra ciertamente pequeño de 260) encontró que el 83% informó sentirse agotado. Estas son personas que ya están siendo empujadas al límite. Si la seguridad les impide cumplir con los objetivos que sus organizaciones valoran, encontrarán formas de evitar la seguridad. Matthew pone todo esto en términos simples: “los desarrolladores tienen un objetivo dividido de tener que hacer cosas de seguridad pero tener la espalda contra la pared para cortar el código y ofrecer funciones”.

Lo que sucede a menudo es que se les pide a los desarrolladores que aseguren sus proyectos, aunque la responsabilidad financiera de esa seguridad recae en un equipo operativo separado. Matthew (de nuevo) es muy claro: “hay que poder resolver esa divergencia. Para averiguar cuánto vale la seguridad para su organización “. En última instancia, explica, “la cuestión es quién lo va a pagar”.

Este es un problema con el que nuestros consultores que trabajan en el campo se enfrentan cada vez más. Antti Vähä-Sipilä es uno de los pioneros en asegurar el ciclo de vida del desarrollo de sistemas (SDLC) en su Finlandia natal, con grandes planes para revolucionar la forma en que las organizaciones piensan sobre su arquitectura de seguridad. Pero Antti ha descubierto que simplemente centrarse en mejorar los procesos ya no siempre es suficiente para lograr los cambios necesarios para que sus clientes estén seguros. “Las causas fundamentales de estos problemas son mucho más profundas de lo que puede exponer un análisis de brechas SDLC”, dice, refiriéndose al tipo de evaluación que suele realizar cuando comienza a trabajar con un nuevo cliente. Las brechas en los procesos SDLC se detectan, pero solucionarlas no conduce a las mejoras necesarias, y la razón de esto es simple:
… Muchas empresas ahora tienen estructuras organizativas que son “inútiles para conseguir la seguridad correcta”.

Por lo tanto, Antti considera que el cambio organizacional es crucial para superar estos desafíos. Sus recomendaciones reales, que tienen que ver con la reestructuración de conceptos completos de administración de productos, quedan fuera del alcance de los informes que generalmente se le pide que escriba. A menudo, lo que se necesita es una serie de discusiones duras pero honestas con los de arriba.

¿Qué sigue?

Construir una cultura de seguridad entre los desarrolladores es un objetivo necesario e importante, pero no resuelve los problemas que he estado discutiendo aquí. Para eso, se necesita un cambio en la estructura organizacional, preferiblemente uno que aleje la seguridad de la información de su asociación con TI y se acerque a las funciones comerciales de una organización.

Creo que es solo cuestión de tiempo antes de que comencemos a ver esto reflejado en la estructura de las operaciones de seguridad y en los tipos de trabajos de seguridad que se ofrecen. Ya lo estamos viendo con organizaciones aisladas. Al menos un CISO con el que hablé está experimentando con un modelo radicalmente nuevo de tener un equipo de operaciones completamente “virtual”. Todos los miembros de este equipo tienen un papel principal en otra función y luego trabajan a tiempo parcial para el CISO. Es un comienzo, pero aún sufre el problema de que los objetivos comerciales dominen los de seguridad, y tiende a poner a las personas en una posición personal incómoda de tener que entregar funciones y los controles de seguridad que podrían obstaculizar esas funciones.

Lo que puedo decir con certeza es que las cosas van a cambiar y, habiendo hablado con varios expertos sobre este tema, estoy dispuesto a hacer tres predicciones sólidas.

Predicción 1: Las funciones comerciales comenzarán a pagar por su propia seguridad
El costo de por vida de hacer que el software sea seguro se incluirá de manera rutinaria en los presupuestos de los proyectos individuales. Esto ayudará a resolver las tensiones entre los objetivos comerciales y los objetivos de seguridad. Los gerentes de producto aprenderán que el trabajo de remediación en aplicaciones mal construidas puede costar muchas veces la cantidad requerida para construir cosas de forma segura al principio. Una vez que los gerentes comiencen a tener en cuenta el costo de la respuesta a incidentes, el caso financiero para la intervención de seguridad temprana será cada vez más claro.

Predicción 2: El rol de CISO se volverá más independiente y los
CISO más estratégicos se volverán cada vez más independientes de los departamentos de TI. Informarán directamente a los directores ejecutivos y tendrán más flexibilidad para establecer la dirección de la estrategia. Esto debería conducir al desarrollo de una estrategia de seguridad clara y menos limpieza a raíz de otras.

La otra cara de este cambio es que los CISO serán menos responsables de las operaciones de seguridad diarias. Jesper es un partidario de este punto de vista: cree que el futuro CISO proporcionará dirección al negocio y supervisará el progreso sin necesariamente ser responsable de implementar las operaciones de seguridad. En consecuencia, las operaciones de seguridad se distribuirán en unidades de negocio individuales para evitar retrasos y garantizar que quienes trabajan con tecnologías específicas también las protejan.

No obstante, los futuros CISO continuarán coordinando los servicios que funcionan mejor cuando están centralizados. Jesper ve al equipo rojo de la organización como una de esas “funciones de servicio a la empresa”. La respuesta a incidentes es otro servicio de este tipo, porque requiere un conjunto de habilidades que “simplemente no puede mantener en todas y cada una de las unidades de negocio”.

Predicción 3: Emergerá una nueva capa intermedia
Ya hemos visto que demasiada centralización puede ser mala. Pero cuando se trata de seguridad, también lo es demasiada distribución. Thomas Wearing, que trabaja con Jesper en la gestión de la seguridad, señala que una descentralización completa de la seguridad conduciría a la adopción de apetitos de riesgo radicalmente diferentes en todos los productos. También está el hecho de que necesita a alguien con conocimientos prácticos del producto para ayudar a traducir la política de arriba hacia abajo de la oficina CISO recientemente transformada.
 

Por tanto, la mayoría de los expertos con los que he hablado creen que será necesario definir y adoptar un papel de nivel medio en un futuro muy próximo. “A veces existen estos pseudo-roles, pero siempre son un poco esponjosos y no están muy bien definidos”, explica Thomas. “Creo que van a ver que se crea un rol que tiene más que ver con la coordinación y la consolidación. Pero todavía tengo que conocer a alguien que tenga ese papel correctamente “.

Matthew está de acuerdo. “Se necesita un nivel medio, que es alguien que esté más cerca del producto, que pueda asumir la responsabilidad de manera más local”, dice. “Estoy pensando aquí en el equivalente de un gerente de ingeniería para ese producto”. La idea sería alguien que pueda ver a varios equipos, pero que también tenga un conocimiento profundo de los productos que se están desarrollando. Alguien que pueda ir al grano. Sobre todo, sería alguien que pudiera hacer de la seguridad un objetivo crítico para el negocio para cada producto.

Esta capa organizativa se haría cargo de muchas de las tareas repetitivas que actualmente mantienen a los CISO atascados en los detalles, pero, lo que es más importante, también permitiría que la responsabilidad de la seguridad se integrara en los ciclos de trabajo de los desarrolladores individuales.

Pensamientos finales

Como todo el mundo siempre dice, no hay una solución rápida para asegurar un entorno de desarrollo, pero parte del problema hasta ahora ha sido que nuestro enfoque ha sido demasiado estrecho. Nos obsesionamos con cambiar la forma de pensar de los desarrolladores, cuando eso es solo una parte del rompecabezas. También necesitamos cambiar la forma en que organizamos nuestras operaciones de seguridad.

referencia: https://www.f-secure.com/en/consulting/our-thinking/security-team-of-the-future?ffcid=70168000000cJgZAAU&utm_source=linkedin&utm_medium=social&utm_campaign=GL&utm_content=a3