Incidente de seguridad de Thanksgiving 2023

El detallado postmortem de Cloudflare sobre su brecha de Thanksgiving 2023 — vinculada a credenciales robadas en un compromiso previo de Okta que no se rotaron por completo — ha generado tanto elogios como escepticismo. Los comentaristas destacan la respuesta agresiva de la empresa (recrear miles de sistemas, rotar ~5.000 secretos e incluso reemplazar hardware en un nuevo centro de datos) como un modelo de respuesta a incidentes, mientras que otros cuestionan los riesgos residuales del código fuente expuesto y de los datos de Jira/Confluence, la dependencia continuada de Okta y las brechas entre el marketing de “zero trust” y los controles de acceso reales.

Respuesta al incidente y remediación

  • A muchos les impresiona la respuesta “nuclear”: rotar ~5.000 credenciales, hacer triage de ~4.900 sistemas, volver a crear/reiniciar la flota global y segmentar físicamente los entornos.
  • Varios dicen que esto va más allá de lo que hacen la mayoría de los grandes proveedores después de una brecha y facilita renovaciones/ventas.
  • Otros sostienen que este nivel de respuesta debería ser lo mínimo esperado, no algo excepcional, y señalan que brechas importantes anteriores en otras empresas tuvieron poco impacto comercial a largo plazo.
  • Algunos recuerdan incidentes anteriores (como bugs de parser) y cuestionan si Cloudflare siempre ha sido tan transparente como ahora se presenta.

Okta, credenciales y Zero Trust

  • La intrusión proviene de credenciales tomadas en un compromiso previo del soporte de Okta que Cloudflare no rotó por completo.
  • Debate sobre la culpa: algunos ven un intento de “darle hacia abajo” a Okta para desviar la atención del fallo de rotación de Cloudflare; otros dicen que los fallos repetidos de Okta merecen críticas duras.
  • Cuestionamiento del marketing de “zero trust”: los atacantes aprovecharon un único token bearer/service token y cuentas de servicio para llegar a Atlassian; los críticos dicen que un verdadero zero trust restringiría más esto.
  • Hay discusión sobre por qué las credenciales “no usadas” o poco entendidas no se revocaron o eliminaron simplemente, frente al temor operativo de romper dependencias desconocidas.

Alcance del acceso y del impacto

  • Los atacantes accedieron a una pequeña fracción de tickets de Jira, páginas de wiki y repos, aparentemente centrados en arquitectura y patrones de acceso más que en datos de clientes.
  • Algunos señalan que la búsqueda en Confluence/Jira puede filtrar secretos sin abrir las páginas, lo que dificulta medir el impacto real.
  • Los escépticos sostienen que cualquier exposición de código fuente interno e informes de bugs es grave y aumenta el riesgo permanentemente; otros enfatizan que solo se tocaron sistemas internos limitados.

Elecciones de herramientas e integraciones de terceros

  • Sorprende que un gran proveedor de infraestructura use Bitbucket; quienes lo defienden citan la integración con Atlassian y el coste.
  • Preocupación de que una cuenta de servicio de Smartsheet con derechos de administrador en Jira y ScriptRunner permitiera instalar Sliver C2, resaltando los riesgos de integraciones de terceros con mucho poder.

Sustitución de hardware y desperdicio

  • Devolver y reemplazar equipos en el nuevo centro de datos de Brasil es visto por algunos como extremadamente exhaustivo y por otros como un desperdicio.
  • Contraargumento: para equipos críticos de red con firmware potencialmente no confiable, el reemplazo se considera la única forma de estar seguros.

Confianza, transparencia y cumplimiento

  • Muchos dicen que los informes detallados y la sobrerreacción visible aumentan su confianza en Cloudflare.
  • Otros califican la entrada del blog como “publicidad”, argumentando que enfatiza la remediación mientras minimiza cómo surgió la situación.
  • Debate lateral sobre PCI/SOC: algunos afirman que la forensia externa está impulsada por el cumplimiento, otros responden que PCI es en gran parte una lista de verificación y no es el motor principal aquí.

Discusión paralela: uso personal de dispositivos de trabajo

  • Largo desvío sobre la gestión de dispositivos de Okta y si conviene mantener alguna cuenta/contraseña personal en portátiles corporativos.
  • Las opiniones van desde “absolutamente nada personal en dispositivos de trabajo” hasta “el uso personal ligero es inevitable y las políticas deberían asumir que los endpoints están comprometidos”.