Adaptación de las lecciones aprendidas del programa FedRAMP de Google a un puesto de CISO multi-framework

Drew Gutstein ha solucionado problemas de cumplimiento que se estaban produciendo a casi cualquier escala. Dedicó casi cinco años a crear y dirigir el programa FedRAMP de Google. Posteriormente, en 2023, se unió a Hudson River Trading (HRT) para desarrollar su función de gobernanza de seguridad desde cero, asumiendo el cargo de CISO al año siguiente, donde gestionó obligaciones en NIST CSF, DORA y SEBI-CSCRF; aproximadamente una docena de regímenes en total. Desde entonces, ha dejado HRT para crear su propia empresa, Gutstein Security Works, donde desarrolla controles cibernéticos automatizados y personalizados para entornos empresariales complejos. Nos reunimos con él en pleno desarrollo para hablar sobre las lecciones que solo alguien que ha ocupado los tres puestos (CISO, ingeniero de seguridad y enlace regulatorio) puede ofrecer: por qué el cumplimiento se produce de la misma manera a cualquier escala y qué lo soluciona realmente.

Hablamos sobre qué es lo primero que falla cuando el cumplimiento deja de ser manual, por qué el riesgo interno está empeorando silenciosamente y por qué nadie ha resuelto aún la gestión del riesgo de terceros.

La IA está aumentando el riesgo interno, no solo el riesgo externo.

Si se le pregunta a Gutstein de dónde proviene la próxima ola de riesgos, señala los puntos finales de los desarrolladores y cómo la IA está cambiando la ecuación de las amenazas internas de dos maneras simultáneas. Primero, los sistemas de IA son en sí mismos un objetivo: "El uso de la IA dentro de una organización crea una enorme superficie de ataque para lo que en la práctica son ataques de phishing", afirmó. Un agente puede ser manipulado de la misma manera que una persona puede ser engañada para hacer clic en un enlace malicioso. Segundo, la IA ahora escribe y confirma código directamente, y si ese código se registra y se confía implícitamente como suele hacerse con el código escrito por humanos, puede terminar ejecutándose en producción —o peor aún, en el pipeline de CI/CD de una empresa— antes de que alguien detecte el problema.

Su recomendación: tratar los entornos de desarrollo con mucha menos confianza inherente en ambos frentes. «Mantengan los puntos finales de los desarrolladores alejados de todo», dijo. «Aquí es donde se originan los ataques a la cadena de suministro». También quiere adoptar una práctica del código abierto por completo, exigiendo que los cambios de código internos pasen por una revisión independiente antes de su publicación, de la misma manera que un mantenedor revisa una solicitud de extracción de un desconocido. «Ya tenemos una forma muy madura de permitir de forma segura que la gente edite código que no les pertenece. Se llama código abierto», dijo. Su argumento: los mantenedores de código abierto nunca confían en una contribución solo por quién la envió. Cada cambio se revisa de forma independiente antes de fusionarse, venga de un desconocido o no. Las empresas, por el contrario, suelen extender la confianza automática al código de los empleados (y ahora, a sus propios agentes de IA), aunque ese código conlleva el mismo riesgo. Drew todavía no ha visto a ninguna empresa importar internamente esa disciplina del código abierto, a pesar de lo obvia que parece la solución una vez que se dice en voz alta.

Cumplimiento normativo a hiperescala

En Google, Gutstein gestionó el cumplimiento de FedRAMP en más de 33 millones de máquinas virtuales y millones de contenedores, una escala en la que el enfoque del programa basado en hojas de cálculo resultó insuficiente. FedRAMP exige informes mensuales de vulnerabilidades, y a la escala de Google, las cifras simplemente no cabían en una hoja de cálculo. Por lo tanto, esa escala rompió el formato que el programa esperaba para los informes. «Imaginen una hoja de cálculo con 33 millones de máquinas multiplicadas por innumerables detecciones. Es imposible incluirlo en una hoja de cálculo. No cabe», afirmó, una discrepancia que atribuye a la rapidez con la que la hiperescala superó las herramientas que todos utilizaban, incluidos los reguladores.

Esa brecha impulsó a Gutstein a trabajar en OSCAL, un formato estandarizado para datos de control respaldado por el NIST. «Imagínenlo como la versión XML del PDF de su plan de seguridad», explicó. La idea principal era que la evidencia fuera legible por máquina en lugar de recopilarse manualmente. También representó a Google en el Consejo Asesor de Proveedores de Servicios en la Nube, instando a los proveedores de servicios en la nube a hablar con una sola voz ante los reguladores de FedRAMP sobre cómo se debería medir el cumplimiento, en lugar de que cada uno presentara solicitudes contradictorias que obstaculizarían la evolución de FedRAMP.

La escala también generó cuellos de botella internos. La infraestructura central de Google incluía seguridad integrada, pero GCP no. Extender la cobertura de escaneo a GCP implicó involucrar al equipo interno de escaneo de Google, que solo había escaneado la infraestructura de Google, nunca los productos de GCP orientados al cliente, y lograr que aceptaran la tarea requirió la aprobación del mismísimo CEO de Google Cloud. Incluso después de obtener ese apoyo, la capacidad se quedó muy corta: el objetivo era escanear 40 productos ese trimestre; el equipo solo pudo escanear dos.

