Conversaciones sobre visibilidad, escalabilidad y relaciones en el desarrollo seguro con Phil Guimond, de ViacomCBS

Hace poco conversé con Phil Guimond, arquitecto principal de seguridad en la nube de ViacomCBS. Él describe su puesto como una forma elegante de decir que le gusta involucrarse en Todo „¢. Esto incluye seguridad y arquitectura en la nube, seguridad de aplicaciones, pruebas de penetración, análisis forense digital y respuesta a incidentes, e incluso, de vez en cuando, evaluación de proveedores y gestión de riesgos. Trabaja en un equipo muy multifuncional.

Tuvimos una conversación excelente y quería compartirla con todos ustedes. Hablamos sobre prácticas de seguridad, cómo abordar el desarrollo seguro moderno y mucho más. Espero que disfruten la charla tanto como yo.

Primero le pregunté a Phil cuál era su enfoque general de la seguridad y cuáles consideraba los aspectos más importantes en los que hay que enfocarse al crear un programa de seguridad de la información.

Guimond: Mi enfoque de la seguridad de la información se basa en la visibilidad, la escalabilidad y las relaciones. Es un sistema que he desarrollado a lo largo de los años gracias a muchas de las personas increíbles con las que he trabajado, incluido nuestro CISO de Streaming, Jonathan Keith, quien ha sido un gran mentor para mí. Durante los últimos años, mientras trabajaba como consultor en respuesta a incidentes, noté que faltaba mucha información. No había registros... nada. Básicamente, casi siempre trabajaba a ciegas y tenía que depender por completo de las herramientas estándar de la CLI para identificar los problemas. Mi recomendación número uno en cada incidente era implementar un sistema de registro adecuado para tener visibilidad. No importa cuánto gastes en herramientas de seguridad si no puedes ver qué necesitas proteger o qué ocurrió si algo se vio comprometido. ¿Cómo sabes qué proteger si no puedes ver qué pasó?

La visibilidad suele usarse como un indicador clave para priorizar los riesgos y obtener información útil en toda la organización. Quería saber cómo usa Phil los datos de visibilidad en su trabajo cotidiano.

Guimond: La visibilidad nos permite responder a una cantidad increíble de problemas en cualquier lugar donde aparezcan, incluidas las amenazas antiguas, nuevas y emergentes. La cantidad de cosas que puedes hacer con visibilidad es tan grande que a veces resulta sorprendente. Sin duda, es emocionante encontrarte con algo nuevo y que tus herramientas de visibilidad te muestren exactamente qué pasó. La visibilidad mejora drásticamente la respuesta a incidentes, las pruebas de penetración, la seguridad de aplicaciones, la seguridad en la nube, la gestión de riesgos y vulnerabilidades y prácticamente cualquier otra área.

En el caso de ataques a la cadena de suministro que comprometen bibliotecas de código abierto, o de vulnerabilidades en estas bibliotecas, puedes ver qué aplicaciones las usan y eliminarlas rápidamente de tus proyectos, actualizarlas o corregirlas tú mismo. Si se compromete la infraestructura de la nube o de la red, puedes encontrar rápidamente al responsable, determinar dónde comenzó el ataque y qué hicieron los atacantes con los recursos que tuvieron como objetivo. Y, lo que es más importante, identificar qué mala práctica provocó el incidente. Después puedes aislarlos fácilmente de cualquier infraestructura y eliminar de una sola vez todas sus acciones no autorizadas. O, si se comprometió la laptop de un empleado, puedes ver qué hizo el atacante con sus credenciales y a qué recursos intentó acceder.

Al crear programas de seguridad de la información a gran escala, es importante tener visibilidad de tantas cosas como sea posible. Necesitas entender qué tecnologías usas, qué bibliotecas de código abierto hay en un proyecto y conocer toda tu infraestructura en la nube, incluidas las políticas de IAM, los buckets, los contenedores, la infraestructura como código y demás.

Poder ver todos, o la mayoría, de tus problemas es fundamental. Puedes identificar qué equipos siguen buenas prácticas que generan mejores resultados y cuáles no. Y cuando detectas equipos que no siguen las prácticas recomendadas, tienes la oportunidad perfecta para acercarte y ayudarlos. Cuando los ingenieros empiezan a seguir las prácticas recomendadas, la gran mayoría de las vulnerabilidades desaparecen de repente. Además, puedes capacitar a los ingenieros en vivo. Por supuesto, la visibilidad por sí sola no basta: también tienes que poder corregir problemas a escala o siempre estarás apagando incendios.

