A lo largo de su carrera como ingeniero de ciberseguridad, Matthew Rosenquist tuvo que lidiar con no pocas frustraciones. Hubo un director general que despidió a su propio equipo después de que este le señalara unas vulnerabilidades en el producto principal de la empresa. Había ingenieros de software que carecían de experiencia en seguridad, pero a los que no les importaba adquirirla.
«En su opinión, eran programadores brillantes y eso les bastaba», afirma Rosenquist. «Dijeron: “Eso no es problema mío”.» «Simplemente lo programo para que funcione y el resto es problema de algún responsable de seguridad».
Esa actitud hostil es comprensible. Los desarrolladores de software se mueven en un mundo de diseño iterativo, lanzamientos rápidos y «producto mínimo viable». Por cuestiones de tiempo y para centrarse en el código, no se preocupan por mucho más, incluida la seguridad. A menudo lo perciben como un lastre para el calendario o incluso para el propio producto.
«Si es usted desarrollador o ingeniero, este es su proyecto», afirma Rosenquist, estratega en ciberseguridad y asesor del consejo de administración que trabajó durante 23 años en Intel y que actualmente ocupa el cargo de director de seguridad de la información (CISO) en Eclipz.io, una empresa de cifrado de software. «Tiene plazos que cumplir. Se le evalúa en función de su capacidad para hacer que su código funcione a tiempo. Ahora imagine a un especialista en ciberseguridad que no conoce su producto. «¿Quiere que haga X, Y y Z?» «Eso me va a desbaratar la planificación». Esta fricción va en aumento. «Lo único peor es no tomar ninguna medida de seguridad».
Superar la brecha
La fricción que describe Rosenquist no es nada nuevo. Esta situación tiene su origen en una división de larga data dentro de la empresa entre los equipos de DevOps y los de seguridad, y se ha agravado debido a los retos que plantea una crisis sanitaria mundial. Dado que millones de trabajadores a distancia acceden a sistemas de datos confidenciales a través de decenas de millones de dispositivos finales —entre los que se incluyen ordenadores portátiles, ordenadores de sobremesa y tabletas—, las vulnerabilidades y las brechas de seguridad se han disparado. Según una encuesta publicada por Tanium en 2020, las empresas norteamericanas pierden 700 000 millones de dólares al año como consecuencia de las interrupciones en los servicios informáticos. La división entre los equipos no ayuda en absoluto.
Pero deben trabajar juntos. Una práctica emergente denominada DevSecOps, por ejemplo, tiene como objetivo tender puentes entre estos dos ámbitos enfrentados mediante la integración de los miembros y los procesos del equipo de seguridad en el ciclo de vida del desarrollo de software, con el fin de detectar las vulnerabilidades en una fase temprana. Aun así, profundos problemas culturales, una escasez global de personal cualificado en materia de seguridad y las estructuras organizativas siguen obstaculizando la armonía entre los equipos. A medida que los responsables de TI buscan formas de superar estos obstáculos, han surgido varias prácticas recomendadas, empezando por un compromiso más claro por parte de la dirección y el fomento de un espíritu de colaboración. A continuación le indicamos cómo empezar:
Marcar la pauta desde arriba
Tras los dos virus devastadores que afectaron a Microsoft en 2001, Bill Gates envió al año siguiente un memorándum a toda la empresa, en el que anunciaba que la seguridad pasaría a formar parte integrante de la programación de todos sus productos: «Cuando nos enfrentemos a la disyuntiva entre añadir funciones y resolver problemas de seguridad», escribió Gates, «debemos optar por la seguridad». … Estamos formando a todos nuestros desarrolladores en las últimas técnicas de programación segura. ... «Nuestro software debería ser tan seguro en su esencia que los clientes ni siquiera tuvieran que preocuparse por ello».
El resultado fue el innovador y muy imitado «ciclo de vida de desarrollo de la seguridad “”» de la empresa, un conjunto de prácticas que integra la seguridad en el producto a medida que este se desarrolla y madura. Desde entonces, las empresas de todo el sector tecnológico han adoptado —y adaptado— estas prácticas de seguridad.
La conclusión: la incorporación de medidas de seguridad en el ciclo de vida del desarrollo de un producto puede, sin duda, afectar a los plazos. Y si los altos cargos no le dan prioridad, va a resultar mucho más complicado convencer a los niveles inferiores de la jerarquía. «Desde los niveles más altos, es necesario adquirir una visión empresarial que esté en consonancia con los objetivos corporativos», afirma Rosenquist.
«. Desde los niveles más altos, es necesario adquirir una visión empresarial que esté en consonancia con los objetivos corporativos»Matthew Rosenquist, director de seguridad de la información (CISO) de Eclipz.io Inc.
David Hahn lo ha comprobado de primera mano. Como director de seguridad de la información (CISO), que ha trabajado en el ámbito de la ciberseguridad en Silicon Valley Bank, el conglomerado mediático Hearst, Intuit y otras empresas, ha colaborado con éxito con los responsables de TI al convenir en que la ciberseguridad debe tener voz y voto en las decisiones y al transmitir a sus equipos la importancia de contar con diferentes conjuntos de competencias que, en última instancia, deben trabajar de forma conjunta. «No puede incorporarse más tarde y que su papel sea el de malo», afirma.
El cambio en la responsabilidad
Una forma de salvar esa brecha consiste en integrar la seguridad de manera más profunda en el proceso de desarrollo. Según un estudio de EY, casi dos tercios de las empresas actuales no cuentan con la participación de los equipos de seguridad en las primeras fases de los proyectos de TI.
Según los expertos, una forma de contribuir a reducir esa brecha es adoptar el enfoque de pruebas de software denominado «shift left» (desplazamiento hacia la izquierda), que consiste en dar prioridad a las pruebas en una fase mucho más temprana del ciclo de desarrollo, en lugar de incorporarlas a posteriori. Además, fomenta —si no exige— una mayor colaboración entre los equipos de seguridad y los desarrolladores.
Este tipo de prácticas contribuyen a eliminar las antiguas barreras entre departamentos. «Se trata de crear un nuevo equipo», afirma Hahn. «Todo el mundo debería adquirir competencias en materia de desarrollo, seguridad y operaciones, aunque algunos tendrán más experiencia en un ámbito que otros».
Una forma de conseguir que lleguen hasta ahí es mediante la formación. Dotar a los desarrolladores de software de competencias en materia de seguridad supone «una oportunidad de crecimiento», afirma Hahn. Del mismo modo, a muchos analistas de seguridad les resultaría útil aprender conceptos básicos de programación. «Pueden empezar con un lenguaje de programación como Go o Python para comprender la programación procedimental y las complejidades del desarrollo de software», afirma Ax Sharma, investigador de seguridad e ingeniero en la empresa de desarrollo de software Sonatype, con sede en el Reino Unido. «Esto contribuirá a reducir el escepticismo respecto a la capacidad del equipo de seguridad para participar en los resultados del equipo».
DevSecOps: Descubrir nuevas formas de abordar la seguridad y el desarrollo
Si los equipos de seguridad y de desarrollo de software logran forjar un nuevo espíritu de colaboración en los próximos años, será en parte porque han adoptado un estilo de trabajo que ha tenido un éxito rotundo a la hora de sanar otra antigua brecha empresarial: la existente entre los desarrolladores de software y los equipos de operaciones de TI. A lo largo de la última década, más o menos, los desarrolladores han colaborado mucho más estrechamente con el equipo de operaciones de TI para integrar ambas funciones y lanzar al mercado nuevo software con mayor rapidez y eficiencia que nunca.
Se trata de una metodología denominada DevOps, que, según GitLab, ya aplican de una forma u otra aproximadamente el 62 % de las empresas. DevSecOps se basa en el mismo concepto, incorporando las pruebas de seguridad al proceso durante la fase de desarrollo, y no después.
DevSecOps no solo implica la participación de los equipos de seguridad en una fase más temprana del proceso, sino que permite al conjunto del equipo evaluar la tolerancia al riesgo. Para los ingenieros de software a quienes les preocupa que sus compañeros de ciberseguridad ralenticen el desarrollo, Hahn afirma que hay una forma de poner a todos de acuerdo y mantener el código en marcha: explicarles qué ocurre si las vulnerabilidades no se detectan a tiempo. «Implemente un modelo de amenazas», afirma. «Cuando uno empieza a planificarlo, se convierte en algo tangible». Se convierte en un debate técnico, en lugar de en algo como: «La opinión de David no era muy acertada, no me gusta eso».
Un modelo de amenazas ofrece a ambas partes una forma de buscar un punto de acuerdo. Por ejemplo, los ingenieros de software están muy interesados en crear un MVP o una versión beta de un nuevo producto que incluya una base de datos completa de registros propios. El departamento de seguridad no quiere que esa base de datos se encuentre en ningún lugar cercano al producto hasta que se haya completado una prueba exhaustiva de vulnerabilidades. Un modelo de amenazas podría poner de manifiesto los riesgos inherentes a la inclusión de datos confidenciales en un producto aún sin terminar.
Y, a partir de ahí, corresponde al equipo de seguridad dar un paso al frente. «Tienen que decir: “No es necesario que corramos ese riesgo”.» «Podríamos introducir datos ficticios», afirma Hahn. El informe de EY señala, asimismo, que los equipos de seguridad podrían mejorar la forma en que comunican dichos riesgos.
A la hora de reunir a ambas partes, Sharma sugiere comenzar con iniciativas a pequeña escala, como revisar el estado de los procesos de seguridad y los niveles de amenaza en todos los productos. De este modo, se tomará conciencia de dónde se producen las vulnerabilidades. A continuación, ambos equipos pueden utilizar herramientas de automatización de la seguridad de , como el software de detección de malware, para localizar las vulnerabilidades restantes. «Considere el primer mes de sus esfuerzos como una fase de observación, de modo que los equipos puedan apreciar el efecto, trabajar juntos y realizar ajustes para eliminar el desperdicio», afirma Sharma.
Cuando las cosas se descarrilan
A veces las cosas saldrán bien. Otras veces, no lo harán. Cuando ambas partes no logran colaborar, hay que buscar dos causas, afirma Hahn: la ampliación del alcance, que hace que un proyecto se desvíe de los plazos y del proceso previstos, y el ego. «Me refiero a personas que no respetan los principios que ellas mismas habían acordado», afirma.
Llegado ese momento, es hora de detener el desarrollo, aunque ello implique retrasar la fecha de lanzamiento. «Es mejor detectar una vulnerabilidad de seguridad que retrase un proyecto dos meses —afirma Hahn— que enfrentarse a una posible catástrofe tras un lanzamiento público».
«Siempre habrá un coste», afirma Rosenquist, director de seguridad de la información (CISO) de Eclipz.io. «Pero lo que está haciendo es mitigar las pérdidas o garantizar el cumplimiento de la normativa». Añade que la integración de los equipos de seguridad y de TI no solo beneficia a los empleados. «Puede suponer una ventaja competitiva».