Una solución estructural que aún admira provino de un competidor. Microsoft creó una "autorización de cambio" que permite que los nuevos productos de Azure lleguen al mercado FedRAMP en semanas, en lugar del plazo de aproximadamente un año que tardan los demás. "Microsoft ideó una forma de auditar su proceso SDLC para que el gobierno pudiera aceptar cada lanzamiento, y sí, el proceso en sí es revisado periódicamente por auditores", dijo, pero aun así ahorran mucho tiempo. "No hace falta ser Microsoft para hacer eso", afirma, aunque también admite que es difícil crear un sistema así y ponerlo en marcha.

La gestión de riesgos de terceros aún no está resuelta.

Gutstein es inusualmente directo en este punto: "Todavía no hemos resuelto el problema de la gestión de riesgos de terceros (TPRM)", afirma. En HRT, su equipo realizó un estudio informal comparando las alertas de brechas de seguridad basadas en noticias con las notificaciones de su sistema formal de gestión de riesgos de terceros. El resultado fue preocupante: "Se tardaba mucho más en recibir la alerta del sistema de gestión de riesgos de terceros, y no parecía haber ninguna correlación entre la puntuación de riesgo y la probabilidad de sufrir un ataque".

Parte del problema, según él, radica en que la disciplina aún se basa casi exclusivamente en informes autodeclarados. Los cuestionarios crean una apariencia de diligencia sin reducir necesariamente el riesgo y pueden resultar engañosos, dados los casos documentados de informes de cumplimiento falsificados. Aplica el mismo enfoque que lo impulsó a adoptar la revisión de código de estilo abierto para el código interno también al ecosistema de proveedores, estableciendo así una distinción que la mayoría de los programas de gestión de riesgos de terceros (TPRM) pasan por alto: el código de código abierto y el subcontratado merecen un modelo de confianza diferente al del software de proveedores, no una política general única. En resumen: todo el código se revisa minuciosamente, y la revisión varía según el riesgo que conlleva.

Su argumento más contundente se centra en dónde reside realmente el cuello de botella en la gobernanza de proveedores. Para evitar la sobrecarga de revisiones que crea obstáculos y obliga a los equipos a eludir el proceso por completo, sugiere que cada nueva herramienta o solicitud de proveedor debería someterse a una pregunta antes de llegar a seguridad. «La pregunta más importante en la gestión de riesgos de terceros es: ¿Realmente lo necesitas? Y si la respuesta es un poco, probablemente no», afirmó, argumentando que las herramientas deberían filtrarse en el departamento de compras antes de llegar a la cola de revisión de seguridad.

En cuanto a las herramientas que logran superar el proceso, observa que la automatización de TPRM se orienta hacia herramientas más modernas que consolidan los conectores SaaS en una única capa de integración, reemplazando los cuestionarios estáticos de autoinforme con una señal más continua. Estas herramientas se conectan directamente a los sistemas de una empresa (Okta, plataformas en la nube, etc.) mediante API, obteniendo información en tiempo real en lugar de que alguien tenga que exportar y cargar manualmente una hoja de cálculo.

Operar bajo una docena de regímenes regulatorios a la vez

El cambio de un programa federal a un rol de CISO con múltiples marcos de trabajo introdujo a Gutstein a una complejidad diferente: la superposición de requisitos. En HRT, realizaba un seguimiento simultáneo de las obligaciones de NIST CSF, DORA, SEBI-CSCRF y otros marcos de trabajo. Según él, los marcos de trabajo convergen cada vez más en torno al mismo lenguaje de control subyacente, incluso a medida que surgen otros nuevos. Su enfoque consistía en mapear los controles entre los distintos regímenes para lograr la equivalencia, utilizando la automatización para reutilizar la evidencia en lugar de volver a demostrar el mismo control varias veces.

Según él, el cambio más importante radica en la sincronización: “Cuando tienes una docena de reguladores y las auditorías se realizan simultáneamente todo el tiempo, tienes que estar preparado desde el principio. Por eso necesitas un cumplimiento continuo y una seguridad constante”. También habla con franqueza sobre la ventaja competitiva: “Si hago un trabajo excelente y elevo el listón para todos los demás, entonces genial”.

El hilo común

En sus tres funciones —CISO, ingeniero de seguridad y enlace regulatorio— Gutstein siempre llega a la misma conclusión. «Aquí es donde me apasiona la automatización», afirma, «porque es ahí donde realmente se obtiene el beneficio, donde se puede liberar a quienes no deberían encargarse de la seguridad». En su opinión, la gobernanza no es un mero trámite burocrático. Es un problema de diseño relacionado con el comportamiento humano, y la solución es casi siempre la misma: automatizar la evidencia, priorizar según el riesgo real y dejar de confundir la actividad con la seguridad.