Para mí, los dos últimos puntos son muy importantes. Primero, reconocer que el objetivo no es solo encontrar problemas, sino también actuar en función de esos hallazgos. Segundo, asegurarte de que estás preparado para escalar. Usar datos de toda la organización te permite identificar el estado y la cobertura de tus equipos de producto, y usar esos datos como parte de tu evaluación de riesgos. Si escalas a través de los equipos sin estar preparado, puedes extender los problemas en lugar de las prácticas recomendadas. Le pregunté a Phil qué significaba para él la escalabilidad.

Guimond: Para mí, escalabilidad significa hacer algo una vez y que esa solución resuelva todo. Por ejemplo, si varios equipos de proyecto necesitan una funcionalidad específica, la forma más sencilla de resolver el problema de tener una docena de bases de código que hacen lo mismo y que tienen vulnerabilidades y desafíos propios es desarrollar un proyecto central que resuelva el problema y dejar que todos esos equipos lo usen. Básicamente, quieres que tus soluciones puedan escalar para tantos equipos como sea posible, con la menor cantidad de acciones y proyectos. Parte de esto también consiste en lograr mejores resultados mediante el uso de prácticas recomendadas.

También creo firmemente que no puede haber verdadera escalabilidad sin visibilidad. Si no puedes ver lo que se supone que debes proteger, ¿cómo lo proteges? ¿Sabes siquiera que existe? En la mayoría de los casos, no lo sabrías a menos que tuvieras muchos conocimientos internos adquiridos tras trabajar en la empresa durante años. ¿Qué pasa si la persona que tenía todos esos conocimientos se va o la atropella un autobús? De repente, todo ese conocimiento desaparece. Y seguirías teniendo poca información sobre las vulnerabilidades de los proyectos. Ese enfoque no escala en absoluto.

La falta de escalabilidad pronto abrumará a tu equipo de seguridad y a los ingenieros que trabajan contigo. Ni tú ni tus desarrolladores tienen tiempo para este enfoque. La escalabilidad también es un gran problema con el enfoque actual de las pruebas de penetración. A los delincuentes no les importa en absoluto el alcance ni las pocas áreas pequeñas que hayas probado. No estoy criticando las pruebas de penetración. Creo que son absolutamente necesarias, pero las pruebas de penetración tradicionales son costosas y no escalan en absoluto. En el entorno actual, que prioriza la nube, necesitas un enfoque de pruebas de penetración que abarque toda la infraestructura. Y debe ser continuo. 

Como mencionó Phil, escalar demasiado rápido o no hacerlo en absoluto puede abrumar al equipo de seguridad, sobre todo si los procesos, la documentación, etc., no están preparados para afrontar el desafío de escalar. Así que le pregunté a Phil cómo logró escalar con éxito.

Guimond: Con un enfoque que prioriza la visibilidad y consolida las herramientas en una sola vista. Sé que suena a cliché, pero realmente funciona. Quieres facilitarles la vida a los ingenieros, no complicársela. Obligarles a usar 25 herramientas de seguridad distintas para proteger sus proyectos es un enfoque ridículo. Así es como se generan una resistencia interminable, falta de escalabilidad y visibilidad, y mucho menos interés de las unidades de negocio en trabajar con los equipos de seguridad.

Así que, si encuentras la manera de facilitarles la vida dándoles la menor cantidad posible de herramientas que resuelvan la mayor cantidad de problemas de forma escalable, obtendrás mejores resultados. Mucho mejores. Y eso se traduce en una mejor visibilidad, que a su vez permite gestionar vulnerabilidades a gran escala. La gestión tradicional de vulnerabilidades no escala: está obsoleta en la era de la computación en la nube. Las prácticas recomendadas eliminarán la mayoría de los problemas. Y para los que persistan, es importante implementar controles compensatorios cuando no sea posible corregirlos sin un rediseño arquitectónico significativo.

Le pregunté a Phil cuáles eran algunas de las prácticas recomendadas que sugeriría seguir para obtener los mejores datos de visibilidad para sus organizaciones.

Guimond: Consolidar y eliminar herramientas. Necesitas herramientas que expongan tus malas prácticas Y te ayuden a corregirlas con la menor cantidad de pasos y ofertas posibles. También debes eliminar las herramientas que no aporten un valor real a tu equipo de seguridad o a los desarrolladores. Si contratas personas solo para que se encarguen de una herramienta o de un conjunto de herramientas, esto puede crear silos y, a menudo, dar lugar a un enfoque de seguridad que no escala.

Quieres que tu equipo sea lo más multifuncional posible, así que dales espacio para explorar y asumir tareas distintas, además de las que ya apoyan. Si los colaboradores individuales pasan todo el día en reuniones, no se hará nada. Trabaja con proveedores cuyos productos tengan una API sólida que proporcione toda la información disponible en su propio panel.

En cuanto a cómo puedes consolidar las herramientas, puedes trabajar con proveedores que protejan gran parte de tu infraestructura en una sola oferta de producto. Por ejemplo, bibliotecas de código abierto, contenedores, SAST [static application security testing], infraestructura como código, inventario en la nube, etc. Luego, puedes enviar todos estos datos a un panel que los muestre en una sola vista, o en la menor cantidad de vistas posible. Debes poder explorar los problemas por categoría: aplicación, red, infraestructura o incluso proyecto.

Es fundamental conseguir el apoyo de las partes que puedan respaldar o hacer cumplir las iniciativas, o de las personas que realmente puedan hacer el trabajo y lograr que las cosas se hagan. Le pregunté a Phil a quién recomendaría pedir apoyo antes de empezar a trabajar para lograr visibilidad en sus equipos.

Guimond: Si estás formando un equipo de seguridad de la información que brinde apoyo, primero debes crear relaciones con los equipos o las unidades de negocio a los que apoyas. Comunícate con ellos, agenda una reunión, mándales un mensaje por Slack —lo que te funcione— y conversa para entender cuáles son sus desafíos. Cuando los entiendas, tendrás una mejor idea de cómo ayudarlos. Si sabes que un equipo tuvo problemas de seguridad específicos en el pasado, es importante proponer una solución para ayudarlos a corregirlos. Los desarrolladores te escucharán si lo haces.

Es muy importante escuchar a los directores, gerentes, desarrolladores e ingenieros del equipo y entender su punto de vista, sobre todo cuando difiere del tuyo. Si no aceptas otras perspectivas, si todo tiene que ser «a mi manera o nada», nadie querrá trabajar contigo y los resultados de tu programa de seguridad de la información serán peores. Pero, una vez que hayas establecido esas relaciones, a menudo será fácil conseguir el apoyo que necesitas. La gente sabrá que puede acercarse a ti y que no estarás encima de ellos. Luego, podrás incorporar las prácticas recomendadas y los conjuntos de herramientas.

Por último, le pregunté a Phil qué consejo general le daría a alguien que quiera crear su propio equipo y programa de seguridad en una organización.

Guimond: Contrata a un equipo diverso y multidisciplinario. Las personas con experiencias distintas a las tuyas verán las cosas de otra manera. Comprender otras perspectivas ayudará a todos a crecer profesionalmente y hará que los equipos sigan innovando. Por ejemplo, hablé con un equipo que tenía 20 proyectos diferentes que resolvían exactamente la misma necesidad. Cada equipo usaba su propia base de código y cada una tenía sus propias vulnerabilidades. Así que intentaban corregir estos problemas uno por uno. Mi enfoque fue mostrarles exactamente cómo corregiría las vulnerabilidades comunes asociadas con ese proyecto, pero dijeron algo que me sorprendió: no solo lo hicieron, sino que también crearon un único proyecto para esa necesidad y permitieron que cada equipo lo usara. Así resolvieron el problema de tener que ir y venir entre todas esas bases de código y eliminaron la necesidad de hacer pruebas de penetración en 20 proyectos distintos. Ahora solo tienen que probar uno. ¿Te suena familiar? ¡Es el ejemplo que usé antes!

Por eso es importante mantener la mente abierta, escuchar los enfoques de otras personas y no esperar hacer lo mismo una y otra vez en cada empresa. Cada empresa y cada equipo son únicos.

En cuanto a la importancia de un equipo multidisciplinario, ¿qué pasa si eliminas varias herramientas cuyo valor ya no justifica el costo? Es posible que los equipos que antes se encargaban de estas herramientas ahora tengan que hacer otra cosa. Si ya se capacitaron en otras habilidades, podrán adaptarse mucho más rápido al cambio. Además, la seguridad de la información siempre está cambiando. Esto les permite seguir creciendo en su carrera sin tener que irse a otro lugar y hace que tu equipo de seguridad sea más adaptable.

No digo que todos deban saber hacer de todo, pero es de gran ayuda que varios miembros del equipo puedan desempeñar distintos roles y, al mismo tiempo, especializarse en su función principal. Esta es la oportunidad perfecta para que tu equipo desarrolle nuevas habilidades y también se capacite. Cuando el equipo tiene la oportunidad de aprender otras cosas y crecer profesionalmente, resulta más fácil atraer a candidatos diversos.

No quieres que tu equipo se enfoque únicamente en una cosa, porque eso perjudicará su desarrollo profesional y frenará tu programa de seguridad de la información. Y, como gerente, si permites que esto suceda, les habrás fallado a ellos y a tu empresa. Habrá limitado sus oportunidades profesionales al mantenerlos aislados y ahora tu programa de seguridad de la información estará atrapado dentro de los límites que tú mismo definiste. Con el tiempo, la deuda técnica provocará más puntos ciegos, menor escalabilidad y muchas más vulnerabilidades.